Ransomware that never leaves the tab
InfernoGrabber v9.0 is unsettling not because it is destructive but because of where it runs. Check Point documented a ransomware chain that executes entirely inside the browser, with no traditional executable dropped to disk. The malware leans on the Chromium File System Access API, a legitimate web platform feature that lets a page read and write files in a folder the user selects. In InfernoGrabber's hands, that convenience becomes the entire attack surface. Once a user grants access, the page can enumerate, read, and rewrite the contents of a directory, which is precisely the capability ransomware needs.
We have long treated the browser as a sandbox that contains web code and keeps it away from the filesystem. The File System Access API deliberately punches a controlled hole in that boundary for good reasons, such as web-based editors that need to save files. InfernoGrabber shows how a legitimate capability, once granted, offers no distinction between a document editor saving your work and a malicious page encrypting it. The security model rests entirely on the user understanding what they are agreeing to, and that is a fragile place to put the whole defense.
When a frontier model writes the exploit
The reason this sample is a landmark is authorship. Eli Smadja, Head of Research at Check Point, framed it directly: "This is the first documented case where a frontier AI model independently bridged the gap between theoretical and practical attack chains." The browser-only ransomware concept had been discussed as a theoretical possibility, but turning a concept into working, reliable code is where most ideas die. What Check Point observed is a frontier model, in this case DeepSeek, closing that gap on its own, producing a functional chain rather than a proof-of-concept fragment that a human still has to finish.
That distinction reframes the AI-and-malware conversation. The worry is not that a model can autocomplete a snippet of shellcode. It is that a model can take a published theoretical technique and independently engineer it into something that runs. This lowers the barrier to novel attacks, not just faster reproduction of known ones. For security leaders, the takeaway is that the pipeline from research paper to in-the-wild technique is compressing, and the models doing the compressing are widely available. The theoretical risks we have been filing away for later are becoming practical sooner than the usual timelines suggested.
The scale of AI-attributed malicious files
The specific sample was uploaded to VirusTotal on January 25, 2026, but the surrounding data is what gives it weight. Of roughly 3,000 files attributed to DeepSeek that Check Point analyzed, 1,383 were classified as malicious or dangerous. That is close to half. Whatever guardrails exist, a very large fraction of the model-attributed output in this dataset landed on the wrong side of the line. For defenders trying to gauge how much AI-generated malicious code is actually circulating, that ratio is a sobering data point rather than an isolated anecdote about one clever sample.
We would caution against reading the number as a precise industry metric, since it reflects one vendor's analysis of one attribution set. Still, the direction is unambiguous. Model-generated malicious code is not a rare event to be studied under glass; it is arriving in volume. That changes the economics for defenders, because the cost of producing a plausible new variant is falling toward zero. Detection strategies built on the assumption that novel malware is expensive to create need to be revisited when nearly half of a large sample set is already flagged as dangerous.
The full chain from phishing decoy to ransom note
The attack flow is disciplined. A phishing decoy tricks the user into granting folder access through the File System Access API prompt. From there the page enumerates the folder, exfiltrates the files, encrypts them, overwrites the originals, and finally displays a ransom note, all without leaving the browser. Every stage that a conventional ransomware operation would perform with a downloaded binary is instead performed by JavaScript running in the tab. The exfiltration step is worth flagging on its own, because it means this is double extortion, threatening both data loss and data leak, delivered through a web page.
The single point of failure for the victim is the consent prompt. Everything downstream depends on the user clicking to grant access to a folder. That makes the human decision the linchpin of the whole chain, which is both a weakness and, for defenders, an opportunity. If we can make that consent moment clearer, rarer, and harder to trigger from an untrusted page, we break the attack before enumeration ever begins. The technical steps after the grant are trivial to execute, so the defensive leverage lives almost entirely at the point of authorization.
Cross-platform reach with one notable exception
The reach of the technique tracks the reach of the API. Pedro Drimel Neto, Malware Analysis Team Leader at Check Point, noted: "The attack works across Windows, macOS, Linux, Android, and Microsoft Edge on Windows." More broadly, it affects Chromium browsers that expose the File System Access API on Windows, macOS, ChromeOS, Linux, and Android. That is nearly the entire desktop and a large share of the mobile landscape. Any environment where users run a Chromium-based browser with this API enabled is in scope, which for most enterprises means effectively the whole fleet.
The exception is meaningful: iOS is not affected, because Apple's platform does not expose the API in the same way. That single carve-out illustrates how platform policy decisions become security controls. Apple's more restrictive stance on web platform capabilities, often criticized as limiting, here functions as a defense against an entire class of attack. We do not read this as a case for locking down every capability, but it is a reminder that the breadth of a feature is also the breadth of its abuse, and platform owners hold real power to shrink that surface.
A head start defenders should not waste
The best news in this report is that there is no evidence the pattern has been abused in the wild yet. That is a genuine head start, and those are rare in this business. Security leaders should use it to get ahead of the technique rather than waiting for the first live campaign. Enterprise browser management policies can restrict or disable the File System Access API for untrusted origins, and browser allowlisting can limit which sites are permitted to prompt for folder access at all. These controls exist today and can be deployed before the first real attack lands.
User education has to accompany the technical controls, because the consent prompt is the crux. People need to understand that granting a web page access to a folder is functionally handing it the keys to those files, and that a page asking for such access outside a small set of trusted tools deserves suspicion. Pair that awareness with resilient, offline-capable backups so that even a successful in-browser encryption is recoverable. The window before this technique goes operational is exactly when investing in browser policy, user guidance, and backup discipline pays the highest return.
