ITInnovationStation

For decades, ransomware attacks have followed a recognizable pattern. A malicious executable reaches a device through phishing, an exploited vulnerability, stolen credentials, a compromised remote-access service or a poisoned software package. The payload executes through the operating system, searches for valuable files, encrypts them and displays a ransom demand.

Security controls were consequently designed around that model. Antivirus products inspect executables. Endpoint detection and response platforms monitor process creation. Application-control policies block unauthorized programs. Mobile operating systems restrict application installation, while users are repeatedly warned not to download suspicious files.

But what happens when there is no executable?

What if the “payload” is simply a website running ordinary JavaScript inside a legitimate browser?

In July 2026, Check Point Research published a controlled proof of concept demonstrating a technically novel form of browser-native ransomware. The technique abused Chrome’s legitimate File System Access API to read, modify and potentially exfiltrate files from a folder selected by the victim. It required no Android application package, no native executable, no browser vulnerability, no privilege escalation and no root access.

The attack depended on something much simpler: convincing the victim to approve a browser permission request.

At the time of Check Point’s analysis, researchers had not found evidence that this exact browser-native ransomware pattern was being used in widespread real-world campaigns. The original AI-generated sample that inspired the investigation was incomplete and unreliable. Nevertheless, Check Point demonstrated that the core concept could be converted into a functioning proof of concept with relatively little additional effort.

That distinction matters.

This is not evidence of a new ransomware epidemic. It is evidence that a previously theoretical browser risk can be turned into a practical attack workflow.

The Browser Is Becoming an Application Platform

The modern browser is no longer merely a document viewer.

Web applications can edit photographs, compile software, conduct video conferences, access cameras and microphones, communicate with hardware devices and operate as full development environments. Browser-based versions of applications such as code editors need functionality that was once available only to native desktop software.

The File System Access API was created to support that evolution.

With the user’s permission, a compatible web application can open files, enumerate the contents of a selected directory and write changes directly back to the local filesystem. A browser-based photo editor, for example, could open a folder containing images, process them and save the modified versions without forcing the user to download each file manually. A browser-based integrated development environment can open a project folder and edit its source files much like an installed application.

Chrome’s documentation explains that a website can use a directory picker to obtain a handle to a user-selected folder. If read-and-write access is approved, the application can enumerate files inside that folder and create writable streams that save changes directly to disk. These operations require browser-mediated permission, and sensitive operating-system locations may be restricted.

The capability is legitimate, useful and intentionally powerful.

That power is also what makes it attractive to an attacker.

From an AI Hallucination to a Real Attack Primitive

Check Point’s research began with an unusual AI-generated malware sample attributed to DeepSeek.

The sample presented itself as an AI-powered Discord avatar upscaler. Behind the interface, its code attempted to combine numerous malicious capabilities, including keylogging, clipboard monitoring, credential theft, webcam access, screenshots, persistence and ransomware.

Most of those features did not work as claimed.

A normal website cannot freely inspect the operating system, monitor every keystroke, extract arbitrary browser credentials or behave like a privileged native application. Browser isolation, origin controls and permission boundaries prevent much of that behavior.

The sample was therefore partly an AI hallucination: code produced to satisfy an ambitious malicious request without correctly accounting for the browser’s security restrictions.

However, one portion of the design was grounded in a real browser capability.

The JavaScript referred to functions for opening files, selecting directories, recursively enumerating a selected folder, reading file contents and sending those contents to a backend service. It also contained the beginnings of a ransomware-style workflow.

The AI-generated sample had connected an unrealistic idea—universal malware operating entirely from a web page—to the very real File System Access API. Check Point then investigated whether that connection could be made operational.

Researchers found that it could.

Using a controlled environment, they developed a functioning proof of concept disguised as an AI image-enhancement service. The victim was encouraged to select a photo folder so the site could supposedly process or improve the images.

That request did not appear inherently suspicious. A legitimate image-editing website might reasonably need access to photographs.

Once the victim selected the directory and approved the required permission, however, the website gained meaningful control over the files within the authorized folder.

How the Attack Would Work

The attack begins with social engineering rather than exploitation.

A victim could encounter a website advertised as:

• An AI photo enhancer
• An avatar generator
• A background-removal tool
• An image upscaler
• A file converter
• A document optimizer
• A browser-based backup utility

The site would invite the user to select a folder containing the files to be processed.

