Browser-Only Ransomware Exploits LLM Hallucinations and File System API

Check Point Research published a proof-of-concept on July 1, 2026, demonstrating a complete ransomware chain that executes entirely within a browser tab — no download, no installation, no elevation of privilege required. The research, by Alexey Bukhteyev, combines two converging trends: the expanding capability surface of browser APIs and the willingness of some LLMs to generate exploitation techniques for those APIs when prompted. The result is a practical attack technique that existing endpoint security controls are structurally unable to detect.

The attack chain

The proof-of-concept, which Check Point named “InfernoGrabber v9.0” and disguised as a Discord avatar upscaler, follows four steps after a user lands on the malicious site:

Permission solicitation. The site presents a convincing AI enhancement interface and prompts the user to select a folder for processing. This is a standard interaction pattern for legitimate web applications — photo editing tools, document processors, and productivity apps routinely request folder access. The browser displays a native permission dialog; the user clicks confirm.

Enumeration. With permission granted, the JavaScript application walks the directory tree, cataloguing file names, sizes, and types. The enumeration happens client-side with no server round-trip. From the perspective of any network monitoring tool, the page has loaded and is sitting idle.

Exfiltration. File contents are read into browser memory and transmitted via HTTP POST to attacker-controlled infrastructure. At this stage the attacker has a copy of the victim’s files regardless of what happens next. Check Point’s test sample used chunked upload to avoid triggering size-based network alerts.

Encryption and overwrite. The original files are read, encrypted using the Web Crypto API’s AES-GCM implementation (a legitimate browser cryptography interface), and written back to disk via the File System Access API. The originals are overwritten. A ransom note is written to the directory.

The entire chain runs in JavaScript. There is no compiled binary, no shellcode, no process injection. SHA256 of the proof-of-concept sample: 07c39f79ab92fb21557b82283472dce1c112f577d796111fb752c3c6d84c86b5.

This is not slopsquatting

It is worth being precise about what the LLM hallucination component means here, because it is easy to conflate this with slopsquatting — the supply chain attack where LLMs hallucinate package names that attackers then register.

In Bukhteyev’s research, the hallucinations are playing a different role. When asked to describe the File System Access API’s capabilities or to generate code that uses it, LLMs sometimes produce descriptions that overstate what the API permits, suggest non-standard usage patterns, or generate code that — when tested — turns out to work despite not matching official documentation. These hallucinated descriptions function as attack blueprints: they describe attack paths that a motivated researcher might not have found by reading the W3C specification alone.

The more direct LLM finding is about model differences in refusal behaviour. Bukhteyev tested multiple frontier models with prompts requesting File System Access API exploitation code. DeepSeek showed significantly weaker refusal rates than OpenAI or Anthropic models, producing functional exploitation code across multiple prompt variants. This is a concrete, measurable safety gap between frontier model families — not a theoretical concern about capability.

Android exposure

The research flags Android as particularly exposed. Chrome 132 and later on Android exposes the photo library through the File System Access API rather than requiring the user to navigate to a specific folder. A user who grants the permission believing they are allowing a photo enhancement app to access one image may in practice be granting access to their entire photo library.

The implication for enterprises with Android devices in BYOD or managed device programmes: a user clicking through a browser permission prompt on their phone — the same UI interaction they perform dozens of times a week for legitimate apps — may be granting a malicious web application read-write access to everything in their camera roll.

Why endpoint controls miss this

The technique bypasses endpoint detection for structural reasons, not because of any specific evasion logic. EDR products detect malicious behaviour at the OS process level — suspicious process creation, unusual file system calls from unexpected executables, injection into running processes. A browser tab executing JavaScript through the browser’s own rendering engine produces none of these signals. The file writes to disk are legitimate, originating from a signed system process (the browser), through a permissions model the OS considers authorised.

Network detection is similarly limited. The exfiltration traffic is outbound HTTP from a browser — indistinguishable from normal browsing at the packet level without deep content inspection and anomaly detection on binary payloads.

Browser-native security controls do enforce the permission model: the user must click through the native dialog. But social engineering that produces permission grants is well-understood and consistently effective. The engineering challenge for defenders is not the cryptography or the JavaScript — it is the human interaction that opens the door.

Defensive posture

For security teams, the actionable response depends on the environment:

Enterprise managed browsers can enforce Content Security Policy configurations and browser extension policies that restrict which sites are permitted to invoke the File System Access API. Chrome Enterprise and Edge for Business both support this at policy level.

User training needs to explicitly address browser permission prompts as a social engineering vector — not just email attachments and download warnings. The framing should be simple: unexpected folder access requests from unfamiliar web applications should be declined and reported.

Network monitoring teams should review whether their DLP or CASB tooling has detection logic for large binary payloads exfiltrated via browser POST requests. Most DLP deployments are tuned for document-format detection; encrypted binary blobs sent in chunks may not trigger existing rules.

The hash of Check Point’s proof-of-concept (07c39f79ab92fb21557b82283472dce1c112f577d796111fb752c3c6d84c86b5) can be used for retrospective threat hunting in environments with endpoint telemetry.