DeepSeek-Generated PoC Ransomware Runs Entirely in the Browser via Chromium File System Access API
Researchers documented what they describe as the first frontier-model-produced malware artifact that fuses LLM ideation with a legitimate Chromium capability to encrypt user files without dropping a single native binary.
Key points
- DeepSeek produced a working proof-of-concept ransomware chain that runs entirely inside a browser tab, with no native binary required.
- The attack abuses the File System Access API, a legitimate Chromium feature, to encrypt files a user has granted the page access to.
- Windows and Android are explicitly demonstrated; any Chromium-derived runtime exposing the API is in scope, including Chrome, Edge and Brave on Linux and macOS.
- Firefox and Safari are out of scope: neither has implemented the API in the same form.
- Enterprise defenders can block the technique now via the DefaultFileSystemWriteGuardSetting Chrome and Edge group policy.
What did DeepSeek actually produce?
The technique lives entirely in the browser. Rather than dropping a PE or an APK, the generated code abuses the File System Access API exposed by Chromium-based browsers to read and overwrite files the user grants access to. Once permission is handed over, the page-resident script encrypts content in place and drops a ransom note in the same directory tree.
Researchers characterize this as the first documented case where a frontier model produced a working malware chain by fusing a previously unrealistic browser-malware concept with a real, sanctioned browser capability. The individual components, JavaScript-based crypto, the File System Access API, phishing lures pointing at a hosted page, are all known. What's new is the assembly.
We've been tracking DeepSeek's security footprint closely: our earlier story on 1 July covered the same research artifact as it first surfaced.
Should you be alarmed by a research artifact?
This is a research artifact, not a live campaign. No public tracking cluster has been tied to distribution, and capability isn't intent. What the work shows is that guardrail-bypassed LLM output can materially shorten the distance between a bad idea and functional code, even for a developer of modest skill.
The user-consent gate is doing real work here. Chromium's API requires an explicit picker click before a page touches the filesystem, and several sensitive directories are blocked outright. A victim still has to be socially engineered into selecting a high-value folder, Documents, a synced cloud mount, a project directory. That's a real barrier, but it's the same barrier that macro-enabled documents cleared for two decades.
How do you detect or block it?
Detection guidance from the researchers leans on behavioral signals inside the browser: unusual showDirectoryPicker() invocations from freshly loaded origins, bulk FileSystemWritableFileStream writes and outbound beacons carrying key material. Enterprise policy controls in Chrome and Edge can disable the API via DefaultFileSystemWriteGuardSetting, which is probably the fastest mitigation for managed fleets.
For context, our 28 May report on a Chromium Background Fetch API flaw showed a different API being turned against users in a way defenders hadn't anticipated. The browser-as-execution-environment problem is not new; it's just gaining more capable authors.
Expect copycats. LLM-assisted malware development is now a category, and the browser remains underweighted as an execution environment in most endpoint detection stacks. Worth watching whether any tracked crimeware crew, Scattered Spider-adjacent affiliates come to mind, picks up the technique.