Chrome would then display a legitimate browser-controlled directory picker and permission prompt. The attacker would not need to forge this interface. The browser itself would ask the user to approve access.

After authorization, the malicious page could enumerate files within the selected directory. Depending on the permission granted, it could read their contents, send copies to an external server, transform the data and overwrite the originals.

A ransomware-style operation could conceptually proceed through five stages:

1. The lure: The website offers a seemingly useful service.
2. The permission: The victim selects a folder and grants the site file access.
3. Enumeration: JavaScript identifies files within the approved directory.
4. Impact: The page modifies, corrupts, encrypts or replaces the accessible files.
5. Extortion: The website displays a ransom demand or threatens to release stolen data.

The critical point is that the browser does not need to be compromised.

From the browser’s perspective, the website is performing operations the user authorized. The harmful intent exists in how the granted capability is used.

No Traditional Malware Installation

This model breaks several common assumptions about ransomware delivery.

There may be no downloaded executable for antivirus software to quarantine. There is no APK for the user to install on Android. There may be no suspicious child process launched from the browser. The attacker does not require root privileges or administrative rights. The proof of concept does not depend on defeating Chrome’s sandbox through a zero-day vulnerability.

The browser itself becomes the execution environment.

The malicious logic can be delivered as HTML and JavaScript from a website. File operations occur through a documented browser API, while the permission prompt is part of Chrome’s normal user interface.

This does not mean endpoint security products are helpless. Network inspection, browser telemetry, behavioral file monitoring, reputation services and backup protections may still expose or limit the activity. However, the technique can bypass detection assumptions centered on malicious binaries, executable reputation and conventional software installation.

The absence of a native payload also changes the victim’s perception.

Most users understand that installing an unfamiliar application carries risk. They may be significantly less cautious when opening a website and selecting a folder for what appears to be a legitimate online tool.

Check Point emphasized that users generally do not regard visiting a website as equivalent to executing malware. A polished AI-themed interface can make the permission request feel consistent with the service being offered.

Why Android Is Especially Interesting

The proof of concept is particularly significant on Android.

Chrome introduced broader File System Access support on Android beginning with Chrome 132. After user approval, compatible web content can access selected files and folders through the same general browser-mediated model used by desktop web applications.

Check Point tested the concept against photo directories on Android devices. The researchers found that users could select valuable image locations, including the root of the DCIM photo directory in the versions they examined.

That creates a compelling social-engineering opportunity.

An AI photo enhancer has an obvious reason to ask for access to photographs. A victim may believe the site is merely opening images for processing, without fully understanding that folder-level write permission can allow the site to modify many files.

On a desktop computer, the Pictures folder may be important but is often separate from the organization’s core documents and application data. On a mobile device, the photo library may contain years of irreplaceable personal information.

It may include:

• Family photographs
• Scans of identification documents
• Banking screenshots
• Recovery codes
• Medical information
• Travel documents
• Images of business records
• Photographs of handwritten passwords
• Sensitive conversations
• Work-related images

An attacker might not even need strong encryption to create leverage. Corrupting files, replacing their contents or exfiltrating sensitive images before deletion could support extortion or blackmail.

Check Point reported that the demonstrated mobile technique was practical on Android Chromium browsers but not on iOS. Chrome on iOS uses Apple’s WebKit engine, which does not expose the same File System Access primitives to websites.

The Attack Is Powerful, but It Is Not Unlimited

Browser-only ransomware should not be confused with full-system ransomware.

The website does not automatically gain access to the entire hard drive. The victim must select a file or directory, and the browser may block or constrain access to sensitive system locations.

Check Point found that broad access to locations such as the user’s home directory, Windows system folders, Program Files, application data, browser data, Documents, Desktop and Downloads was restricted or constrained in the tested Chromium implementations.

The attack is therefore limited by the scope of the user’s selection and the permissions Chrome grants.

A malicious webpage cannot simply load in the background and begin encrypting every reachable disk, mapped network drive and server share. It does not automatically inherit administrative privileges, disable security products, delete shadow copies or spread laterally through the network.

It is more accurate to describe the concept as permission-scoped browser ransomware.

The damage may still be severe when the selected folder contains high-value information, but the potential impact is narrower than that of mature enterprise ransomware deployed with elevated access.

This limitation is also one reason the social-engineering design matters so much. The attacker needs a believable reason for the victim to select a valuable directory.

