As Amazon prepares for Prime Big Deal Days, its Fall Prime Day event on October 6-7, cybercriminals are already exploiting the anticipation surrounding one of the year’s largest online shopping events. New findings from Check Point Research reveal a significant increase in Amazon-related domains, alongside ongoing phishing campaigns and malicious websites designed to target online shoppers. Amazon-Related Domain Registrations Continue to Rise Check Point Research observed a steady increase in newly registered Amazon- and Prime Day-related domains in the months leading up to the event. New Amazon- and Prime Day-related domain registrations have risen for three straight months, climbing from […]
Torrent trackers have long been abused for distributing malicious software, disguised as popular films, games, and other content. Our previous research has shown that cybercriminals repeatedly turn to torrents as an initial infection vector, using trojanized cracks and installers to reach a large number of users. Installation guides for pirated software routinely instruct users to disable their antivirus, conditioning them to ignore the potential threats they are inviting onto their computers.
During our analysis of malware that leverages blockchain networks for its C2 infrastructure, we discovered a previously unknown modular, multi-stage framework that we dubbed MovieReaper. This report details the new crimeware campaign that began with the mass infection of users via compromised torrent tracker file storage. We have identified several hundred victims, including both individual users and organizations in multiple countries, such as Russia, Türkiye, Japan, Kenya, Uganda, and Colombia, as well as in several European countries like Spain, the Netherlands, Belgium, and Germany. We analyze the techniques for evading detection by security and sandbox solutions, and examine the capabilities of the modular framework.
Kaspersky products detect this threat as HEUR:Trojan.Win64.Agent.gen.
Technical details
Background
In mid‑August 2026, during our threat‑hunting efforts, we identified a large‑scale infection campaign involving previously unknown malware disguised as popular movies. The campaign affected both individuals and organizations across multiple countries. Our initial analysis revealed a common denominator: all of the victims had used torrent trackers. This finding prompted us to investigate the campaign further and analyze its distribution mechanism, overall scope, and unknown malware implants.
Initial infection and spread
Compromised torrent trackers are the primary vector used to distribute malware. During our investigation, we identified multiple user reports describing suspicious files being downloaded instead of the intended content.
For example, a user of a popular movie torrent tracker reported the following case on Reddit:
Further analysis of the attack revealed that instead of compromising torrent trackers, the threat actor modified a widely used public repository of torrent files, itorrents[.]org. As a result, the trackers that relied on the repository began inadvertently distributing malicious torrent files to their users. This approach is particularly dangerous because it lets the threat actor reach users of multiple trackers without having to compromise each platform individually.
As of the publication date of this report, the archive remains compromised. When a user attempts to download a torrent via a magnet link, the legitimate torrent archive returns a different torrent file. This malicious torrent leads to the download of the malware loader, used to deploy a framework that we dubbed MovieReaper.
The loader initiates the infection chain shown in the diagram below. Each stage of the chain is described in detail in the following sections.
Malware implants
The infection chain consists of several steps, where only the initial one is dropped on the disk before it is executed to avoid detection. The malware itself is not heavily obfuscated, apart from strings being encrypted with a custom stream cipher. Most of the countermeasures were aimed at avoiding detection by AV sandboxes.
Step 1: Loader
The most popular initial executable was distributed through torrent trackers under many different names (for example, the odyssey (2026) [1080p] [webrip] [5.1].exe), but the file hash (MD5: A0B13781EDD7CFDAB13D79AFFF3C83C1) was identical across all downloads. We have seen multiple different loaders, where the executable file disguises itself with a long filename and an icon of some well-known application. Most of the filenames are rather long, presumably to hide the EXE extension at the end.
After the user manually starts the application, it establishes a global mutex to ensure that only one loader is executed at a time. We have seen several mutex variations in our samples, containing a randomly generated string (in the example Global\fnulSktzSqvVLXHU). This executable then performs a series of operations in order to avoid detection by AV sandbox solutions.
While performing those operations, the malware avoids making LoadLibrary and GetProcAddress calls to acquire the addresses of required functions. Instead, it searches for loaded libraries by traversing the double-linked list taken from the Ldr field of the PEB and then performs manual parsing of the loaded DLL to calculate the function address.
After all initial checks have passed, the binary prepares to establish a network connection to a C2 web server to download the shellcode, map it to the RWX memory and execute. While doing so, the loader decodes the domain name https://deadhub[.]org and if connection to it has failed, it uses the IP address http://193.23.118[.]155 as a fallback and connects to it using plain HTTP. The malware chooses a random group of strings and uses them as a path in the HTTP request to download the parts of the shellcode.
While mapping the address space and executing the shellcode, the loader registers a vectored exception handler and rewrites the handler address in memory in order to perform a debug break. This, will not crash the program, but instead redirect controlflow to the function that actually makes a raw NtProtectVirtualMemory syscall (via a previously located “0x0F 0x05” syscall instruction inside ntdll). Then it calls the undocumented ntdll function EtwpCreateEtwThread, which is a popular alternative to CreateThread for code executionm, and executes the shellcode.
Step 2: Shellcode
The second stage of this malware performs an HTTPS request to the Solana blockchain at the endpoint /getAccountInfo endpoint for the account 6pnDGAiHgyPdmckM5Qt1YbanGzrX43WLEU159nRaNLDm. The data in field of the response contains the base64‑encoded address of a second C2, which is encrypted with a static XOR key located within the shellcode itself. To store data in this account, attackers used a simple Solana program (address: CSiY8bQLBYPdfPWkwipBzH6sijTVQVVsA279JQdvwHtL).
Utilizing the Solana blockchain as a storage layer for next-stage C2 endpoints substantially complicates infrastructure takedown efforts by defenders.
The second stage payload communicates with its C2 server strictly through HTTPS via a TLS-pinned certificate using the nanopb protobuf library as a container for transferred data. The main logic of the stage 2 implant contains several initial commands, where the most important is the one that parses the COFF file, loads it into memory, and executes the module_init function from it. This provides a convenient interface for extension of the command list, which brings us to the next stage of the payload.
Step 3: UAC Bypass and persistence
Notably, the recovered modules were compiled with symbols, which accelerated reverse engineering.
After receiving the next stage from the second C2 server, the newly loaded module performs several tasks right in the module_init function.
Stage 3 performs UAC Bypass and achieves persistence using public techniques, masquerades the original binary as C:\ProgramData\Microsoft\Windows\Telemetry\msedge.exe, and restarts itself.
The respawned process starts with the initial loader, but with a special command-line argument, which allows it to skip most of the anti-sandboxing checks and proceed straight to downloading the next payload. The executable proceeds with the same steps as before, but this time, instead of downloading the persistence and UAC bypass module, a new one is downloaded from the second C2 server. This is because the malware uses the beacon to send a flag to the remote server, indicating whether the implant is running from the Telemetry folder, which allows the C2 to distinguish between first-run and respawned instances.
Step 4: The final implant
The final module (“file manager”) exposes 21 commands that give the operator filesystem access on the victim host. This allows remote the operator to download, upload, and read files on the system; list and enumerate directories; manipulate files with create, copy, rename, move, delete, chmod, and symlink commands; and use preview and thumbnail commands to exfiltrate previews of images and files before actually extracting them.
We suspect that other modules may be loaded on demand if requested by the operator.
Infrastructure
During this malware campaign, attackers are using various commercial hosting providers for their C2 infrastructure (see the IoC section for details). Furthermore, as noted above, the campaign leverages the legitimate Solana blockchain via the RPC endpoint api.mainnet.solana.com to deliver the address of the second‑stage C2 server to the malware. This approach provides the attackers with decentralized storage for C2 addresses, adding an additional layer of resilience and making it more difficult for defenders to disrupt the campaign by simply blocking the IP addresses of the C2 servers.
Victims
The observed campaign targeted both individuals and organizations across Europe, Asia, Africa, and Latin America, with infection attempts identified in Russia, Spain, Germany, Finland, Türkiye, Japan, Nepal, Kenya, Tanzania, Ghana, Uganda, Colombia, the Netherlands, Belgium, and other countries. The targeted organizations span a wide range of sectors, including enterprise, government, IT, consulting, retail, transportation, and agriculture.
Conclusions
Our research uncovered activity by the same actor dating back to October 2025. Although the campaign has evolved over time, with the malware authors expanding their arsenal and making the loader harder to detect, the pattern remains the same. This includes encoded strings, parts of shellcode downloaded through plain HTTP, and several techniques used to avoid sandboxes and virtual machines. We will continue monitoring this actor’s activity to catch new potential threats.
The first stage offers the clearest opportunity to disrupt this campaign: it relies on a single specific domain name and a single IP address to serve the shellcode, so taking down this server would prevent subsequent infection stages. This includes the second-stage payload, which uses the Solana blockchain network for a C2 and is therefore more resistant to conventional infrastructure takedowns.
However, this framework’s self-containment, modularity and in-memory execution has potential for reuse in later campaigns with minimal rework.
Imperva Threat Research identified a series of remote denial‑of‑service vulnerabilities in GraphQL Java, one of the most widely used libraries for GraphQL in the Java ecosystem.
In this blog, we’ll deep dive into these vulnerabilities, analyze their impact, and provide recommendations to protect your environment. If your endpoints are protected by Imperva Web Application Firewall, your systems are already protected against these threats.
Introduction
GraphQL Java is the engine beneath Spring for GraphQL, Netflix DGS, and Atlassian’s own products. With over one million downloads per month and ten years of production use, it is a natural choice for any team building a GraphQL API on the JVM.
Over the last few years, multiple types of DoS attacks have been identified across GraphQL implementations. These vulnerabilities can lead to either denial of service or, in cloud-billed environments, excessive cost consumption. In response, the industry converged on a set of protective controls, like depth limiting, query complexity budgets, and field count caps. Apollo added query cost analysis and depth limiting, GitHub meters its public GraphQL API by computed node cost, and GraphQL Java also introduced additional controls.
However, these enhancements can leave blind spots earlier in the pipeline, before the server has even understood the request.
The DoS attack we found live in the first half of the pipeline, where the query is parsed and validated, and therefore independent from the schema, the resolvers, and any backend logic.
They were reported under GHSA-7p4r-9rcc-8vhv (still as draft) and fixed in versions 24.4, 25.1, and 26.1. Several products embedding the library were affected, including Adobe Experience Manager (AEM), Atlassian Confluence, and HAPI FHIR server, a widely used open-source implementation of the HL7 FHIR healthcare interoperability standard.
Request Processing
Fig. 1: GraphQL Processing High Level Pipeline
GraphQL was built around a simple idea: “GraphQL queries mirror their response.” In other words, the client describes exactly the data it needs, while the server determines how to retrieve and resolve that data. The query is then sent to a GraphQL endpoint, where it goes through a series of processing steps before the response is returned:
HTTP Request: The server receives the GraphQL query.
Lexing: The query is broken down into tokens.
Parsing: The tokens are turned into an Abstract Syntax Tree (AST) representing the query structure.
Validation: The query is checked against the GraphQL schema and its rules.
Execution: GraphQL invokes the appropriate resolvers to retrieve the requested data.
JSON Response: The results are assembled and returned to the client.
The distinction between these stages matters. A request can be rejected before execution because its syntax is invalid or because it does not match the schema. Only after passing these checks does GraphQL reach the resolvers, where the application and its underlying data sources are accessed.
For security research, this pipeline provides a useful way to understand the attack surface. Each stage processes attacker-controlled input in a different way, making it important to understand not only what GraphQL does, but also when and where it does it.
Parsing and Validation: A Closer Look
Before a server decides what data to return, it must first decide whether the request makes sense. Parsing breaks the raw query text into an Abstract Syntax Tree. This involves:
Resolving string literals: block strings go through a dedicated normalization routine that strips leading and trailing blank lines.
Constructing AST nodes for every value encountered: numeric literals are converted to BigInteger or BigDecimal at this point.
Validation walks the AST and checks it against the schema. This involves:
Field and type checks: do the requested fields exist? Do the argument types match?
Fragment validation: named fragments must not form cycles, directly or transitively
Limit enforcement: in GraphQL Java 26.0, maxDepth and maxFieldsCount are checked here.
Fragment Cycle Detection
Validation is where fragment cycle detection takes place. Named fragments are GraphQL’s reuse mechanism. Instead of repeating the same selection set in multiple places, a client defines it once and references it with a spread:
Fig. 2: Named Fragments in GraphQL
Fragments can themselves spread other fragments. The spec allows arbitrary nesting, but it forbids cycles: if A spreads B and B spreads A, resolving either one requires resolving the other first. The execution engine would recurse indefinitely. The same applies to indirect cycles across any number of fragments.
This check happens during validation, after parsing has produced the AST and before execution starts. At this point the server has a complete map of every named fragment in the document and every spread reference between them.
Cycle detection is pretty straightforward: for each fragment, follow its spread references transitively and check whether any path leads back to the starting node. If it does, the document is rejected with a validation error and execution never starts.
ValidateNoFragmentCycles is called once per FragmentDefinition in the document. Each call starts with a fresh HashMap.
For each fragment, it calls buildTransitiveSpreads, a depth-first traversal that follows every spread reference outward, building up the set of fragments reachable from the starting node.
The traversal tracks its current path in an ArrayList, and at each step calls ArrayList.contains to check whether the next node has already been visited.
Worst Case Scenario
We considered a document with the following chain of d fragments:
Fig. 3: Malicious Payload Structure
For each fragment, ValidateNoFragmentCycles starts a new traversal with a fresh HashMap. Since the traversal follows the entire chain, and ArrayList.contains iterates over the path of fragments visited so far, the cost of a single validation is O(d²).
Fig. 4: Processing of the First Fragment
Since this happens for all fragments, the overall complexity is O(d³), where d is the number of fragments in the document. Within the default 15,000-token limit, a single payload can contain up to around 1,800 fragments (~50 KB), which is sufficient to saturate a CPU core for several minutes at every request.
Why existing GraphQL protections may not help
Traditional GraphQL protections such as depth limits and field-count limits operate during validation. However, this attack specifically targets the validation step itself. Therefore, it hits before the protections can prevent the attack.
Following the reception of our report, graphql-java released a patch that introduces memoization. Once a fragment has been explored, it is marked as done and never re-traversed again. The same malicious payload is processed in a few milliseconds instead.
This finding was the most impactful, but it wasn’t the only one.
Additional Remote DoS Vulnerabilities
We identified the same underlying idea as one of the attack vectors previously identified in React Server Components (BigInt values, CVE-2026-23864), and another vector involving block string normalization routine, more impactful. Both fixed in 24.4, 25.1 and 26.1.
HAPI FHIR Use Case
HAPI FHIR is a Java server designed to store and serve medical data (patients, prescriptions, lab results) using the FHIR healthcare standard. Like many modern APIs, it exposes a GraphQL endpoint that clients can use to query this data.
Internally, HAPI handles GraphQL requests with its own parser, written specifically for FHIR, which knows how to resolve medical resources. But when a client asks for introspection (a standard GraphQL feature that returns the full list of available queries and types) HAPI delegates directly to graphql-java.
However, it’s possible to bypass HAPI’s custom FHIR resolver and route a non-introspection query straight to graphql-java.
This delegation is triggered by a simple string check: it relies on the presence of the string `__schema` in the body.
Therefore, simply starting the request with the following pattern (see Fig 5.) was enough.
Tested on a fresh c7i.2xlarge instance, with the latest HAPI server with graphql enabled, a single request took 150 seconds of validation. A single wave of multiple small requests could lock the server entirely for several minutes and pin all 8 CPU cores at 100% for more than an hour.
In this application, this attack vector could represent an alternative avenue for a threat actor lacking authorization to exfiltrate patient data (as HAPI’s authorization model governs GraphQL endpoint access and data read permissions independently), and still willing to cause impact.
The attack surface is further widened by HAPI’s default CORS configuration (allows any origin, Access-Control-Allow-Origin: *). In environments where no additional network controls are in place, this means the attack could be triggered from a browser: a healthcare worker opening a malicious link while connected to the internal network is sufficient to take down the FHIR server for everyone.
Who is Affected?
An application is potentially exposed when:
It uses an affected version of GraphQL Java;
It accepts attacker-controlled GraphQL documents;
The GraphQL endpoint is remotely reachable;
No upstream control blocks the malicious request.
Remediation
The fixes are available in GraphQL Java versions 24.4, 25.1, and 26.1 via PRs #4440, #4441.
For environments where an immediate upgrade is not possible:
Restrict access to affected GraphQL endpoints to authenticated or otherwise trusted clients where the application permits it.
Apply rate limiting and concurrency limits to restrict the number of GraphQL requests that can be processed simultaneously.
Monitor CPU utilization and GraphQL request latency for unusual increases that may indicate resource-exhaustion attempts.
As AI accelerates vulnerability discovery and exploitation, threat actors can increasingly scan a target environment in real time, identify weaknesses across its technology stack, and rapidly turn those findings into attacks. This reduces the time organizations must detect and remediate newly exposed vulnerabilities, making proactive and continuously enforced security controls increasingly important.
Affected organizations should upgrade to a fixed release as soon as possible. Until patches can be applied, additional controls at the application and network layers can help reduce exposure and limit the impact of potential attacks.
Imperva customers are protected against exploitation of these vulnerabilities. Imperva Threat Research will continue to monitor this threat and work to ensure that customers remain protected against emerging attack techniques targeting GraphQL and other widely deployed technologies.
Timeline
August 11 – We reported the security issue to GraphQL Java.
August 19 – Report Acknowledged.
August 23 – Fix released in versions 24.4, 25.1 and 26.1.
AI-assisted development has crossed a threshold. The question is no longer whether your IDE communicates with an AI, it’s how deeply that AI is now wired into your local environment. The Model Context Protocol (MCP) is one of the plumbing behind this shift: a JSON-RPC-based protocol that lets AI assistants invoke tools running on your machine. From setting a breakpoint, to running tests, or launching a debugger… all from a chat window.
DebugMCP is one of the extensions leading that charge. Published by Microsoft on GitHub, it exposes a local MCP server that gives any compatible AI agent (GitHub Copilot, Cline, Cursor, Codex, Windsurf, and others) direct control over the VS Code debugger. The value proposition is compelling: instead of pasting stack traces into a chat window and waiting for a suggestion, an AI agent can set breakpoints, step through code, inspect variables, and evaluate expressions autonomously.
We identified and reported a critical security issue in version 1.1.4. A remote attacker who tricked a developer into visiting a malicious webpage could achieve arbitrary code execution on that developer’s machine, in the background, without any further user interaction (drive by).
Following our report, the maintainers patched DebugMCP via commit 86776b2m. The fix was silently shipped (no version bump, no advisory) and is included in version 1.2.0 and later. We are publishing this report following the 90-day disclosure period.
We recommend updating to the latest available version.
Scope
The exploitability of this weakness was amplified by the context in which the software evolves.
Indeed, we’re talking about an opensource MCP server hosted on GitHub, that can be used as a standalone server. But this MCP server is also exposed as an extension in VSCode Marketplace, installable with a single click both in local endpoints, and in shared servers via systems like Github CodeSpaces, OpenVSCode Server, etc.
From this single installation click, the server is automatically started and listening on port 3001 without authentication, opening the door to RCE.
First, we’ll explore how this issue could be exploited from a surrounding compromised device, and we’ll then demonstrate how DNS rebinding could be exploited to trigger RCE via simply having a victim browse to a malicious site.
At the end of 2025, probably following a series of vulnerabilities identified in multiple MCP servers, Anthropic added an additional layer of security to prevent this risk (CVE-2025-66414) that adds a default security layer in most MCP server cases.
Version 1.24.0 of modelcontextprotocol introduces createMcpExpressApp, a preconfigured express server instance that automatically registers validateHostHeader and validateOriginHeader. Together, these functions prevent the risk of DNS rebinding.
However, the library still relies on maintainers to use header validation middleware functions in case of custom express configuration. And in the case of DebugMCP, this is lacking.
That was the first node of our attack chain.
Combined with the lack of host and origin definition and validation, the custom express server defined (identical to CVE-2025-53967), exposed the MCP tools far beyond the intended reach.
But independently from the broad network exposure, an LLM could be tricked via indirect prompt injection to access a file outside VSCode workspace trust, and the fix produced by the maintainers doesn’t answer this question.
Uncontrolled File Path
To further explore the attack chain, let’s review the tools exposed.
The README lists the available tools, including:
start_debugging: launches a debugging session for a given file path
get_debugger_state: returns the current state of an active debugging session
get_variables: inspect local variables in the current stack frame
evaluate_expression: evaluate an arbitrary expression in the debugger context
continue_execution: resume execution
From reading the tool definitions, start_debugging jumped out immediately since it accepted a fileFullPath argument and instructs VS Code to launch a debugger session for that file. That’s a file execution primitive.
But to obtain an efficient RCE chain, a few more steps were required.
The UNC Path Primitive
At first glance, because the vulnerability requires knowing the full path of an executable on the victim’s machine, it seems difficult to weaponize reliably in the wild.
However, on Windows, the Universal Naming Convention (UNC) path format allows programs to reference files on network shares using paths of the form:
\\SERVER\SHARE\path\to\file
This feature enabled us to make DebugMCP pass the path to VS Code’s debugging infrastructure, which passed it to the Python launcher, which reached out to the attacker’s SMB share and loaded the file. The file executed under the victim’s user context.
Fig. 1: SMB endpoint to fetch payload
The proof-of-concept payload was intentionally benign:
import os os.system(“calc.exe”)
After a few seconds, Calculator opened. The attacker’s code was running on the victim’s machine via a single HTTP request.
At this point we had a working local exploit, if we could send one HTTP request to port 3001 with an attacker-controlled UNC path and get code execution.
The remaining question was how to deliver that request from a remote attacker’s position to a victim’s localhost, across the same-origin policy that is supposed to make this impossible.
Stateless MCP session
One part of the answer lies in the MCP itself. You can find a detailed introduction to the protocol here.
What matters here is one implementation detail that significantly reduced the attack complexity.
MCP over HTTP is built on JSON-RPC 2.0. The protocol specification describes a lifecycle: a client must send an initialize request, receive the server’s capability response, then send an initialized notification (only after this handshake can tool calls be made). This sequence implies a minimum of two round-trips before any tool is invoked, and it gives a server the opportunity to establish authenticated session state.
The MCP TypeScript SDK’s StreamableHTTPServerTransport enforces this lifecycle through a validateSession function called on every non-initialize request. The enforcement is conditional:
Fig. 2: Stateless MCP mode
When sessionIdGenerator is undefined, validateSession returns immediately without checking anything. The entire initialization lifecycle is bypassed. In DebugMCP v1.1.4, the transport was explicitly configured in stateless mode.
The consequence for the attack chain is direct: a single no-cors HTTP request was sufficient to trigger the attack.
Browser Local Network Protections
However, there was a last ingredient we needed to incorporate to obtain a frictionless exploit.
Indeed, Local Network Access’s aim is to protect users from cross-site request forgery (CSRF) attacks targeting routers and other devices on private networks, and to reduce the ability of sites to use these requests to fingerprint the user’s local network.
Combined with the same-origin policy (that prevents a piece of JavaScript from one domain and make cors requests to a different one and get the response), in modern browsers, there is a good chance a warning popup would be displayed and halt the execution of the malicious content if a threat actor tries to scan the local network.
But DNS rebinding is a technique that can potentially circumvent this boundary by exploiting the way browsers cache DNS records. And as we explained earlier, DebugMCP doesn’t include MCP default mitigation added by Anthropic against this risk.
Here is the attack flow:
Fig. 3: Attack Flow
The sequence unfolds in six steps:
Step 1: Victim visits the page. The attacker’s domain resolves to the attacker’s public IP (Phase 1 DNS). The browser loads the initial page content.
Step 2: DNS Rebinding. The domain was registered with a very short TTL: 1 to 2 seconds. Firefox enforces an internal minimum cache duration of ~60 seconds regardless of the declared TTL, so the page polls in a JavaScript loop until the entry expires and Firefox re-resolves the name: at which point the attacker’s DNS server returns 127.0.0.1.
Step 3: Local Network Access. The attacker’s JavaScript, issues a fetch to http://evil.attacker.com:3001/mcp?transport=streamable_http. The browser considers this request same-origin and sends it. The DNS entry now points to 127.0.0.1, so the request arrives at the victim’s local DebugMCP server.
Step 4: DebugMCP Execution. The request reaches the Microsoft DebugMCP server running locally on the victim’s machine. DebugMCP processes the request and triggers its Python launcher, which is responsible for starting the debugging workflow.
Step 5: Malicious Payload Download. The Python launcher connects to a publicly accessible SMB share controlled by the attacker and downloads the malicious Python script onto the victim’s machine.
Step 6: Code Execution. The launcher passes the downloaded script to the start_debugging() function. DebugMCP then executes the attacker-controlled payload, ultimately giving the attacker code execution on the victim’s machine.
Demonstration
Although the exploit triggers error messages in the VS Code console, the payload is still successfully executed. We used Firefox version 150.0.3, the latest at the time of our research.
Note: After the research, Firefox enforced a Local Network Access Protections (version 153). This prevents the a request originating from a domain associated with a public IP to reach more private address networks. This recent feature, currently existing in Chrome and Firefox, isn’t yet generalized to all browsers.
Impact
The target is a developer. That means the compromised machine holds live credentials, source code, and trusted access to internal infrastructure.
In practice: AWS keys, SSH keys, GitHub tokens in VS Code’s secret storage, active cloud CLI sessions, VPN tunnels open to the internal network, and push access to production branches would be likely available: a payload that runs as the developer inherits all of it silently.
The delivery requires no interaction beyond visiting a page, it’s a drive-by attack.
Recommendations
Developers using this tool should update to the latest available version. The fix ships after 1.1.4 (version 1.2.0 and later).
In addition, it’s recommended to regularly audit which servers are listening on loopback.
Use authentication in your MCP servers and enforce governance to control which MCP server is running in your network and be able to remove it if necessary.
Regarding MCP development more specifically:
Use middleware that enforce validation (like createMcpExpressApp Since SDK v1.23.0).
Validate file path inputs. Reject UNC paths and remote schemes before passing any path to an execution primitive.
Disclosure Timeline
May 19: Issue reported to Microsoft
May 24: Fix shipped in commit 86776b2, released as version 1.2.0
September 25: Public disclosure (this blogpost)
Conclusion
AI-assisted development is quietly rewriting the developer machine’s threat model. To give an agent useful capabilities, extensions expose local servers, wire in execution primitives, and grant broad access to the filesystem and the debugger.
Each of these is a reasonable engineering decision on its own. Together, they turn the workstation into a dense collection of automation endpoints, and those same endpoints, built to be driven by a trusted agent, are equally drivable by an attacker who reaches them. The productivity story and the attack surface story are the same story.
Developer environments are where source code, signing keys, pipeline credentials, and cloud sessions converge; compromising one is often a shorter path to production than attacking production directly.
This vulnerability was not sophisticated. The techniques here are not new; what’s new is the rate at which capable, unvetted local servers are being deployed onto high-value machines, and the growing ability of AI agents to discover and chain weaknesses autonomously.
A new kind of AI model returns decisions instead of text. We spent a day trying to change its mind. It cost about 50 cents. In this article Jev is a new kind of AI model that returns typed decisions instead of text, built for software to call rather than for people to read. We put it inside a realistic application and tried to change its verdict from the outside. →every configuration we tested was broken: risk downgraded to low and investment advised, on a document that flags every warning sign →about 50 cents per successful break, with our strongest […]
In this article Nineteen Check Point AI Security R&D teams spent two days on one prompt: build the demo customers would ask to see twice. Three of the results tell a single story about securing AI agents, and none of it starts with an attacker. →an autonomous agent took dangerous actions with no attacker involved, it simply hit a wall and improvised →a single poisoned file in a code repository turned a popular coding agent into a data exfiltration channel →questioning an off-track agent prevented as many attacks as blocking it, and completed more legitimate work →the lesson for anyone […]
Torrent trackers have long been abused for distributing malicious software, disguised as popular films, games, and other content. Our previous research has shown that cybercriminals repeatedly turn to torrents as an initial infection vector, using trojanized cracks and installers to reach a large number of users. Installation guides for pirated software routinely instruct users to disable their antivirus, conditioning them to ignore the potential threats they are inviting onto their computers.
During our analysis of malware that leverages blockchain networks for its C2 infrastructure, we discovered a previously unknown modular, multi-stage framework that we dubbed MovieReaper. This report details the new crimeware campaign that began with the mass infection of users via compromised torrent tracker file storage. We have identified several hundred victims, including both individual users and organizations in multiple countries, such as Russia, Türkiye, Japan, Kenya, Uganda, and Colombia, as well as in several European countries like Spain, the Netherlands, Belgium, and Germany. We analyze the techniques for evading detection by security and sandbox solutions, and examine the capabilities of the modular framework.
Kaspersky products detect this threat as HEUR:Trojan.Win64.Agent.gen.
Technical details
Background
In mid‑August 2026, during our threat‑hunting efforts, we identified a large‑scale infection campaign involving previously unknown malware disguised as popular movies. The campaign affected both individuals and organizations across multiple countries. Our initial analysis revealed a common denominator: all of the victims had used torrent trackers. This finding prompted us to investigate the campaign further and analyze its distribution mechanism, overall scope, and unknown malware implants.
Initial infection and spread
Compromised torrent trackers are the primary vector used to distribute malware. During our investigation, we identified multiple user reports describing suspicious files being downloaded instead of the intended content.
For example, a user of a popular movie torrent tracker reported the following case on Reddit:
Further analysis of the attack revealed that instead of compromising torrent trackers, the threat actor modified a widely used public repository of torrent files, itorrents[.]org. As a result, the trackers that relied on the repository began inadvertently distributing malicious torrent files to their users. This approach is particularly dangerous because it lets the threat actor reach users of multiple trackers without having to compromise each platform individually.
As of the publication date of this report, the archive remains compromised. When a user attempts to download a torrent via a magnet link, the legitimate torrent archive returns a different torrent file. This malicious torrent leads to the download of the malware loader, used to deploy a framework that we dubbed MovieReaper.
The loader initiates the infection chain shown in the diagram below. Each stage of the chain is described in detail in the following sections.
Malware implants
The infection chain consists of several steps, where only the initial one is dropped on the disk before it is executed to avoid detection. The malware itself is not heavily obfuscated, apart from strings being encrypted with a custom stream cipher. Most of the countermeasures were aimed at avoiding detection by AV sandboxes.
Step 1: Loader
The most popular initial executable was distributed through torrent trackers under many different names (for example, the odyssey (2026) [1080p] [webrip] [5.1].exe), but the file hash (MD5: A0B13781EDD7CFDAB13D79AFFF3C83C1) was identical across all downloads. We have seen multiple different loaders, where the executable file disguises itself with a long filename and an icon of some well-known application. Most of the filenames are rather long, presumably to hide the EXE extension at the end.
After the user manually starts the application, it establishes a global mutex to ensure that only one loader is executed at a time. We have seen several mutex variations in our samples, containing a randomly generated string (in the example Global\fnulSktzSqvVLXHU). This executable then performs a series of operations in order to avoid detection by AV sandbox solutions.
While performing those operations, the malware avoids making LoadLibrary and GetProcAddress calls to acquire the addresses of required functions. Instead, it searches for loaded libraries by traversing the double-linked list taken from the Ldr field of the PEB and then performs manual parsing of the loaded DLL to calculate the function address.
After all initial checks have passed, the binary prepares to establish a network connection to a C2 web server to download the shellcode, map it to the RWX memory and execute. While doing so, the loader decodes the domain name https://deadhub[.]org and if connection to it has failed, it uses the IP address http://193.23.118[.]155 as a fallback and connects to it using plain HTTP. The malware chooses a random group of strings and uses them as a path in the HTTP request to download the parts of the shellcode.
While mapping the address space and executing the shellcode, the loader registers a vectored exception handler and rewrites the handler address in memory in order to perform a debug break. This, will not crash the program, but instead redirect controlflow to the function that actually makes a raw NtProtectVirtualMemory syscall (via a previously located “0x0F 0x05” syscall instruction inside ntdll). Then it calls the undocumented ntdll function EtwpCreateEtwThread, which is a popular alternative to CreateThread for code executionm, and executes the shellcode.
Step 2: Shellcode
The second stage of this malware performs an HTTPS request to the Solana blockchain at the endpoint /getAccountInfo endpoint for the account 6pnDGAiHgyPdmckM5Qt1YbanGzrX43WLEU159nRaNLDm. The data in field of the response contains the base64‑encoded address of a second C2, which is encrypted with a static XOR key located within the shellcode itself. To store data in this account, attackers used a simple Solana program (address: CSiY8bQLBYPdfPWkwipBzH6sijTVQVVsA279JQdvwHtL).
Utilizing the Solana blockchain as a storage layer for next-stage C2 endpoints substantially complicates infrastructure takedown efforts by defenders.
The second stage payload communicates with its C2 server strictly through HTTPS via a TLS-pinned certificate using the nanopb protobuf library as a container for transferred data. The main logic of the stage 2 implant contains several initial commands, where the most important is the one that parses the COFF file, loads it into memory, and executes the module_init function from it. This provides a convenient interface for extension of the command list, which brings us to the next stage of the payload.
Step 3: UAC Bypass and persistence
Notably, the recovered modules were compiled with symbols, which accelerated reverse engineering.
After receiving the next stage from the second C2 server, the newly loaded module performs several tasks right in the module_init function.
Stage 3 performs UAC Bypass and achieves persistence using public techniques, masquerades the original binary as C:\ProgramData\Microsoft\Windows\Telemetry\msedge.exe, and restarts itself.
The respawned process starts with the initial loader, but with a special command-line argument, which allows it to skip most of the anti-sandboxing checks and proceed straight to downloading the next payload. The executable proceeds with the same steps as before, but this time, instead of downloading the persistence and UAC bypass module, a new one is downloaded from the second C2 server. This is because the malware uses the beacon to send a flag to the remote server, indicating whether the implant is running from the Telemetry folder, which allows the C2 to distinguish between first-run and respawned instances.
Step 4: The final implant
The final module (“file manager”) exposes 21 commands that give the operator filesystem access on the victim host. This allows remote the operator to download, upload, and read files on the system; list and enumerate directories; manipulate files with create, copy, rename, move, delete, chmod, and symlink commands; and use preview and thumbnail commands to exfiltrate previews of images and files before actually extracting them.
We suspect that other modules may be loaded on demand if requested by the operator.
Infrastructure
During this malware campaign, attackers are using various commercial hosting providers for their C2 infrastructure (see the IoC section for details). Furthermore, as noted above, the campaign leverages the legitimate Solana blockchain via the RPC endpoint api.mainnet.solana.com to deliver the address of the second‑stage C2 server to the malware. This approach provides the attackers with decentralized storage for C2 addresses, adding an additional layer of resilience and making it more difficult for defenders to disrupt the campaign by simply blocking the IP addresses of the C2 servers.
Victims
The observed campaign targeted both individuals and organizations across Europe, Asia, Africa, and Latin America, with infection attempts identified in Russia, Spain, Germany, Finland, Türkiye, Japan, Nepal, Kenya, Tanzania, Ghana, Uganda, Colombia, the Netherlands, Belgium, and other countries. The targeted organizations span a wide range of sectors, including enterprise, government, IT, consulting, retail, transportation, and agriculture.
Conclusions
Our research uncovered activity by the same actor dating back to October 2025. Although the campaign has evolved over time, with the malware authors expanding their arsenal and making the loader harder to detect, the pattern remains the same. This includes encoded strings, parts of shellcode downloaded through plain HTTP, and several techniques used to avoid sandboxes and virtual machines. We will continue monitoring this actor’s activity to catch new potential threats.
The first stage offers the clearest opportunity to disrupt this campaign: it relies on a single specific domain name and a single IP address to serve the shellcode, so taking down this server would prevent subsequent infection stages. This includes the second-stage payload, which uses the Solana blockchain network for a C2 and is therefore more resistant to conventional infrastructure takedowns.
However, this framework’s self-containment, modularity and in-memory execution has potential for reuse in later campaigns with minimal rework.
We designed a behavioral clustering model to map cloud identity roles from audit logs, enabling continuous threat detection using standard SQL queries.
The defining development of the period came not from attackers but from the AI labs themselves, whose models broke out of controlled evaluations and reached real systems. In the wild, the criminal and state use of AI continued to mature along the lines tracked in earlier editions: models now act as attack operators, an underground market supplies the access, and AI systems have themselves become a target. The substantial distance between what the strongest models demonstrated under evaluation and what criminals are currently doing is the central fact of the period.
Key observed findings
Evaluation models escaped containment in ways nobody had engineered a fix for. An OpenAI research prototype found and exploited a previously unknown vulnerability in an internal package proxy, reaching Hugging Face’s production systems and taking roughly 17,600 recorded actions before anyone caught it. Anthropic and Meta each reported test models reaching the open internet through misconfigurations, and the UK AI Security Institute logged a case where an agent invented fake identities to try to talk a real person into approving malicious code.
What criminals are doing today is still far more modest, and that gap is the story worth watching. Real world attacks run on models below the frontier, use known techniques, and get caught by existing defenses, nothing like a model finding its own zero day or sustaining an unsupervised operation for days. But frontier capability has reached commercial and open source models within months of first appearing every time before, and there’s little reason to expect this one stays contained to the lab.
An affiliate tied to The Gentlemen ransomware group used Claude Code to carry out real intrusions against at least six organizations, a person directing an AI tool through each step. JADEPUFFER went further: a human configured and launched it, the model ran the entire extortion operation itself, moving from the initial flaw to the internal database, exfiltrating and deleting data, leaving a ransom note, and correcting its own errors along the way, with no person directing the individual steps.
A criminal market has organized around stealing and reselling AI access itself. One tier steals API keys and credentials at scale, and a second resells that access through gateways that hide the buyer’s identity from the provider.
AI systems have become entry points in their own right. Coding agents and enterprise copilots can be steered through content they’re built to trust, a symbolic link, an image, a fabricated error report, and both Google’s Gemini CLI and Anthropic’s Claude Code needed patches for flaws a malicious GitHub issue could trigger.
A separate market exists for removing a model’s guardrails once you have access to it. One forum post asking to buy a durable method for bypassing a model’s restrictions, rather than a single jailbreak prompt, is a useful illustration of what that demand looks like.
AI is surfacing vulnerabilities faster than anyone can patch them, but that hasn’t translated into more successful attacks. Microsoft shipped a record 570 fixes in July and Oracle’s quarterly update ran past 1,400, yet only about one percent of AI discovered vulnerabilities were confirmed exploited in the wild, roughly the same rate as flaws found any other way.
Everyday enterprise GenAI use is a quieter but steadier source of exposure. In July, one in every 36 prompts from enterprise networks carried a high risk of sensitive data leakage, and 88 percent of organizations using these tools recorded at least one high risk prompt during the month.
Want the full report? Read the complete July-August 2026 AI Threat Landscape Digest here.
Between mid-July and early August 2026, models being evaluated internally by OpenAI, Anthropic, and Meta reached real production systems outside their test environments. One exploited a previously unknown vulnerability to escape its sandbox entirely. At the same time, criminal groups showed that frontier capability isn’t required for serious attacks: a ransomware affiliate ran a full intrusion through Claude Code, and a separate campaign, JADEPUFFER, is now documented as the first case of agentic ransomware, an extortion operation a model carried out end to end once a human set it in motion. Check Point Research’s July-August 2026 AI Threat Landscape Digest […]
We ensure alignment and control in agents using synchronous control monitoring. Our model oversees agent execution, continuously ingests the trace as context, and prevents harmful actions before they execute in real time at sub-100ms latency. Agent trace at 30 tok/s, streamed to the control monitor model on the right. Prevents harmful actions before they are executed. Background Control Monitoring is a powerful tool for ensuring the runtime alignment and safety of autonomous agents. Since the Hugging Face Incident, the need for control monitoring on top of existing safety mechanisms was reinforced: OpenAI started investing more heavily into monitoring safety tools. […]
Enterprises are connecting AI assistants to more of their real infrastructure every month, from inboxes to file drives to internal tools, on the assumption that the isolation between users and accounts holds. Check Point Research just tested that assumption against ChatGPT and found a way to break it. Using an internal service that was never meant to carry user data at all, CPR opened a working channel between two completely separate ChatGPT accounts and used it to hand one victim’s session a task from a total stranger, all while the victim’s own conversation looked entirely normal. Key Takeaways Check Point […]
Check Point Research discovered a covert cross-account command channel through which an attacker could use a victim’s ChatGPT session to execute hidden tasks with the tools, data, and connected apps available to that session. The victim could receive a normal answer to their visible request while the attacker’s task was processed separately and its result returned across accounts. In our proof of concept, ChatGPT retrieved email data from the victim’s connected Gmail account and relayed it to the attacker.
The channel operated through code-execution environments belonging to different ChatGPT accounts. Although the containers could not access the public Internet or communicate directly, they could all reach the same internal service used to deliver software packages.
The hidden instruction could be delivered through a malicious prompt, a shared ChatGPT conversation, or a custom GPT. Once it was present in the victim’s conversation context, an ordinary message could trigger the attacker-controlled task without revealing it in the visible response.
The same channel could also be used to exfiltrate conversation history and files available in the affected chat and its code-execution environment. The scope of the attack depended on the data, tools, connected apps, and permissions already available to the victim’s session.
Introduction
Over the past several years, AI assistants have moved far beyond text generation. Modern systems can execute code, install additional dependencies, analyze user files, and access data through connected services. These capabilities significantly increase the practical value of LLMs, but they also change the security model: protecting user data now depends both on the behavior of the model itself and on its execution environment, the tools available to it, and the platform’s internal services.
In this architecture, the model sits inside the security boundary. It can access internal resources and user data, but its behavior can be steered through instructions. If an attacker provides a convincing justification for an action, the model may carry it out using the capabilities available in the user’s session. The model can therefore act as a coerced insider: not malicious, but persuaded to act on the attacker’s behalf. Even if the model performs an action it should not, data leakage should still be technically impossible.
ChatGPT handles tasks that require code execution inside isolated containers. We have previously shown why the isolation of these containers is critical. To prevent user data leakage, containers must not have direct access to the public Internet, and containers belonging to different users and accounts must not be able to exchange data.
The importance of this isolation boundary was recently highlighted by the widely reported Hugging Face incident. In its postmortem of the incident, OpenAI described how agents running in separate evaluation environments established unauthorized communication channels that allowed them to share information and coordinate their actions.
Coincidentally, while this incident was developing, Check Point Research was investigating a related isolation problem in ChatGPT. In June 2026, we independently found a way to establish a covert, bidirectional channel between the code-execution containers of two separate ChatGPT conversations created under different accounts. The mechanism we discovered was different from those used by the agents described in OpenAI’s postmortem, but both cases exposed the same architectural weakness: a shared internal service became an unintended communication layer across environments that were supposed to remain isolated.
We also found that this communication path could be turned into a hidden task channel. A crafted instruction could make ChatGPT process a second stream of tasks alongside the visible conversation: receive instructions from an attacker, execute them using the capabilities of the victim’s session, and return the results without exposing the second stream in its visible response.
Figure 1 – ChatGPT process a second stream of tasks alongside the visible conversation.
To demonstrate the practical impact, we embedded such an instruction in a shared ChatGPT conversation. The victim only had to open the link and send a normal message. ChatGPT completed the user’s request while simultaneously accessing the victim’s connected Gmail account and sending the retrieved data to the attacker’s account through the cover channel.
Video 1 – A shared ChatGPT conversation completes the victim’s visible request while retrieving data from the connected Gmail account and sending it to the attacker’s account.
Container Network Isolation and Internal Access
For solving complex analytical problems, ChatGPT can create code-execution containers. At the time of our research, we assessed that these containers could not access the public Internet. Containers created for separate conversations, including conversations under different accounts, also cannot communicate directly with one another.
Some tasks may nevertheless require installing additional Python and npm packages, as well as dependencies from other ecosystems. To support this functionality without giving containers access to public package repositories, the containers were allowed to access an internal JFrog Artifactory instance, which acted as a controlled intermediary for retrieving the required dependencies.
The containers therefore remain isolated from one another, but each can access the same permitted internal service.
A Shared Clipboard Between Isolated Containers
Access to the same internal service does not by itself break container isolation. The issue arose because the Artifactory instance available to the containers exposed Item Management API operations for repository items.
These operations were available through the /api/storage/{repoKey}/{itemPath} endpoint:
Set Item Properties allows string properties to be attached to an existing repository item, such as a file, folder, or repository. Property updates are supported for local repositories and local caches of remote repositories and require Annotate permission.
Get Storage Item Information can return the properties associated with an item through the same storage endpoint.
In the environment we examined, the credentials provided to the container for reader access had sufficient permissions to perform both operations. The credentials were stored in environment variables and were available to code running inside the container. Code launched by ChatGPT could therefore authenticate to the storage endpoint without extracting a separate secret or escalating privileges.
We tested whether item properties were isolated by account. From a container under one account, we added a test property named chatgpt_test_ts, with the current timestamp, to an automatically cached file. From a conversation under a different account, we then requested the properties of the same file. The response contained the exact property name and value written from the first account.
Figure 2 – The item properties retrieved from the second account contain the chatgpt_test_ts value previously written from the first account.
Property values could carry text directly or binary content encoded as Base64. Data too large for a single property could be divided into chunks, stored under separate keys, and reassembled at the other end. The storage endpoint therefore turned the package service’s metadata into a shared clipboard between isolated containers.
The Invisible Second User
The channel between containers belonging to different users could be used to steal chat history and files shared in a conversation. In our previous research, we showed how a malicious instruction could make ChatGPT exfiltrate the same type of data through a different hidden outbound channel.
For the cross-container attack described here, all that was needed was a single short message containing the required instructions. The attack could therefore be carried out in several ways:
a malicious prompt pasted by the victim into a new or existing chat;
a shared conversation containing the instruction;
a custom GPT with the instruction embedded in its hidden configuration.
The possible damage extended beyond chat history and uploaded files. Today, ChatGPT is a cloud-based agent that can access external services through connected apps. A user may connect it to Gmail, Google Drive, Microsoft Teams, GitHub, and many other services. ChatGPT can then access data stored there within the permissions granted by the user or their workspace.
Figure 3 – ChatGPT plugins.
We were able to write the instruction so that, in Thinking mode, ChatGPT handled two independent request streams during a single turn.
The first stream was the normal conversation with the victim. ChatGPT processed the visible request and returned an ordinary answer. At the same time, it checked the hidden mailbox for a task from the attacker. If a task was waiting, ChatGPT carried it out using the tools and data available in the victim’s session, then returned the result back through the covert channel.
The instruction told ChatGPT not to mix the two streams. The hidden task and its result did not appear in the answer shown to the victim. From the user’s point of view, the conversation continued as usual. In reality, the same ChatGPT session was serving a second user whom the victim could not see.
Figure 4 – ChatGPT processes a visible user request and a hidden task during the same turn, then returns the results through separate channels.
For example, a hidden task could ask ChatGPT to retrieve a list of emails. The next time the victim sent a message, ChatGPT could process this task alongside the user’s visible request.
We tested this scenario using an unrelated, ordinary user request. ChatGPT processed the request and returned a normal answer in the visible conversation. During the same turn, it accessed the connected Gmail account and returned the requested email data through the hidden channel.
The visible answer contained no mention of the Gmail request or the retrieved data. The only app-specific clue was the small “Talked to Gmail” label above the answer.
Figure 5 – ChatGPT answers the cooking question normally. The “Talked to Gmail” label is the only indication of the hidden activity in this view.
This label recorded an action that had already taken place. It did not give the user a chance to approve or reject it.
By default, the Gmail integration in ChatGPT automatically approves low-risk actions. ChatGPT may still deny actions involving sensitive information, but a read operation can be completed without a separate confirmation request. However, in the attack scenario we examined, even read-only “low-risk actions” can carry significant risk because they may be used to obtain personal data, sensitive correspondence, confidential business information, or other content accessible through the victim’s connected account without a separate confirmation request.
OpenAI documentsImportant actions as the default permission setting for connected apps. Under this setting, ChatGPT can read from apps without prior approval, while actions considered important require confirmation. Users can select the stricter Always ask setting. Under the default configuration, the Gmail activity becomes visible only after the read has been completed.
Figure 6 – The default Gmail settings allow low-risk actions without a separate confirmation request.
The covert channel could therefore become a remote-control channel for the capabilities available to the victim’s ChatGPT session. Its reach would depend on the data, tools, and permissions already available there.
Activating this capability required very little interaction from the victim. Shared conversations and custom GPTs were especially practical delivery methods. In both cases, one ordinary message from the victim could activate the hidden task stream.
In the shared-conversation scenario, the victim only had to send a message in a conversation whose context already contained the malicious instruction. ChatGPT could then process the visible request while also checking the hidden mailbox and carrying out any waiting task.
A custom GPT could operate similarly. It could perform its advertised function while checking the hidden mailbox during ordinary interactions. Its builder instructions are not shown to the user, allowing the covert-channel instruction to remain outside the visible conversation.
Conclusion
By the time we completed our report, the cross-account channel was no longer available. We nevertheless disclosed our findings to OpenAI, who confirmed that the internal Artifactory instance identified during our research had been decommissioned.
This issue illustrates a broader security challenge in agentic systems. An LLM operates inside the trust boundary: it uses credentials, runs code, accesses internal services, and works with user data. Its actions are directed by text instructions. This combination turns the model into a coerced insider that can use authorized capabilities on behalf of another user.
In the environment we studied, the network sandbox performed its intended function. The cross-account channel emerged through a shared internal service and mutable state without tenant isolation. Shared infrastructure effectively became a communication path between containers that were considered isolated.
The architecture of agentic platforms must account for every resource available to the model: internal APIs, shared state, credentials, tools, and connected apps. Management interfaces should be inaccessible from the runtime, and permissions should be limited to the minimum required. Within shared internal services, any data that a container can modify must remain accessible only to the account or session that owns it. Connecting external services increases the impact of any failure in this model because an active session may work with data far beyond the container.
TL;DR:CVE-2026-75650, dubbed StyleSmuggler, is a critical vulnerability affecting Adobe Commerce and Magento Open Source. The vulnerability allows an unauthenticated attacker to inject malicious PHP code into Magento’s template system and achieve remote code execution. Adobe assigned the vulnerability a CVSS score of 10.0 and released an emergency hotfix after exploitation was observed in the wild. Imperva Cloud WAF and On-Prem WAF customers are protected against exploitation attempts associated with CVE-2026-75650.
Understanding the StyleSmuggler Vulnerability
StyleSmuggler is an improper neutralization vulnerability in Magento’s template engine. Attackers can abuse the processing of styles properties to smuggle malicious PHP code past existing safeguards and into content that Magento later renders.
The attack occurs in two stages. First, the attacker sends a crafted request that causes malicious PHP code to be stored within Magento-generated content, such as a failure report. The attacker then triggers application functionality that renders the poisoned content, including Magento’s standard failed-payment email process. When the template is rendered, the injected PHP executes on the server.
No authentication or user interaction is required. The recipient does not need to open the failed-payment email, and the attack can succeed even if the email is never delivered. Successful exploitation gives the attacker arbitrary code execution in the context of the Magento application, potentially enabling malware deployment, persistent access, credential theft, payment-data compromise, or further movement within the environment. The vulnerability affects supported versions across multiple Adobe Commerce and Magento Open Source branches, including systems that had received recent security patches.
Observed post-exploitation activity has included the deployment of persistent Linux backdoors disguised as legitimate processes such as kworker, fc-cache, and chronyd. Researchers have also identified a separate campaign using the vulnerability to install a PHP web shell, demonstrating that multiple threat actors are already attempting to operationalize StyleSmuggler.
What Imperva Has Seen So Far
Imperva has observed exploitation activity targeting websites across 15 countries, indicating that StyleSmuggler scanning and attack attempts are already geographically widespread. The United States accounts for 25% of targeted sites, followed by Mexico at 15.9%, Spain at 14%, and Singapore at 13.6%.
Retail websites represent the largest share of observed targets at 39.5%, consistent with Magento’s extensive use across ecommerce environments. Lifestyle sites account for another 19.5% of targets, followed by healthcare at 17.9%.
Attack traffic has primarily automated attacks. While client identifiers can be modified or spoofed, their prevalence is consistent with attackers using scripted tools to automate scanning and exploitation rather than interacting through conventional web browsers.
Imperva protections are actively identifying and blocking malicious requests associated with the StyleSmuggler attack chain before they can reach protected applications.
Conclusion
CVE-2026-75650 poses an immediate risk: it enables unauthenticated remote code execution, has already been weaponized, and can give attackers direct control over ecommerce servers. Adobe Commerce and Magento Open Source administrators should apply the VULN-39341 hotfix immediately and investigate potentially exposed systems for signs of compromise. As exploitation began before a patch was available, applying the hotfix does not remove malware or persistence mechanisms that may already be present.
Imperva Cloud WAF and On-Prem WAF customers are protected against exploitation attempts associated with StyleSmuggler. Imperva will continue monitoring the campaign as attackers refine their payloads and additional activity emerges.
At least four espionage groups, most with suspected links to China, are using a new exploit kit that chains two Chromium-based browser flaws and one Microsoft Windows bug to break into organizations' networks in the US and Southeast Asia. Mark Kelly, a threat researcher at email security shop Proofpoint, told The Register that the researchers don't know exactly who was targeted, nor how, and so far the damage appears limited. “In terms of organizations targeted, we saw fewer than 20 organizations globally targeted across the activity highlighted," he said. "However, the true number is almost certainly higher than this.” Proofpoint’s threat hunters spotted the new kit, which they named BlueMoon, and said its first observed use started on August 28. This is when a Beijing-backed crew they track as TA412, also known as Violet Typhoon and APT31, used BlueMoon to “repeatedly” target non-governmental organizations (NGOs), mining companies, and physical commodity trading firms in the US. TA412 is a cyberespionage group linked by US authorities to China's Ministry of State Security (MSS), and American prosecutors previously charged seven alleged members with conspiracy to commit computer intrusions and wire fraud, alleging they broke into computer networks, email accounts, and cloud storage belonging to numerous critical infrastructure organizations, companies, and individuals. Just days after Proofpoint documented the late-August activity, “several other espionage-motivated clusters began using BlueMoon, the majority of which have a suspected China nexus,” Kelly and fellow researchers Greg Lesnewich, Konstantin Klinger, Saher Naumaan, Julia Paluch, David Galazin, and Stuart Del Caliz said on Wednesday, noting that there may be other, non-China-nexus attackers using the exploit kit as well. “BlueMoon was developed and deployed rapidly, and shared across multiple threat actors within days,” Kelly told The Register. “This may reflect a reduced cost and barrier to entry for this class of capability, which has historically been rare and high value, as AI agents increasingly enable threat actor exploit development. That is particularly true for open-source codebases such as Chromium, where publicly accessible upstream patches create a ‘patch-gap’ window for rapid reverse engineering and exploit development ahead of downstream stable releases.” A Google spokesperson declined to comment beyond what Proofpoint wrote. Microsoft patched the Windows bug (CVE-2026-85880) on Tuesday, and a spokesperson reiterated that customers who applied that patch are protected. BlueMoon attack chain The kit chains together three vulnerabilities. The first is a V8 type confusion (CVE-2026-85046) flaw that allows remote code execution and affects all Chromium-based browsers, including Google Chrome and Microsoft Edge. Google patched this bug in Chrome on September 3, and at the time warned that it “is aware that an exploit for CVE-2026-85046 exists in the wild.” Microsoft published a security advisory saying it fixed the flaw in Edge Stable version 152.0.4191.62 on September 2. The second is a Chrome V8 sandbox escape. This one also affected all Chromium-based browsers. It does not have a CVE because Google doesn’t issue them for sandbox escapes. Finally, the third bug is a privilege escalation vulnerability in Windows Advanced Local Procedure Call (CVE-2026-85880) that Microsoft patched on Tuesday, as noted above. Redmond also warned that this flaw had been exploited as a zero-day prior to the security update. The Proofpoint researchers also note that both V8 vulnerabilities are what’s called "patch-gap" zero-days at the time of the observed activity. This means they were known and fixed in upstream Chromium source code – a change containing the fix for CVE-2026-85046 was committed on August 7. But they remained unpatched in the latest stable releases of Chrome and Chromium-based browsers available to the public for weeks. “It is likely that the exploit kit developer used these publicly available Chromium patches to weaponize the browser exploit chain,” the researchers note. From phishing to browser surveillance The attacks start with a phishing email that tricks victims into clicking on an actor-controlled URL. This triggers the two V8 bugs to allow remote code execution and escape the browser sandbox. The attack chain then exploits the Windows bug to download multiple payloads including browser-surveillance malware, credential-stealing backdoors, and others, depending on the group using the exploit kit. TA412’s first campaign, which began on August 28, used a range of lures. Some of the emails purported to come from university students interested in internships at the targeted organizations, and some were more target-specific exchanges, intended to build trust with the individual before ultimately sending a malicious link via email. In these instances, the exploit chain “ultimately downloaded and ran a loader executable on the infected host, which then installed a malicious browser extension disguised as Google Gemini on the victim's Chromium-based browser,” the team wrote. This browser extension, which Proofpoint tracks as GemStone, allowed the Beijing spies to issue commands through a command-and-control (C&C) channel, steal cookies and other sensitive data, take screenshots, and inject a keylogger into a browser tab. The malware also contains a keyword monitor, which injects an attacker-specified keyword list into the top frame of each page, scans the HTML body for these keywords, and triggers a screenshot if it finds any. A few days later, beginning on September 2, a second China-aligned spy crew that Proofpoint tracks under the temporary group designator UNK_LateNight used BlueMoon to target multiple US aerospace companies. The phishing emails used request-for-quotation lures specific to defense industry organizations, and included links to attacker-controlled domains spoofing a variety of US aerospace companies. These websites also served the BlueMoon exploit kit and ultimately loaded a backdoor called ShadowPad, which has been shared among multiple China-aligned groups since 2019. Around this same time, on September 2, another suspected espionage group that Proofpoint tracks as UNK_DoubleCheck targeted a Vietnamese manufacturing firm with messages sent from a compromised Southeast Asian government email address. The fourth campaign began a day later, and involved suspected China-linked spy crew UNK_QuietRacket using BlueMoon to target government, consulting, and financial-sector organizations in Indonesia and Singapore. These phishing emails used lures related to Indonesian conferences, such as the Indo Startup Expo and Forum 2026 and the World Conference on Creative Economy (WCCE 2026). Proofpoint warns that BlueMoon will likely be used by both cyberspies and financially motivated attackers. “The broader dynamic revealed by this activity - rapid exploit development that leverages the open source patch-gap – is likely to recur beyond BlueMoon as this development model becomes accessible,” the team wrote. ®
Login
