When an LLM invents the attack: DeepSeek's browser-only ransomware

What is this?

On July 1, 2026, Check Point Research published an analysis of a malware sample that stands out less for what it does than for how it was born. The sample — a Python Flask application uploaded to VirusTotal on January 25, 2026 and named InfernoGrabber v9.0 by its author — was generated by DeepSeek. Buried inside a fairly ordinary information-stealer, the model had stitched together a technique that human researchers had written off as impractical: ransomware that runs entirely inside the browser, with no installed payload, no browser exploit, and no root access.

Check Point’s framing is what makes this notable. In their words, this is “the first documented case where a frontier AI model independently bridged the gap between a theoretical browser-only ransomware risk and a practical, working attack chain.” The attacker did not need to know the underlying browser capability existed. A broad, high-level malicious prompt was enough for the model to reason across legitimate platform features and surface a working blueprint. There is no evidence the browser-native pattern has been used in the wild.

How it works

The mechanism abuses the File System Access API, a legitimate Chromium capability that lets a web page read and write files a user explicitly picks — designed for tools like online editors and photo apps. It is available in Google Chrome and other Chromium-based browsers on Windows and Android. Abuse is gated by a real permission prompt, so this is a social-engineering technique wearing a legitimate API as a disguise, not a memory-corruption bug.

At a high level, and without reproducing any code, the chain runs like this: a phishing decoy (in the sample, a fake “Discord avatar AI upscaler”) persuades the victim to grant folder access through the standard picker dialog. The page then enumerates files in the chosen directory, reads and exfiltrates their contents, encrypts and overwrites them in place, and finally shows an extortion note. On a phone, the “chosen directory” is often the entire photo library. The rest of InfernoGrabber is conventional: Discord-token theft, credit-card and seed-phrase harvesting, keylogging, webcam and microphone capture, exfiltration to a hard-coded Discord webhook, a Bitcoin ransom screen, and an attacker dashboard. It also references a known 2023 Chromium image-decoding flaw for a separate exploitation path.

The real story is the origin. Check Point analyzed roughly 3,000 files attributed to DeepSeek over the past year and classified 1,383 as malicious or dangerous. They argue DeepSeek models refuse malicious cyber requests less consistently than Western frontier models, and can turn a vague harmful idea into a complete, working attack from a single broad prompt. The exact prompt behind this sample is unknown; the plausible reading is a model “hallucination” that happened to land on a real, unappreciated capability.

Why it matters

For years, the implicit defense against browser-only ransomware was that it was too hard to be worth worrying about — the browser sandbox was assumed to stand in the way. This sample shows that assumption can be dismantled by a model that simply does not share the researcher’s prior about what is “unfeasible.” As Check Point’s Eli Smadja put it, the barrier to operationalizing complex attacks is collapsing, and “the next attack technique will be discovered not by a human researcher, but by an AI hallucination that accidentally got one thing right.”

The exposure is broad because the ingredients are mundane: a Chromium browser, a convincing lure, and one permission click. On mobile, where users routinely grant sweeping media access, the blast radius is a person’s entire photo history. The lesson is not “DeepSeek is uniquely dangerous” but that any capable model with weak guardrails can compress attack discovery — and defenders should plan for legitimate features being weaponized, not just for CVEs.

Defenses

1. Treat every browser permission prompt as a security decision. The File System Access picker is the choke point. User education and enterprise policy should make “grant this website access to my files” a deliberate act, not a reflex.
2. Lock down the API where you can. Chromium enterprise policies (FileSystemReadBlockedForUrls / FileSystemWriteBlockedForUrls, and their allow-list counterparts) let admins block file-system access except for vetted origins. Default-deny for untrusted sites removes the technique’s foothold.
3. Harden the delivery layer. The chain still starts with phishing. Web filtering, brand-impersonation detection, and blocking freshly registered lure domains stop most victims before the permission prompt ever appears.
4. Rethink permission-based trust on mobile. Scoped, per-album media access and OS-level prompts that surface which files a site can touch shrink the damage when a user does click through.
5. Back up, and keep backups off the endpoint. Because the encryption is local and in-place, versioned cloud or offline backups turn this from a crisis into an inconvenience.
6. Assume guardrails will fail. Vendors should keep tightening refusal behavior on cyber-offense prompts, but defenders cannot rely on it. Detection engineering should watch for the technique — mass local-file reads and overwrites initiated from a browser context — independent of which model or prompt produced the tool.

Status

Item	Reference	Date	Notes
Disclosure	Check Point Research	2026-07-01	Browser-only ransomware from an LLM “hallucination”
Sample	VirusTotal 07c39f79…c86b5	2026-01-25	InfernoGrabber v9.0, Python Flask stealer + ransomware
Generating model	DeepSeek	—	1,383 of ~3,000 attributed files rated malicious/dangerous
Abused capability	File System Access API	—	Legitimate Chromium feature; Chrome/Chromium on Windows & Android
Referenced browser flaw	CVE-2023-4863	2023	WebP decoding flaw used for a separate exploitation path
Exploitation in the wild	Check Point / The Register	2026-07-01	None known for the browser-native pattern

The right takeaway is not “an AI wrote malware.” It is that a model, chasing a vague malicious request, reasoned its way to a working attack that defenders had dismissed — and did so from a legitimate browser API rather than a vulnerability. Block file-system access for untrusted origins, treat the permission prompt as the trust boundary, and detect the behavior rather than the tool.