A photo utility naturally targets Pictures or DCIM. A document-conversion service could request a project folder. A browser-based coding assistant could ask for a source-code directory. A backup service might request an entire collection of files.

The best lure is the one in which dangerous access appears essential to the advertised feature.

The API Designers Anticipated Ransomware Risk

The possibility of ransomware abuse was not entirely unforeseen.

The File System Access specification explicitly identifies ransomware as a security consideration. It recommends restricting access to sensitive directories and allows browser vendors to control the granularity at which write access is granted. The specification also warns that users may authorize access to more information than they realize, particularly when selecting directories containing large numbers of files.

The proof of concept does not therefore expose a conventional software vulnerability that can simply be patched.

It demonstrates a design tension.

For a web-based editor to be useful, it must be able to modify files. For the permission to remain understandable, the browser must present a workflow that ordinary users can complete. But any capability powerful enough to support a legitimate editor may also support destructive modification after permission is granted.

The security boundary is consequently not only technical. It depends on whether the user understands:

• Which website is requesting access
• Which folder is being shared
• Whether access is read-only or read-and-write
• How many files the folder contains
• Whether the site truly requires modification rights
• How long the permission may remain active

Chrome can display a real permission prompt, but it cannot guarantee that the website’s explanation is honest.

Why AI Matters to the Story

The most important lesson may not be the specific ransomware proof of concept.

The original sample was technically confused. It attempted numerous browser capabilities that could not function as written. Yet while trying to satisfy an unrealistic malicious request, the model discovered a legitimate API that could accomplish part of the attacker’s objective.

This illustrates a new role for generative AI in offensive research.

An inexperienced attacker may not know that the File System Access API exists. The attacker may not understand browser permissions, directory handles or writable streams. But the attacker can describe a desired outcome in natural language and ask a model to connect that objective to available platform features.

Even when the initial output is broken, it may contain one useful idea.

The user can then test, refine and regenerate the components at low cost. AI does not need to invent a new vulnerability. It can create novelty by combining existing capabilities in ways that defenders have not previously encountered in real campaigns.

Check Point concluded that AI may help bridge the distance between theoretical risks and practical attacks by identifying combinations humans have not yet operationalized.

How Users and Organizations Should Respond

The immediate defense is not to disable every modern browser capability. It is to treat folder-access permission as a serious security decision.

Users should avoid giving unknown websites access to folders containing sensitive or irreplaceable data. When testing an unfamiliar browser utility, they should copy a small number of files into a temporary directory rather than granting access to an entire photo library or project folder.

A request for write access deserves particular scrutiny. A website that only needs to upload or analyze a file may not require permission to modify the original.

Organizations should also consider browser governance as part of endpoint security. Managed browser policies, web filtering, application allowlisting and user education should address powerful web APIs rather than focusing exclusively on downloaded malware.

Backups remain critical. Important files should exist in protected versions that cannot be overwritten through the same user context. Cloud synchronization alone may not be sufficient if destructive changes are rapidly synchronized to every copy. Version history, immutable retention and offline backups provide stronger recovery options.

Security teams should also monitor for unusual patterns in which a browser process reads and rewrites many user files shortly after access to a newly registered or low-reputation domain. This is a behavioral detection challenge rather than a simple malware-signature problem.

A Warning, Not Yet an Epidemic

Browser-only ransomware is technically novel, but it should not be exaggerated.

As of Check Point’s July 2026 publication, researchers had not observed the demonstrated technique as an established in-the-wild ransomware pattern. The original sample was incomplete, and the attack still requires a victim to visit a malicious website, select a useful folder and approve meaningful access.

Those constraints are significant.

Nevertheless, many successful attacks already depend on users approving fraudulent MFA prompts, opening malicious documents, authorizing OAuth applications or entering credentials into convincing websites. Requiring user interaction does not make an attack unrealistic.

The proof of concept reveals a change in where malware-like behavior can occur.

Ransomware no longer necessarily needs to arrive as a program. A website can become a temporary application, the browser can provide the required file access and a legitimate permission can become the point of compromise.

The browser has not been exploited.

The user has authorized a capability without understanding its consequences.

That is what makes browser-only ransomware important. It is not simply a new way to encrypt files. It demonstrates how the expanding power of web applications is erasing the traditional boundary between visiting a website and running software.

The next ransomware payload may not ask to be installed.

It may ask to enhance your photographs.