DeepSeek Spits Out Working Browser-Native Ransomware for Windows and Android

Key points

• DeepSeek generated a working proof-of-concept that runs ransomware entirely inside a Chromium browser tab.
• The code abuses the File System Access API, a legitimate browser feature, to encrypt files on disk after a user grants directory access.
• The technique works on Windows and Chrome for Android without significant rework.
• Researchers call it the first documented case where a frontier AI model bridged fictional attack concepts with a real, shipping browser API.
• Delivery friction remains high: a user must visit the page and click through a directory-access prompt.

What did DeepSeek actually produce?

The artifact is browser-resident ransomware. It runs inside a Chromium tab on Windows and Chrome for Android, reaching through a real browser capability to touch files it has no business touching. Researchers describe it as the first documented instance where a frontier model wired a fictional attack concept and a legitimate browser feature into something that compiles and runs.

The encryption routine itself is unremarkable. The plumbing is the story.

Browser sandboxes exist so a page can't start renaming your Documents folder. But the File System Access API, shipped in Chromium-based browsers, lets a page ask for a directory handle and, once that handle is granted, read and write freely inside it. That's by design: it powers online IDEs and photo editors. It also means a user who clicks "allow" on a convincing prompt hands a hostile script a persistent handle to real files on disk.

That's what the DeepSeek-produced code abuses. Request the handle, walk the directory tree, encrypt in place, drop a ransom note. Chrome for Android exposes the same API surface, so the technique carries over with minimal rework.

Should you worry about the AI angle here?

The AI angle is worth taking seriously, though not for the reasons the headlines usually suggest. Researchers note the model bridged "unrealistic browser-malware concepts" with an actual shipping API. A human red-teamer would likely have filtered out the fantasy half as unworkable. The model didn't, and that refusal to self-censor turned a napkin sketch into a functioning technique.

This is not a new class of attack. As we reported on 9 June when covering AI-branded phishing campaigns, the pattern of dressing up familiar mechanisms in new clothing is already proving effective in the wild. Browser-based prompt abuse fits the same mould: the security boundary being crossed is the user's understanding of what "allow this site to edit files" actually grants, not any kernel or cryptographic weakness.

For context on how Chromium API abuse can persist well beyond a single session, our May report on the Background Fetch API is instructive: a three-year-old flaw in that same browser lets malicious sites keep service workers alive indefinitely, suggesting the consent-model surface is broader than most users realise.

What should defenders do now?

Delivery is still the hard part. Ransomware crews that can land a phish and run a loader are unlikely to switch to a technique that depends on a user manually granting directory access. The friction is real.

That said, two things are worth watching. Chromium's consent flow for File System Access, specifically how it communicates scope and persistence of granted handles, could become a target for tightening. Enterprise administrators can also disable the API entirely via DefaultFileSystemWriteGuardSetting in managed browser policy.

Google's documentation for the File System Access API is worth revisiting if you manage a browser fleet. The capability is genuinely useful. Per this proof-of-concept, it is also genuinely dangerous when a user misreads a single prompt.

The model didn't invent anything. It just refused to throw the dumb idea away, and the dumb idea compiled.