SURIQ
The security boundary for a new class of ransomware is not your antivirus, your firewall, or your endpoint agent. It is the small permission dialog your browser shows when a website asks to open a folder. Click Allow on the wrong page, and code running inside an ordinary browser tab can read and overwrite the files in that folder, with nothing installed on the machine for security software to find.
That is the takeaway from new research from Check Point, published this week. Their proof of concept encrypts a victim's files entirely from within the browser. There is no downloaded executable, no exploited vulnerability, and no CVE. The whole attack rides a legitimate, documented browser feature that editors and design tools use every day.
What browser-only ransomware actually is
Browser-only ransomware is malicious code that runs inside a web page and never leaves it. Traditional ransomware has to land a program on the disk and run it, which gives antivirus, endpoint detection, and application allowlists a file and a process to inspect. This technique skips all of that. The encryption happens in the browser tab, using the same web features a legitimate photo editor or code editor would use.
The feature at the center is the File System Access API, available in Chromium browsers. It lets a web application ask the user to pick a file or a folder, and once the user approves the picker, the page can read, write, and overwrite files inside that selection. That is exactly what a browser-based image editor needs to save your work. It is also everything ransomware needs to encrypt your documents in place.
An AI chatbot connected the dots
The origin is the part that will get the headlines. Check Point's Alexey Bukhteyev started from a sample that DeepSeek generated when prompted, in broad terms, for a single malicious tool that combined data theft and file encryption. The model's output was incomplete and did not work reliably. What made it notable is how it failed: instead of writing a conventional Windows program, it mapped the abstract idea of ransomware onto real browser features, reaching for the File System Access API to do the file damage.
The researchers then turned that rough idea into a working proof of concept. The lesson is not that an AI wrote functioning malware, because it did not. The lesson is that a model can recombine legitimate, well-documented platform features into an attack blueprint a human might not have assembled, and it lowers the expertise needed to get there. It is the same pattern behind AI coding agents that run the commands they just blocked and an AI agent tricked into taking over its own host: the model connects trusted capabilities into something harmful. The underlying primitive was not even new. Academics at Florida International University described the same browser-based approach on the same API in a peer-reviewed paper at USENIX Security 2023. What changed is that the idea is now cheaper to reach.
Why your endpoint tools stay blind
This is the detail that should worry a defender more than the AI angle. Endpoint protection is built to watch files and processes: a new executable, a suspicious script, a process touching hundreds of documents in seconds. Browser-only ransomware presents none of those signals. The only process on the machine is the browser itself, a signed and trusted application doing something browsers are allowed to do. The Florida International University team tested their version against five antivirus products and found no malicious payload for them to catch, because there is no payload on disk. When the malicious action wears a trusted process, the agent's silence becomes the problem, the same gap we saw when endpoint-killer tools became a shipped product.
File-encryption behavior can in principle be spotted, but the sensor has to watch the right layer. A mass rewrite of files in a user's Documents or Pictures folder is the behavioral tell, whether a native program or a browser tab is doing it. If your detection only alarms on new or unsigned processes, a browser encrypting files sails straight through.
Where the real control sits
The defense for this class is not a better malware signature. It is governing the permission that makes the attack possible, and it can be done at the browser policy layer.
Managed Chrome exposes an enterprise policy for exactly this. FileSystemWriteBlockedForUrls blocks the write side of the File System Access API for specified sites, and DefaultFileSystemWriteGuardSetting can be set to BLOCK_FILE_SYSTEM_WRITE to stop sites from requesting write access at all, with an allowlist for the internal tools that genuinely need it. A matching read guard exists for the read side. For most business fleets, almost no website has a real reason to write into a local folder, so blocking by default costs little.
Three more things hold up here:
- Treat the folder-access prompt as a real security decision. It is the same kind of grant as installing software. Users should approve it for tools they trust and deny it everywhere else.
- Keep offline or versioned backups. The recovery story for browser-only ransomware is the same as for any ransomware: a copy the attacker cannot reach beats any detection.
- Watch bulk file changes, not just new processes. A detection that keys on rapid modification of documents catches the behavior regardless of what is driving it.
How exposed are you right now
Two facts keep this in proportion. First, it is a proof of concept. Check Point has not reported the technique in a live campaign, so treat it as a demonstrated capability, not an active threat this week. Second, the exposure is narrower than it sounds, and it depends entirely on the browser.
| Browser | File System Access API | Reach if granted |
|---|---|---|
| Chrome and Chromium, desktop | Yes, since version 86 | Any folder the user picks |
| Chrome, Android | Yes, since version 132 | Photo and video folders only |
| Edge, Brave, other Chromium | Yes | Same as Chrome |
| Firefox | No write-capable picker | Not exposed |
| Safari | No write-capable picker | Not exposed |
Only Chromium browsers ship the write-capable picker, so Chrome, Edge, Brave, and their relatives are in scope while Firefox and Safari are not. On desktop the reach is any folder the user selects. On Android, Chrome 132 and later limits it to the photo and video directories, which still holds a lot of what an ordinary person would pay to get back.
The uncomfortable part is that nothing here is a bug to be patched. The File System Access API is working as designed, and it is genuinely useful. What this research does is move a documented risk from an academic paper into a form anyone can reach with a chatbot prompt. The permission dialog was always a security control. It is time to manage it like one.