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

A new proof-of-concept generated with the help of DeepSeek is making the rounds, and it deserves a closer look than most "AI wrote malware" stories.

The artifact is browser-resident ransomware. It runs inside a Chromium tab, on both Windows and Android, and reaches out through a real browser capability to touch files it shouldn't be able to touch. Researchers are calling it the first documented case where a frontier model wired together a fictional attack idea and a legitimate browser feature into something that works.

The interesting part isn't the encryption routine. That bit is boring. The interesting part is the plumbing.

Browser sandboxes exist precisely so a page can't reach out and 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 granted, read and write inside it. That is by design. It powers online IDEs and photo editors. It also means that if a user clicks "allow" on a plausible-looking prompt, a hostile script gets a persistent handle to a real folder on disk.

That's what the DeepSeek-produced code abuses. Ask for the handle, walk the tree, encrypt in place, drop a note. On Android, the same API surface is available in Chrome, so the technique ports across without much rework.

If this feels familiar, it should. It's closer in spirit to a clickjacked OAuth consent than to a kernel exploit. The security boundary being crossed is the user's understanding of what "allow this site to edit files" actually grants.

What makes the AI angle non-hype: the researchers describe the model bridging "unrealistic browser-malware concepts" — the kind of thing a junior red-teamer would sketch on a napkin and discard — with an actual, shipping API. A human would likely have filtered out the fantasy half. The model didn't, and that turned out to be useful for building something novel rather than useless.

Whether this ever shows up in the wild is a separate question. Delivery is the hard part. You still need a user to visit a page and grant directory access, which is a friction point most ransomware crews would rather skip in favor of a phish and a loader.

Still, a few things worth watching:

• Whether Chromium tightens the consent flow for File System Access, particularly the scope and duration of granted handles.
• Whether enterprise policy admins start disabling the API outright via DefaultFileSystemWriteGuardSetting and friends.

Google's documentation for the File System Access API is worth a re-read if you manage a browser fleet. The capability is genuinely useful. It is also, per this PoC, genuinely dangerous when a user misreads a prompt.

The model didn't invent a new class of attack. It just refused to discard the dumb idea, and the dumb idea turned out to compile.