We identified a couple of vulnerabilities in AI automation platform Dify resulting in cross-tenant sensitive information disclosure and one-click account takeover. These findings reinforce the pattern we documented in our previous n8n blogpost:even though AI automation platforms are increasingly becoming integration hubs for complex workflows, their security posture still lags behind their rapid evolution and operational importance.
Introduction
Dify is an open-source platform for building LLM-powered applications: agents, chatbots, and automated workflows. With over 134,000 GitHub stars and over 10 million docker pulls, it has rapidly become one of the most popular tools in the AI application space, offering both self-hosted and managed cloud deployments.
Our research into Dify uncovered two distinct vulnerabilities that illustrate this risk:
A file handling flaw that enables one-click account takeover through a single malicious link (detailed below).
An insufficient tenant isolation issue in shared environments that exposes other users’ application source code.
Both findings point to the same structural challenge: platforms that centralize trust must also centralize rigor in how they isolate users and handle untrusted input.
The first issue was addressed in Dify 1.13.1. The second was fixed in the sandbox layer by moving from a shared identity to per-execution UIDs, then shipped to Dify users through the newer sandbox image bundled with 1.13.3.
Dify did not respond to any of our disclosure messages and chose to patch silently.
One Click to Account Takeover
The flaw lies in how Dify handles file uploads through workflow tool nodes, such as Image Downloader or Image Toolbox.
SVG is an XML-based image format that can natively embed JavaScript, via <script> tags or event handlers on SVG elements. When a browser renders an SVG file served from a trusted origin, any embedded script executes with full access to that origin’s session context, including cookies, local storage, and API calls.
Dify uses two subdomains:
upload.dify.ai: where user-uploaded files are stored and served
cloud.dify.ai: the main application domain, where users authenticate and manage their workflows
Critically, upload.dify.aiand cloud.dify.ai are configured as DNS aliases. From the browser’s perspective, both subdomains resolve to the same origin. This collapses the intended security boundary: a file that should have been confined to a static asset domain is instead rendered with the full privileges of the application domain.
A malicious SVG uploaded to upload.dify.aicould simply be accessed via cloud.dify.ai, and the browser would execute its JavaScript payload as if it were part of the application itself.
But this design wouldn’t be dangerous if access control was enforced on uploaded files. Each uploaded file receives a unique ID and is stored at a predictable path:
However, these files are publicly accessible with no authentication and no per-user scoping (a.k.a Insecure Direct Object Reference). Anyone who knows the URL can retrieve the file. And that ID is not necessarily secret: it could leak through Referer headers or surface in shared workspace contexts.
Therefore, in this case, the exploitation scenario was straightforward:
The threat actor generates a malicious link leading to a resource in his account
The resource link is shared to another user, and one click leads to account takeover.
The important detail is what happened during execution. The runner generated a temporary script under ${LIB_PATH}/tmp/<uuid>.py, which became /tmp/<uuid>.py from the Python process’s perspective after chroot. The same runner stamped every wrapper script with a single hard-coded sandbox UID:
Identity was fixed through static.SANDBOX_USER_UID.
The wrapper script was written with os.WriteFile(…, 0755).
The file lived under the shared sandbox tmp directory.
Separate tenants executing inside the same sandbox root, under the same effective identity, with readable code artifacts left in a shared /tmp. That is the entire isolation bug.
Our proof of concept simply sampled /tmp during execution and collected newly created files. In a shared cloud deployment, that exposed wrapper scripts belonging to other tenants running on the same sandbox host.
The attacker-side workflow looked like this:
What the Attacker Actually Stole
The leaked file was not the raw user script.
Dify generated a Python wrapper that loaded a native seccomp helper, decoded a Base64 blob, decrypted it, and exec’d the result.
On the Go side, the matching encryption logic was just as direct:
This looks like “encryption,” but it is really a byte-wise Vigenere cipher with a 64-byte repeating key.
Something like that:
Why the Encryption Broke
If Dify had used a modern authenticated cipher and never exposed the key, reading /tmp/<uuid>.py would still have been bad, but it would not immediately reveal source code. Instead, the runner:
generated a random 64-byte key
XORed every plaintext byte with key[i mod 64]
Base64-encoded the result
embedded the ciphertext in the wrapper script
Repeating-key XOR leaks structure across every byte position modulo the key length. Once the key length is known, recovery collapses into a set of small single-byte XOR problems, not a modern cryptanalytic challenge.
Our PoC used exactly that property. The attack strategy:
Lock onto the real key size of 64 bytes.
Score candidate plaintext bytes for “Python-likeness.”
Slide common cribs, import , from , def main( — across the ciphertext.
Reward outputs that decode as UTF-8, contain Python tokens, and successfully parse with ast.parse.
Workflow code is highly structured plaintext: full of repeated syntax, imports, identifiers, indentation, JSON handling, and predictable scaffolding. Even when the exact business logic is unknown, the shape of Python source gives the attacker enough signal to recover key bytes and reconstruct the rest.
The sandbox did not need to leak the key. The ciphertext was enough.
A reduced version of the recovery logic:
The real PoC is more careful, including crib dragging, UTF-8 heuristics, Python-token scoring, AST validation, and more.
Why This Was Recoverable in Practice
Three properties made the attack reliable.
Fixed key size. The vulnerable runner hard-coded key_len := 64, so the PoC did not have to discover a moving target.
Strong plaintext priors. Python source naturally contains ASCII-heavy text, repeated keywords, common import patterns, indentation and punctuation, and valid UTF-8.
Machine-verifiable output. The PoC did not stop at “looks readable.” It strongly preferred candidates that parsed as real Python, turning recovery into a search problem with a sharp scoring function.
The wrapper was written with os.WriteFile(…, 0600).
The file was reassigned with syscall.Chown(…, uid, …).
The embedded prescript stopped using the single global sandbox UID and used the per-run UID instead.
This matters more than any cryptographic tweak. Before the fix, every execution looked like the same sandbox user. After the fix, each execution got its own identity and its own readable artifact set.
Dify did not “fix the encryption.” It fixed the isolation boundary.
The Impact
One-click account takeover: The attacker acts as the victim: modifying workflows, changing settings, inviting collaborators.
Workflow theft: Private workflows (often encoding proprietary business logic, integration architecture, and prompt engineering) become fully accessible.
Credential exfiltration: API keys, OAuth tokens, and model configurations stored in Dify can be extracted, enabling lateral movement into every connected external service.
Full instance compromise: If the victim is an administrator, the attacker gains control of the entire Dify deployment and every integration it orchestrates.
Conclusion
Both vulnerabilities we found in Dify stem from the same oversight: security controls that weren’t designed to keep pace with the platform’s feature growth. As these tools add collaboration, file sharing, and multi-tenant environments, each new surface needs to be hardened with the same rigor as the core application.
What makes this particularly relevant for security teams is the open-source model: Dify is widely self-hosted, meaning unpatched instances may persist long after fixes are released. Organizations running Dify (in any configuration) should verify they are on v1.13.1 or later.
Timeline
January 14, 2026: initial disclosure sent
March 17, 2026: Dify 1.13.1 released, addressing the first issue
March 19, 2026: dify-sandbox 0.2.13 released with UID-based tenant isolation
March 20, 2026: follow-up sandbox patch stabilizes the UID-based design inside the chroot
March 25, 2026: Dify 1.13.3 released, bundling the fixed sandbox at 0.2.14
TL;DR: Researchers recently disclosed CVE-2026-42945, a critical heap-based buffer overflow vulnerability affecting both NGINX Open Source and NGINX Plus. The flaw exists within the ngx_http_rewrite_module component and can allow unauthenticated attackers to trigger denial-of-service conditions and potentially achieve remote code execution (RCE) using specially crafted HTTP requests.
Imperva Threat Research Group analyzed the vulnerability and associated exploitation techniques. Imperva customers using Cloud WAF or On-Prem WAF are protected against attack attempts targeting this issue.
The Vulnerability
CVE-2026-42945 is a heap-based buffer overflow vulnerability in the ngx_http_rewrite_module component of NGINX Open Source and NGINX Plus. The issue, nicknamed NGINX Rift, occurs when specific rewrite-rule patterns are processed using unnamed Perl-Compatible Regular Expression (PCRE) capture groups such as $1 or $2, combined with replacement strings containing a question mark (?) and followed by additional rewrite, if, or set directives.
Under vulnerable conditions, specially crafted HTTP requests can trigger heap corruption within the NGINX worker process. Public research indicates this can reliably cause worker crashes and denial-of-service conditions, while some researchers also demonstrated potential paths toward remote code execution under favorable memory-layout conditions.
The vulnerability was discovered through autonomous analysis of the NGINX codebase and reportedly remained dormant for nearly two decades. Researchers described the issue as arising from a state mismatch in rewrite processing logic that ultimately results in unsafe memory handling during URI rewriting operations.
In practical terms, an attacker sends a crafted HTTP request designed to reach a vulnerable rewrite rule. During processing, attacker-controlled URI data can overflow allocated heap memory inside the worker process. Depending on the target environment and mitigations such as ASLR, exploitation may result in:
Worker process crashes
Repeated restart loops
Application-layer denial of service
Potential remote code execution within the NGINX worker context
The flaw affects:
NGINX Open Source versions 0.6.27 through 1.30.0
NGINX Plus R32 through R36
Patched releases include:
NGINX Open Source 1.30.1 and 1.31.0+
NGINX Plus R32 P6 and R36 P4
Because rewrite directives are extremely common in real-world NGINX deployments, particularly in reverse proxies, API gateways, load balancers, authentication flows, and URL routing logic, exposure may extend across a substantial portion of internet-facing infrastructure. NGINX was the most widely deployed web server on the internet as of 2025, supporting 32.4% of all websites with known web servers, so the exposure surface is extremely broad across enterprise, cloud, SaaS, and e-commerce environments.
Some of the techniques associated with exploitation include:
Heap corruption via malformed URI rewriting operations
Application-layer denial of service through worker crashes
Potential memory manipulation leading to remote code execution
Automated internet-wide scanning for exposed NGINX deployments
Unlike traditional volumetric DDoS attacks, exploitation of CVE-2026-42945 targets the application processing layer directly, allowing attackers to disrupt services using relatively small numbers of malicious requests.
Bottom Line
CVE-2026-42945 demonstrates how long-lived vulnerabilities in foundational internet infrastructure can remain undiscovered for years while silently exposing a massive attack surface. By abusing rewrite-processing logic inside ngx_http_rewrite_module, attackers can trigger heap corruption using crafted HTTP requests, leading to denial-of-service conditions and potentially remote code execution.
Because NGINX is deeply embedded within modern web infrastructure, including reverse proxies, API gateways, SaaS applications, and cloud environments, organizations should prioritize patching affected systems immediately and review rewrite-rule configurations for vulnerable patterns involving unnamed PCRE captures.
Imperva Cloud WAF and On-Prem WAF customers are protected against related attack activity.
Many developers today are using Claude Code, with a growing portion running it through Amazon Bedrock. For enterprise teams, Bedrock offers major advantages: keeping data inside a VPC, leveraging AWS credits, and integrating with existing IAM controls, monitoring, and security policies. Bedrock adoption also grows significantly among larger organizations and enterprise environments – but this setup can also introduce security risks or unintended configuration mistakes in real-world usage.
If you’re running Claude Code with AWS Bedrock, there’s something you need to know: the AWS credentials you configure for Bedrock don’t stay confined to Bedrock. They might be shared with every shell command, every MCP server, and every subprocess that Claude Code spawns. And depending on how those credentials are scoped, that could mean full access to your entire AWS account.
The Problem in a Nutshell
When you set up Claude Code for Bedrock, you store your AWS credentials in ~/.claude/settings.json:
These environment variables get loaded into the Claude Code process. So far, so normal. The issue is that Unix processes inherit environment variables from their parent. Every time Claude Code runs a shell command, spawns an MCP server, or launches any subprocess, those child processes get your AWS credentials too.
That means any AWS CLI command executed through Claude Code authenticates as your IAM principal. Not just for Bedrock, but for everything that principal has permissions to do.
How This Goes Wrong in Practice
The security boundary here is entirely on the IAM policy side, Claude Code itself applies no restriction. If your IAM user only has `AmazonBedrockLimitedAccess`, the blast radius is minimal. But in practice, credentials often have broader permissions than intended. None of the scenarios below require an attacker or a sophisticated exploit, they’re everyday mistakes that happen when AWS credentials are broader than they need to be.
Reusing your everyday IAM user
You already have an IAM user you use for daily development, like deploying lambdas, reading S3, or managing EC2 instances. Instead of creating a dedicated user for Claude Code, you drop those same credentials into settings.json because it’s faster. Now Claude Code has access to everything you do: production databases, customer data in S3, IAM itself. You meant to give it Bedrock access, but you actually gave it your entire AWS footprint.
Operating on the wrong environment
You’re working on a staging project, but the credentials in settings.json belong to your production account. You ask Claude Code to “delete the old test data from S3” or “terminate the idle instances.” Claude Code generates the right AWS CLI commands for the task, but runs them against production. There’s no visual indicator in Claude Code telling you which AWS account or environment is active. The approval prompt shows aws s3 rm, and you click accept because the command looks correct for what you asked.
Permissions drifting over time
You start with a tightly scoped IAM user for Bedrock only. Months later, someone on your team attaches AmazonS3ReadOnlyAccess for a one-off migration script and forgets to remove it. Then PowerUserAccess gets added during an incident for quick debugging. The Claude Code credentials silently gain more power over time, and nobody audits what it can actually do because “it’s just the Bedrock user.”
Shared credentials across a team
A team lead sets up an IAM user for Claude Code and shares the credentials in a wiki or Slack channel for the team to use. Now multiple developers are running Claude Code with the same identity. There’s no way to distinguish who did what in CloudTrail logs. If one developer’s session is compromised through prompt injection, the blast radius covers everyone using those credentials, and attribution is impossible.
The Attack Scenarios
This isn’t just a theoretical concern. There are several realistic ways this can go wrong:
Accidental over-provisioning is the most likely scenario. A developer uses Claude Code normally, unaware that a “clean up old files” prompt could generate AWS CLI commands touching production S3 buckets or EC2 instances.
Prompt injection is more targeted. An attacker plants malicious instructions in a repository file: a README, a config file, a code comment. When Claude Code reads the file, the injected instruction can influence it to generate AWS CLI commands that exfiltrate data or create backdoor access keys. The user sees an approval prompt but might not catch the malicious intent among legitimate-looking operations.
Compromised MCP servers inherit the full environment as subprocesses. A malicious or supply-chain-compromised MCP server can silently make AWS API calls using your credentials.
What You Should Do
Scope your credentials tightly. The IAM user or role you configure for Claude Code should have the absolute minimum permissions needed, ideally only bedrock:InvokeModel* and related Bedrock actions. Audit what’s attached right now. You might be surprised.
Consider using Bedrock API keys instead of IAM credentials. Claude Code supports AWS_BEARER_TOKEN_BEDROCK, which is inherently scoped to Bedrock operations. API keys can’t be used by the AWS CLI for non-Bedrock operations. This is the most effective mitigation available today and requires no infrastructure changes.
Use temporary credentials. If you must use IAM credentials, prefer STS temporary credentials or SSO-based authentication over long-lived access keys. They at least limit the exposure window.
Pay attention to shell command approval prompts. When Claude Code asks permission to run a command – read it. Look for aws CLI commands that access services beyond what you’d expect. If you see aws s3, aws ec2, aws iam, or similar, think about whether that’s something you intended to allow.
Audit your settings.json. Run aws sts get-caller-identity with the configured credentials and check what policies are attached to that principal. If the answer is anything broader than Bedrock access, tighten it.
The Bigger Picture
This is a classic example of the principle of least privilege being violated through environment inheritance, a well-understood Unix behavior that becomes a security issue when credentials meant for one purpose are implicitly available for all purposes.
Claude Code’s shell command approval prompt provides some protection, but it’s a thin layer. Users lack context about which AWS credentials are active and what permissions they grant. Approval fatigue, the tendency to reflexively accept prompts after seeing enough of them, further erodes this safeguard.
The ideal fix would be credential isolation: Bedrock credentials should be internal to Claude Code and never exposed to shell subprocesses through environment variables. Until that happens, and according to Anthropic, the responsibility falls on you to ensure your credentials are scoped as narrowly as possible.
On May 4th, 2026, The GentlemenRaaS administrator acknowledged on underground forums that an internal backend database (Rocket) had been leaked. This leak exposed 9 accounts, including zeta88 (aka hastalamuerte), who runs the infrastructure, builds the locker and RaaS panel, manages payouts, and effectively acts as the administrator of the program.
The internal discussions provide a rare end‑to‑end view of the operation: they detail initial access paths (Fortinet and Cisco edge appliances, NTLM relay, OWA/M365 credential logs), the division of roles, the shared toolsets, and the group’s active tracking and evaluation of modern CVEs such as CVE-2024-55591, CVE-2025-32433, and CVE-2025-33073.
Screenshots from ransom negotiations were also leaked, showing a successful case where the group received 190,000 USD, after starting with an initial demand (anchor) of 250,000 USD.
Further chats indicate that stolen data from a UK software consultancy was later reused to attack a company in Turkey. The Gentlemen used this during negotiations as a dual‑pressure tactic: they portrayed the UK firm as the “access broker,” while mentioning to provide “proof” to the Turkish company that the intrusion originated from the UK side and encouraging it to consider legal action against the consultancy.
By collecting all available ransomware samples, Check Point Research identified 8 distinct affiliate TOX IDs, including the administrator’s TOX ID. This suggests that the admin not only manages the RaaS program but also actively participates in, or directly carries out, some of the infections.
Introduction
The Gentlemen ransomware‑as‑a‑service (RaaS) operation is a relatively new group that emerged around mid‑2025. Its operators advertise the service across multiple underground forums, promoting their ransomware platform and inviting penetration testers and other technically skilled actors to join as affiliates.
In 2026, based on victims listed on the data leak site (DLS), The Gentlemen appears to be one of the most active RaaS programs, with approximately 332 published victims in just the first five months of 2026. This volume places the group as the second most productive RaaS operation in that period, at least among those that publicly list their victims.
During our previous publication, Check Point Research analyzed a specific infection carried out by an affiliate of this RaaS. In that case, the affiliate used SystemBC, and the associated command‑and‑control (C&C) server revealed more than 1,570 victims.
In this publication, we focus on the affiliate program itself and the actors who participate in it. On May 4th, 2026, The Gentlemen administrator acknowledged the leak of an internal database used by the group, which contained operational information about their infrastructure, affiliates, and victims. Check Point Research obtained what appears to be a partial leak of the group’s internal chats and related data, which was briefly posted on an underground forum before being removed. Later on, the leak also appeared on another underground forum.
The leaked material includes detailed conversations between the RaaS operators and their affiliates across several internal channels (such as INFO, general, TOOLS, and PODBOR). In these chats, they coordinate ongoing intrusions, exchange toolsets and EDR‑kill packages, discuss infrastructure and backend components (including the Rocket database and NAS storage), review CVEs and exploit paths (for example Fortinet, Cisco, and NTLM relay issues), and talk about specific victims, campaigns, and payouts. Together, these messages provide a rare inside view of how The Gentlemen plans, executes, and scales its ransomware operations.
The Gentlemen RaaS Admin
The Gentlemen RaaS administrator has been very active and vocal on various underground forums, trying to attract affiliates with an aggressive profit-sharing model: 90% for affiliates and 10% for the operator.
In September 2025, in one of the first posts promoting the RaaS program, the account Zeta88 published a message advertising the service and inviting individual penetration testers to join as affiliates.
Figure 1 — Zeta88 advertising The Gentlemen’s RaaS.
Later on, the official posts for this ransomware program started to be published by another account, The Gentlemen. The administrator also shared their TOX ID across several forums.
Figure 2 — RaaS admin in underground forum.
The same TOX ID can be seen on the onion data leak site (DLS), where it is used by affiliates or compromised victims to contact the administrator.
Figure 3 — Onion page TOX ID.
In a post on an underground forum, where the administrator demonstrated how affiliates can build the ransomware, we can see the administrator’s profile page, where their TOX ID is again visible in the corresponding field.
Figure 4 — Image uploaded by RaaS admin.
In the second shared image, we again observe the same TOX ID and see how the target or victim entry is supposed to look from an affiliate’s perspective.
Figure 5 — Image uploaded by RaaS admin.
Considering that the initial post was made by Zeta88, it is likely that this account belongs to the administrator and that their TOX ID is F8E24C7F5B12CD69C44C73F438F65E9BF560ADF35EBBDF92CF9A9B84079F8F04060FF98D098E. This assessment is based on the fact that the same TOX ID appears consistently across different contexts: in the early recruitment posts, in the onion data leak site (DLS), and in the screenshots showing the administrator’s profile and communication fields. Taken together, these overlaps strongly suggest that Zeta88, the later The Gentlemen account, and this TOX ID are all controlled by the same RaaS administrator.
RaaS Affiliates
Check Point Research collected most of the available artifacts related to The Gentlemen RaaS from online sources. Based on the current 412 public victims listed on the data leak site (DLS), and considering that there are likely additional victims who paid and therefore were not published, we identified 29 unique campaigns in public sources such as VirusTotal.
For each of these 29 campaigns, we extracted the TOX ID associated with the corresponding affiliate. Our analysis shows that these campaigns were conducted by 8 unique TOX IDs.
There are almost certainly more affiliates involved in this group, however, based on our current locker visibility, we can confidently confirm 29 discovered campaigns and ransomware samples.
Based on this small collection of samples, most of the campaigns appear to have been conducted by the affiliate using the TOX ID 98C132E2B20B531BE6604397D97040C1E9EB42FCE12EDF119BCE8B4031CA5C70DAF5E65FA3C3. It is also noteworthy that the RaaS administrator’s TOX ID has been observed in four unique infections. This suggests that the administrator not only manages the RaaS program but also actively participates in, or directly carries out, some of the infections.
RaaS Leak
On May 4th, 2026, on an underground forum, the RaaS administrator published a post acknowledging the claims of an internal leak involving their so‑called Rocket database, an internal backend system used to store operational data, and addressed his affiliates directly about the incident.
Figure 6 — The Gentlemen RaaS post.
The message continues in a dismissive tone toward the leak seller and then shifts focus back to “more interesting” topics. These include a full overhaul of the communication structure, the deployment of a new NAS with unlimited storage, and several technical upgrades to the locker, such as removing hardware breakpoints, performing NTDLL unhooking, and patching ETW to suppress Event Tracing for Windows.
Demanding ransom from a RaaS
On May 5th, 2026, the account n7778 with TOX ID 7862AE03A73AAC2994A61DF1F635347F2D1731A77CACC155594C6B681D201F7AD6817AD3AB0A advertised the sale of The Gentlemen’s hacked data on underground forums for 10,000 USD, payable in Bitcoin.
Figure 7 — Account selling The Gentlemen RaaS Data.
In the following days, the same account posted two MediaFire links containing proof files supporting the claimed leak.
Figure 8 — Partial leaks.
The first leaked data is a text file that contains the contents of the shadow file from The Gentlemen’s server, including user account entries and their password hashes. The file lists many usernames, among them zeta88, 3NT3R, B1d3n, C0CA, d0wnloAd1, equal1z3r, F3N1X, Gblog88, JLL, LDW, n0n3, PRTGRS, W1Z. Notably, we again see the zeta88 account, the same handle that was used in the initial underground post advertising the RaaS program, further linking this server to the RaaS administrator.
Figure 9 — shadow file content.
The second leaked data set contains partial conversations between the RaaS operators and their affiliates across several internal channels (such as INFO, general, TOOLS, and PODBOR). In these chats, they coordinate ongoing intrusions, exchange toolsets and EDR‑kill packages, discuss infrastructure and backend components, review CVEs and exploit paths, and talk about specific victims, campaigns, and payouts.
While the partial leaked data that we obtained is around 44.4 MB, a screenshot shared by the same account on another underground forum shows a total size of approximately 16.22 GB, which likely corresponds to the full leaked data set.
Figure 10 — Full leaked data screenshot.
Roles & Structure
The group appears to have a clear division of roles and responsibilities. At the core, the main operator and developer, zeta88 (most likely hastalamuerte), runs the infrastructure and builds and maintains the custom ransomware locker, the RaaS panel and builder (Linux with containers and a TOR front), as well as the GPO‑based spread mechanism and the locker’s “spread” module. This operator also curates toolsets in the TOOLS channel, including EDR kill kits and kiljalki collections, selects targets, and assigns them to specific teams, often talking about “targets”, “подбор” (selection) channels, and distributing corporate victims to groups of 2–3 people. In addition, they manage payouts and negotiations, including multi‑million ransom discussions (“переговоры на 10кк”).
Figure 11 — Image shared in the chats, zeta88 – Admin.
Considering our previous assessment that the RaaS administrator also runs campaigns himself (based on TOX IDs), the leaked chats reinforce this view: they show him personally deploying the locker and encrypting at least one victim’s environment.
Figure 12 — zeta88 locking message.
Often, messages sent by zeta88 appear to be copied or adapted from earlier messages made by hastalamuerte, and affiliates frequently mention hastalamuerte by name. Taken together with previous findings and earlier RaaS posts linked to zeta88, these patterns strongly suggest that hastalamuerte and zeta88 are very likely the same person.
Figure 13 — zeta88 – hastalamuerte message.
Below this core role, key operators or affiliates such as qbit and quant handle more hands‑on operational work. qbit is a practical operator on many cases, responsible for scanning and filtering Fortinet VPNs and other edge devices, performing reconnaissance and persistence (including “крепиться клаудом” (English: “to establish persistence via the cloud”) through Cloudflare tunnels or Zero Trust solutions), and using tools such as NetExec (NXC), RelayKing, PrivHound, and NTLM relay scanning. qbit frequently requests clear EDR killer sets, manuals, and guidance for locking ESXi environments, and also brings in new bot or access suppliers (“поставщик ботов”) (English: “supplier of bots”). quant focuses on log‑based access (“логи ЛБ”, i.e. spilled credentials for OWA/O365 and similar services) and maintains a custom log parser and proprietary credential/data collector, referred to as buildx641, which is run from a domain‑joined machine, uses vssadmin, shadow copies, ntds.dit, and SYSTEM copies, and collects and compresses data from multiple hosts. quant is oriented toward OW/OVA spam and higher‑value (“тир1”) (English: “tier‑1”) victims and has set up a powerful “brute server” (Threadripper PRO, 128 GB RAM, RTX 5090) for large‑scale brute forcing.
Around these core and key operators, there are several other accounts, including Wick, mAst3r, Protagor, Bl0ck, JeLLy, Kunder, and Mamba who take on various roles such as red‑teamers, advertising partners, access brokers, or case‑specific collaborators; for example, Protagor is mentioned in connection with OV (online vault/OWA‑type) spam, while Mamba acts as an access broker for Fortinet VPNs sourced from ramp.
Through this specific leak, we identified 9 unique accounts actively communicating with each other: Kunder, qbit, JeLLy, Protagor, zeta88, Bl0ck, Wick, quant, and mAst3r. This internal interaction pattern supports the view that these accounts form a coordinated operational network within The Gentlemen RaaS ecosystem. This number aligns with our earlier assessment based on the unique TOX IDs extracted from the ransomware lockers.
Group members collaborate on various infections and share the profits as well. As a result, the 90% share allocated to the affiliate is often split among multiple affiliates who worked together to achieve a successful intrusion.
Figure 14 — Collaboration and profit sharing.
Based on the analyzed chat messages, the organization’s structure appears to match the model shown in the following image. It is likely that additional members exist who do not appear in this specific leak, but the roles and relationships we observe here are consistent across the available data. There are also indications of an internal separation between trusted members and newcomers—for example, one message notes that “that Rocket is still alive – there are rookies there”—suggesting a tiered or layered structure within the group.
Figure 15 — Organization diagram.
Operational workflow
The conversations from the leak show a fairly standard but well‑organized operational workflow. The group claims to usually gain initial access through exposed edge devices such as VPN appliances, firewalls, and other internet-facing systems, with a particular focus on platforms like Fortinet FortiGate and Cisco. They combine different methods to achieve this, including credential brute‑forcing against web or VPN panels, exploiting known vulnerabilities, and buying access from third‑party “bot” or access brokers. Screenshots shared in the chats also show them searching for accounts and credentials in data‑breach search engines. Once they obtain a foothold, they treat these systems as pivots to move deeper into the internal network.
Figure 16 — Searching credentials & accounts.
After gaining access, the operators perform internal reconnaissance and privilege escalation to understand the environment and obtain higher-level permissions, often aiming for domain administrator access. They rely on a mixture of Active Directory discovery, certificate abuse, and various local privilege escalation techniques. At the same time, they invest significant effort into disabling or bypassing security tools such as EDR and antivirus solutions, using a combination of misconfigurations, registry abuse, logging mechanisms, and bring-your-own-vulnerable-driver–style (BYOD) techniques to tamper with or overwrite security binaries.
With elevated access and reduced defensive visibility, the group focuses on expanding across the network and preparing for the final stages of the attack. This includes lateral movement, establishing additional tunnels or proxies for reliable connectivity, and relaxing security settings to make further operations easier. They also harvest credentials and browser-based sessions to reuse existing access to corporate services. Data exfiltration is then carried out using automated tools and tuned configurations to move large volumes of data efficiently, often targeting NAS devices, backup systems, and virtualization infrastructure. Finally, once the environment is prepared and critical data is in their control, they deploy their custom ransomware “locker,” which is designed to spread quickly across the network, leverage existing administrator sessions, and encrypt systems in a coordinated manner.
Tools & Infra
The leaked conversations show that The Gentlemen RaaS operators use a repeatable and fairly mature toolset to support their operations. For remote access and C2, they rely on frameworks like ZeroPulse and Velociraptor, combined with Cloudflare-based tunnels and custom VPN setups to keep stable access into compromised networks. For offensive operations, they use a range of red‑team utilities such as NetExec, RelayKing, TaskHound, PrivHound, CertiHound, and others to perform Active Directory discovery, certificate abuse, privilege escalation, and file share discovery. A separate group of tools is dedicated to EDR and AV evasion, including EDRStartupHinder, gfreeze, glinker, and DumpBrowserSecrets, as well as techniques inspired by public research on abusing Windows logging and Event Tracing for Windows (ETW). Finally, they support these activities with infrastructure and helper tools like port scanners (gogo.exe), usage guides, OSINT extensions, and password‑cracking services, which together give them a reusable framework for running repeated intrusions and ransomware deployments.
Category
Tool / Resource
Purpose / Usage
Reference / Notes
C2 / Remote Access
ZeroPulse
Remote access / C2 framework for controlling compromised hosts.
https://github.com/jxroot/ZeroPulse
C2 / Remote Access
Velociraptor
Used as a covert C2 platform, including memory and LSASS dumping.
Often used with signed builds to reduce detection.
C2 / Remote Access
Cloudflare Zero Trust / Tunnels
Provides stealthy tunnels into victim networks over HTTPS.
The leaked chats show that the group pays close attention to other ransomware operations, including the leaked Black Basta negotiations. In particular, they discuss Black Basta’s approach to code signing and note how that group allegedly used VirusTotal to search for legitimate code‑signing certificates, which were then targeted for brute‑force attacks on their private keys. The Gentlemen actors refer to this technique as a model they can reuse or adapt, highlighting their interest in abusing trusted certificates to make their binaries look legitimate and harder to detect.
Figure 17 — Code signing conversations.
AI mentions
The Gentlemen mention AI usage in multiple channels and for various purposes. While it is clear that they have already used AI for code‑assisted development, including experiments with Chinese models, more advanced use cases—such as locally deploying models to analyze large volumes of exfiltrated victim data—are only discussed at a conceptual level. These ideas are suggested in the chats but do not appear to be fully implemented.
zeta88 states that he built the GLOCKER admin panel in three days using AI‑assisted coding. He is candid about the limitations of this approach, noting that while AI can speed up development, you still need to understand what you are doing and be able to guide and correct the code it produces.
Figure 18 — zeta88 “vibe-coded” the Panel.
Members share their AI preferences across different chats. zeta88 states that he finds DeepSeek, Qwen, Kimi, and Emi the most effective models for his purposes, particularly for coding assistance and technical queries.
Figure 19 — AI preferences.
He also suggests adding more Chinese LLMs to their toolkit, in addition to those they are already considering or using, such as DeepSeek and Qwen.
Figure 20 — Chinese LLMs suggestions.
A couple of months later, qbit shares in the INFO channel their recommendation for “the most radical neural network, which creates any content without censorship. Runs on Qwen 3.5 with all barriers removed… Zero refusals. Absolutely no restrictions.”
Figure 21 — Qwen 3.5 post.
zeta88 directs affiliates to use AI as a quick reference—for example, to look up FortiGate internals—rather than asking in the channel.
Figure 22 — Usage of AI as quick reference.
For more challenging tasks such as operational data analysis, identifying high‑value access points, and offloading much of the manual data‑triage work to an AI model, the operators explicitly discuss using an uncensored, self‑hosted LLM. However these suggestions appear to remain theoretical, as Protagor admits, “I have no idea how to do that, but I think it’s possible.”
Figure 23 — Local, self-hosted LLM.
Screenshot shared in the chats shows an LLM response on how to send an email to all users via the Jira admin interface, in Russian. It describes two methods, mainly using Jira Automation and user groups.
Figure 24 — Screenshot shared in the chats.
The group appears to be experimenting with well‑known Chinese LLMs and has considered using locally hosted models to assist with data triage on stolen information.
CVEs and Exploits
While the group discusses these vulnerabilities, shares related links, and occasionally attempts to exploit specific systems using particular CVEs, we cannot confirm whether the targeted machines were actually vulnerable to the exact vulnerabilities they referenced.
CVE-2024-55591 – FortiOS management interface
This vulnerability affects the FortiOS management interface and fits directly into their broader focus on Fortinet appliances as high‑value initial access points. While the chats do not show detailed exploitation steps, the presence of this CVE alongside their FortiGate targeting suggests it is part of the set of vulnerabilities they track for potential use against exposed management interfaces.
In the logs, qbit shares a proof-of-concept (PoC) for CVE-2025-32433, and zeta88 comments on its quality and applicability. This shows that the group is not simply aware of the CVE but is actively evaluating whether it can be used in real operations, specifically in environments where Cisco or Erlang-based SSH services are exposed. Even if they are cautious about PoC reliability, the discussion confirms that this vulnerability is part of their potential exploit toolkit.
Figure 26 — qbit & zeta88 related posts.
CVE-2025-33073 – NTLM reflection / NTLM relay
qbit references RelayKing and shares output showing domains being scanned for NTLM relay issues, including checks that explicitly cover CVE-2025-33073. This is strong evidence that they are not just reading about the vulnerability but have integrated RelayKing into their standard reconnaissance process to generate target lists for tools like ntlmrelayx. In other words, CVE-2025-33073 is a vulnerability they actively scan for and intend to exploit as part of broader NTLM relay workflows.
Figure 27 — Mention of CVE-2025-33073.
Other Exploit Paths (Without Explicit CVE IDs)
The operators also make heavy use of technique-based exploits where no specific CVE number is mentioned in the chats. These include:
MSI service abuse via RegPwn, used for privilege escalation.
Veeam to domain admin paths, based on public write‑ups about misconfigured backup infrastructure.
iDRAC to domain admin paths, leveraging Dell iDRAC weaknesses.
WPR, AutoLogger, and ETW manipulation techniques documented by zerosalarium and others to overwrite or disable security binaries.
Payments & Negotiations
Zeta88 acts as the organizer/administrator, distributing cryptocurrency payouts to team members (including those who are “AFK”) and advising on how to cash out proceeds via Bitcoin wallets (Guarda, Trust Wallet, Exodus). The group discusses AML (Anti-Money Laundering) evasion strategies. Zeta88 sends a BTC transaction to Kunder as a payout, which Kunder confirms receiving.
Figure 28 — Transaction link shared.
The specific mentions of how they handle Bitcoin laundering/cash out:
Exchange Chains (“связки обмена”) Zeta88 mentions running ~800 transactions through “buy desks” (скупов) via exchange chains, or sometimes sending directly, suggesting chain-hopping to obscure transaction origins.
AML Checking They discuss whether their BTC is “clean” and reference a buyer who actively checks AML scores before transacting. They’re uncertain how the scoring works but are aware their coins could be traced.
Tinkoff QR Code Cash-Out A specific method mentioned: a buyer converts BTC to cash via Tinkoff bank QR codes, with minimums of 400k rubles (previously 250k). This converts crypto directly to Russian banking infrastructure.
Physical Cash Delivery Kunder mentions “locking in the rate” and a guy physically bringing cash at the end of the month, a classic peer-to-peer OTC (over-the-counter) arrangement that bypasses exchanges entirely.
Wallet Infrastructure They recommend non-custodial wallets (Guarda, Trust Wallet, Exodus) specifically to avoid KYC/AML controls that centralized exchanges enforce.
Blurry screenshots from the leak also shed light on the financial side of the operation. Although not fully legible, they appear to show a negotiation where the group secured approximately 190,000 USD after a discount of about 60,000 USD from the initial ransom demand.
Figure 29 — Agreement to pay 190,000 USD.
zeta88 is very aware of the importance of maximizing pressure on extorted victims to increase the chances of payment. In his private channel, he drafts a generic follow‑up letter that can be adapted to any company, emphasizing the costs of not paying the ransom, including regulatory exposure, reputational damage, and operational impact, and citing assessments from previous attacks. This is not the standard ransom note deployed alongside the encryption, but an additional, more tailored communication intended to reinforce the pressure on the victim.
Figure 30 — Negotiation playbook.
Interesting Negotiation Case
In a high‑profile attack in April 2026, a software consultancy company from United Kingdom publicly reported a breach. The company’s leadership stated in an open letter that only “typical business data, including business contact information, contracts, and NDAs related to client work” had been accessed.
From what appears to be a personal channel used by zeta88, he drafts a ransom demand letter addressed to the UK company, detailing what The Gentlemen claim to have exfiltrated, including customer infrastructure data, secrets, OAuth credentials, and more. The letter explicitly emphasizes potential GDPR violations as leverage to pressure the victim into paying.
Figure 31 — Ransom note.
Two weeks later, the group published the consultancy’s identity and breach details on their data leak site (DLS). According to the internal chats, data exfiltrated from the consultancy was then reused both before and during attacks against a company in Turkey, where The Gentlemen gained initial access via a vulnerable VPN appliance.
Figure 32 — Forti access to company in Turkey.
zeta88 ran this operation alongside Protagor, creating a backdoor Okta service account himself—typical of his intensive, hands‑on involvement in many of the intrusions documented in the leaked discussions. During the same campaign, zeta88 explicitly references data from the UK consultancy breach to cross‑reference and enrich information about the Turkish company, illustrating how prior compromises are used to enrich and support new attacks.
Figure 33 — UK company containing information for Turkish company.
One example mentioned was an internal “Transfer/Migration Document” (in the local language), an internal project document the consultancy maintained in its own collaboration platform describing work they did for the company in Turkey. This document, stolen in the first breach, was then used in the second.
The group discussed how best to use this access for extortion. In their internal chats, they talked about publishing the company from Turkey on their DLS together with a statement that, The access to the company in Turkey was obtained through the compromised consultancy from United Kingdom.
Figure 34 — DLS statement discussions.
This served a dual purpose:
Punishing the consultancy (UK), which the actors described as “a very bad company.”
Increasing pressure on the company in Turkey, by promising to show exactly how they gained access so that, the Turkish would be encouraged to legally pursue the consultancy in UK.
Figure 35 — Initial access proof.
Eventually, the Turkish company was published on the group’s DLS, and the attackers “credited” the consultancy in UK as their “access broker”.
Their View of Other RaaS Programs and Actors
The actors consistently frame the RaaS ecosystem through the lenses of brand strength, payout reliability, and affiliate leverage (percentage splits and control over negotiations). Among the programs mentioned, they clearly distinguish a small “top tier” from a broader landscape of lesser or untrusted players.
Program / Group
Things Discussed
Subjective Sentiment (Their View)
HelloKitty
Name/brand as something they’d like to use; jokes about linking to the real Hello Kitty site and putting (R) everywhere; described explicitly as a “мощный бренд”.
Very positive on brand strength and recognition; sees it as a powerful marketing asset.
Kraken
Mention that “товарищи кракен” wrote to qbit; qbit later says their team might “move” over to zeta88’s side.
Neutral‑pragmatic; current or past orbit, but clearly willing to switch away for better options.
Dragon Force
One of only two programs zeta88 would choose from “all presented”; explicitly says they pay both operators and adverts; only negative comments heard were about their software/panel.
Strongly positive overall; trusted, in the top tier of programs they respect.
Gunra
Listed among candidate PPs for a supplier; zeta88 says “че эт ваще такое…”, and lumps it with Hyflock; calls the operator “этот мудень”.
Negative; unserious / low‑relevance; clear disdain for the operator.
Hyflock
Same context as Gunra; zeta88 dismisses it in the same breath as Gunra, with the same derogatory comment about the person behind it.
Negative; grouped with Gunra as not to be taken seriously.
ShadowByt3$ RAAS
Appears in the candidate list; zeta88 simply comments “хз” (doesn’t know).
Neutral; no formed opinion, neither trust nor distrust expressed.
Anubis
Appears in the candidate list; zeta88 asks “% видел он?”, focusing on what percentage they take.
Cautious / skeptical; interest hinges on profit split; no clear positive trust.
CHAOS
Appears in the candidate list; zeta88 asks whether they will still take that supplier (“возьмут ли они его еще”).
Uncertain; doubts about acceptance / relationship continuity; not a clearly preferred option.
LockBit (tooling)
quant asks what a локбит тулза actually is (builder or decryptor), notes he has not opened it; no explicit evaluation of the group itself.
Curious but cautious; tooling is not trusted or fully understood yet; no explicit sentiment on LockBit group.
Black Basta / Devman
quant asks if “блек баста это девман”; zeta88 speaks harshly about “David” and his link to Devman, calls him “мудак” and “чепуха”, wishes them невыплат (non‑payment).
Strongly negative but personalized; animosity toward David/Devman rather than a structured view of the RaaS.
“Red team” / Mr Beng cluster
Mentions Редтим=красный лотос=арсен=баламут=студент and “мистер БЕНГ”; mocks offer of 15k for “source code” of a C2 built on top of white tools (Velociraptor, etc.); ridicules this as overpriced and based on legitimate software.
Negative; sees them as overpriced grifters repackaging white tools with heavy marketing.
Conclusion
The Gentlemen RaaS program has quickly evolved into a highly active and structured ransomware ecosystem. With over 320 public victims in 2026 and hundreds more systems visible through related infrastructure, it stands among the most productive RaaS operations that maintain a public data‑leak presence. The leaked Rocket backend and internal chats show that this scale is driven not by a loose crowd, but by a small, tightly coordinated core of about 9 named operators and at least 8 distinct affiliate TOX IDs, all organized around the administrator zeta88 / hastalamuerte, who both runs the platform and participates directly in operations.
The leak reveals a repeatable, human‑operated ransomware playbook: initial access through exposed edge infrastructure (such as VPNs and management interfaces), rapid expansion and privilege escalation, heavy investment in EDR/AV evasion and ETW/logging tampering, and systematic use of shared tools for discovery, lateral movement, credential theft, and data exfiltration. The group actively tracks and evaluates modern vulnerabilities, including CVE-2024-55591, CVE-2025-32433, and CVE-2025-33073and combines them with technique‑driven paths like backup and management‑controller abuse and NTLM relay workflows, giving them a flexible exploitation pipeline.
Overall, The Gentlemen exemplifies how contemporary RaaS programs blend productized ransomware with professional intrusion teams. A small, well‑organized set of operators, supported by curated tooling, structured communication channels, and up‑to‑date exploit knowledge, can generate substantial impact in a short time. For defenders, this underscores the need to harden internet‑facing services, close known misconfigurations and relay paths, and monitor for the specific tools, workflows, and TOX‑based communication patterns tied to this group.
TL;DR: A newly disclosed denial-of-service vulnerability, CVE-2026-23870, impacts React Server Components and dependent frameworks, including Next.js App Router deployments. The flaw enables unauthenticated attackers to send specially crafted HTTP requests that trigger excessive CPU consumption during request deserialization, leading to potential service degradation or total unavailability. Imperva Threat Research Group has analyzed the vulnerability and associated attack patterns. Imperva Cloud WAF and On-Prem WAF customers are already protected against exploitation attempts targeting this issue.
The Vulnerability
Researchers recently disclosed CVE-2026-23870, a high-severity denial-of-service vulnerability affecting React Server Components and downstream frameworks such as Next.js. The issue exists in how vulnerable React Server Component implementations deserialize attacker-controlled request payloads sent to Server Function endpoints.
The vulnerability stems from improper handling of cyclic or recursively referenced data structures during request processing. Specifically, vulnerable deserialization logic within the React Flight protocol can repeatedly consume maliciously crafted models before properly marking them as processed, resulting in excessive resource consumption.
In practical terms, an attacker can send a specially crafted HTTP request to exposed Server Function endpoints in applications using React Server Components. When the payload is processed, the server enters a high-CPU execution state that can persist for extended periods before eventually throwing an error. Because the error is catchable and the attack requires no authentication, attackers can repeatedly issue malicious requests to sustain denial-of-service conditions.
The issue primarily impacts:
react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack
Affected versions include:
0.0 through 19.0.4
1.0 through 19.1.5
2.0 through 19.2.4
Patched releases are available in:
0.5
1.6
2.5
Because React Server Components are heavily used in modern application architectures, particularly high-traffic ecommerce, SaaS, and API-driven environments, exploitation can have significant operational impact. Applications leveraging Next.js App Router deployments are especially exposed due to the widespread use of Server Function endpoints.
Some of the techniques observed or associated with exploitation include:
Crafted cyclic model payloads designed to trigger recursive deserialization behavior
Repeated requests to Server Function endpoints to sustain CPU exhaustion
Abuse of React Flight protocol request parsing logic
Application-layer denial-of-service attacks targeting availability rather than data theft
Automated scanning of exposed React and Next.js deployments for vulnerable endpoints
Unlike traditional volumetric DDoS attacks, CVE-2026-23870 enables low-bandwidth, application-layer denial of service by forcing disproportionate server-side computation. This makes the attack particularly attractive because relatively small numbers of malicious requests can create significant backend resource exhaustion.
Bottom Line
CVE-2026-23870 highlights the growing security risks associated with modern server-side rendering frameworks and component-driven architectures. By abusing request deserialization logic in React Server Components, attackers can trigger disproportionate backend resource consumption using relatively low-effort HTTP requests.
Since this vulnerability requires no authentication and targets exposed Server Function endpoints directly, exploitation is straightforward in unpatched environments. Organizations using React Server Components, Next.js App Router, or related server-side rendering frameworks should immediately upgrade affected packages and review exposed application endpoints.
Imperva Cloud WAF and On-Prem WAF customers are protected against related attack activity.
There’s an automated attack circulating right now that breaks into unprotected Redis servers, takes over the underlying machine, and then carefully puts everything back the way it found it. It restores the database filename. It deletes the tools it used. It detaches from the connections it opened. When it’s done, the server looks healthy. Logs look normal. Nothing appears to be wrong.
Except there’s a new line in /root/.ssh/authorized_keys that wasn’t there before.
We discovered this attack recently targeting a single Redis honeypot. Attacks came from 10 distinct source IPs across six countries, and over 1,200 attack attempts were recorded in a single month. Our data-driven, AI-based honeypot enabled us to detect and analyze this activity in detail.
The Attack
Redis was never designed to face the internet directly. But people expose it: a misconfigured security group, a container with the wrong port mapping, a developer who needs it reachable for a quick test. The default configuration has no password. Port 6379, open to the world.
When our Redis honeypot instance was exposed, the first visitors arrived within minutes. They connected, ran INFO, read the version string, and disconnected. That’s it. They aren’t trying to break in. They’re taking a census- cataloging what’s out there, how old it is, whether it’s protected. Thousands of these scans happen every day across the internet, quiet and mechanical.
Then a second wave showed up. These bots tried something: config set dbfilename backup.db. It’s a test. If Redis accepts the command, it means the server will let you write files to arbitrary paths on the host machine’s disk. The bot doesn’t exploit this. It just records the address and leaves. It’s building a list for someone else.
The real attack came as a single connection that tried five different methods of compromise in rapid sequence. The whole thing took a few seconds. It opened with FLUSHDB to wipe the database and clear the slate, and then worked through the following tricks:
Cron injection: redirect Redis’s save directory to /var/spool/cron/, write a key whose value is a cron entry. Now the host downloads and runs a binary from a C2 server every minute, with a randomly generated filename to dodge signature detection.
Lua sandbox escape: a Debian/Ubuntu packaging decision dynamically linked Redis’s Lua interpreter against the system library, breaking the sandbox. One EVAL command loads io.popen, leading to full RCE. CVE-2022-0543 is four years old, yet still working.
SSH key planting: same file-writing trick, pointed at /root/.ssh/authorized_keys. One line, and the operator has root access forever.
Replication hijacking: SLAVEOF tells Redis to sync from the attacker’s server, which serves a malicious shared object disguised as a database dump. MODULE LOAD turns it into a Redis extension exposing system.exec. This trick leads to full RCE through Redis’s own replication protocol.
Direct execution: use that module to download and run the binary through the shell.
Five methods, one connection, a few seconds- but attackers don’t need all five to work. They just need one.
Then the connection did something unexpected. It started cleaning up.
SLAVEOF NO ONE
system.exec "rm -rf /tmp/exp.so"
MODULE UNLOAD system
config set dbfilename dump.rdb
It detached from the rogue replication server. It deleted the malicious shared library from the disk. It unloaded the module from Redis. It restored the original database filename. Redis is often used for ephemeral data, like sessions, queues, and rate limits, so a cleared database might not even raise an alarm. It just looks like a restart.
The attack was optimized for staying hidden after breaking in. Every forensic trace is reversed. The only artifact left behind is an SSH public key, one line in a file that most administrators never read, indistinguishable from a legitimate entry. Even if you find the malware, kill the process, and delete the cron entry, the key is still there. Root access, on demand, forever. Or until someone manually audits authorized_keys, which is rare.
The Botnets
The SSH Key Operator: A sophisticated, single-operator attack that targets unprotected Redis servers. It attempts five different RCE methods. Over a single month, our single Redis honeypot recorded over 1,200 attack attempts from 10 distinct source IPs across six countries. The majority included RCE attempts: Lua sandbox exploits and replication hijacking aimed at arbitrary command execution on the host. Different C2 servers, different binary names, but the same sequence, the same Lua payload, the same SSH public key. One operator, rotating sources and randomizing filenames. The key is the only constant.
The traffic came in distinct waves. Baseline was roughly 15 to 20 attempts per day from two or three sources. Then, without warning, a wave would hit, with a single IP connecting hundreds of times in an afternoon, once every 69 seconds- in total, over 300 attempts in a few hours. We saw three to four waves per month, each lasting two to six hours, each from a different source IP. Then silence until the next wave.
MGLNDD Botnet: A separate operation that periodically connects to exposed Redis servers, sending a single command format (MGLNDD_54.147.241.42_6379) to perform a “roll call” – checking whether the Redis server is already part of their botnet. It operates from Azure VMs using AWS IP addresses, never repeating the same source twice.
The SSH key operator and the MGLNDD botnet share the same hunting ground but ignore each other completely. Two separate operations are working in the same territory. An exposed Redis port isn’t just targeted by an attacker, it’s targeted by an ecosystem.
Takeaway
The attack is silent. The window between “I’ll fix that config later” and the machine is silently compromised isn’t days or hours-it’s seconds. Everything looks fine afterward: the server is up, the application works, the dashboards are green. The only artifact is an SSH key, patient and persistent, waiting to be used.
What You Must Do:
Never expose Redis to the internet. Restrict access via security groups, firewalls, or VPCs.
Set a strong Redis password. The default has none.
Regularly audit /root/.ssh/authorized_keys for unfamiliar keys-attackers hide persistence here.
Keep Redis patched. CVE-2022-0543 still works after 4 years.
Monitor for suspicious commands: CONFIG SET, MODULE LOAD, FLUSHDB, SLAVEOF.
Use file integrity monitoring on /root/.ssh/authorized_keys to detect tampering.
Don’t trust green dashboards. Assume you’ve been breached until verified otherwise.
Imperva Data Security solutions provide comprehensive protection for your data against a wide range of threats. These offerings enable security teams to identify the location of sensitive information, monitor access patterns, and detect misuse promptly to facilitate timely response.
Unit 42 uncovers high-risk AI browser extensions. Disguised as productivity tools, they steal data, intercept prompts, and exfiltrate passwords. Protect your browser.
CVE-2026-41940 is a critical authentication bypass vulnerability affecting cPanel & WHM, including DNSOnly, in versions after 11.40. The flaw, discovered by WatchTowr Labs, exists in the login flow and allows unauthenticated remote attackers to gain unauthorized access to the control panel. The vulnerability carries a CVSS 3.1 score of 9.8 and is classified under CWE-306: Missing Authentication for Critical Function.
cPanel & WHM is widely used to manage web hosting environments. WHM provides administrative access to hosting infrastructure, while cPanel gives individual account holders control over their hosted sites. Because this vulnerability affects the authentication layer of a management interface, successful exploitation could give attackers access to high-value administrative functions across hosting environments. The issue affects all currently supported versions of cPanel & WHM, and the flaw is tied to session loading and saving behavior.
cPanel has released patched versions and recommends immediate updates. Administrators should update a fixed version, verify the cPanel build, and restart the cPanel service. For environments that cannot immediately patch, cPanel recommends blocking inbound traffic on ports 2083, 2087, 2095, and 2096 or temporarily stopping affected services.
Imperva customers are protected out-of-the-box against CVE-2026-41940.
Observations from Our Data
Since the release of CVE-2026-41940, Imperva has observed nearly 4,000 attack requests targeting customer environments.
Our data shows:
Attacks targeting sites across 15 distinct industries and 17 countries, indicating broad scanning and opportunistic exploitation rather than activity concentrated against a single vertical or geography.
US-based sites accounted for almost 70% of observed attacks, followed by Barbados and Israel. The heavy concentration against US sites suggests attackers are prioritizing regions with large hosting and web infrastructure footprints, while the presence of smaller geographies indicates automated discovery across exposed internet-facing assets.
The most frequently targeted industries were Business, Society, and Education. This distribution reflects the broad deployment of hosting control panels across organizations that maintain public-facing websites, portals, and distributed web infrastructure.
While observed volume remains limited compared to mass exploitation campaigns, the spread across industries and countries shows active probing for exposed cPanel and WHM instances. Given the vulnerability’s unauthenticated nature and impact on administrative access, even moderate request volumes warrant urgent attention, and attack volumes will likely grow.
Mitigation and Protection
The definitive remediation for CVE-2026-41940 is to update cPanel & WHM to a patched version immediately. Organizations should also review cPanel’s detection guidance, inspect session files for indicators of compromise, and audit WHM access logs for unauthorized activity. cPanel’s advisory specifically recommends purging affected sessions, forcing password resets for root and WHM users, and checking for persistence mechanisms if indicators of compromise are found.
Imperva customers using Cloud WAF and WAF Gateway are protected against exploitation techniques associated with CVE-2026-41940. Imperva’s web application firewall inspects HTTP traffic for malicious patterns, helping block attempts to abuse authentication workflows and session-handling behavior before they reach vulnerable systems.
For customers with Cloud WAF, protection is automatically applied. Customers with WAF Gateway should refer to the manual mitigation guide sent by Imperva support teams and provided in the Imperva Community Guide.
Conclusion
CVE-2026-41940 represents a critical risk for organizations running exposed cPanel & WHM infrastructure. Its combination of unauthenticated access, low attack complexity, and potential administrative impact makes it a high-priority vulnerability for patching, monitoring, and incident review.
Imperva customers are protected against exploitation attempts associated with this vulnerability through Imperva’s web application firewall protections and HTTP traffic inspection capabilities. Organizations running cPanel & WHM should still apply vendor patches immediately, validate their deployed versions, and review available logs and session artifacts for signs of compromise.
When Anthropic unveiled Mythos and Project Glasswing, the reaction was immediate and polarized. Some dismissed it as fear-driven marketing, while others treated it as a credible shift in the threat landscape.
Like with many things, the truth is probably somewhere in the middle. I wanted to test that for myself, and since I recently got access to OpenAI’s Trusted Access for Cyber program, I decided to take it for a spin.
GPT-5.4 identified the bugs and helped assemble a working exploit chain, but it wasn’t a simple “build me an exploit” prompt. Guiding it required domain knowledge, iterative probing, and knowing which paths were actually exploitable.
On modern browsers like Safari, exploitation is less about finding bugs and more about finding bugs that still matter after multiple layers of defense.
The bug I’m going to talk about today sits in a more interesting category. The bug itself looked contained, and in many ways it was. It did not provide a path to RCE or a sandbox escape. What it did instead was cross a different boundary entirely: it broke the Same-Origin Policy.
If you visited a malicious page from any Apple device, it could read authenticated cross-origin data from other sites you use, including access tokens and other sensitive data, making account takeover trivial.
The video below shows the PoC we sent Apple, demonstrating leakage of sensitive data from both Apple Connect and iCloud / Apple ID endpoints. Although this demo focuses on Apple services, the issue affects all websites. This means that by visiting a malicious website, sensitive data from other domains is at risk of being leaked.
The Sandbox Russian Doll
Browser exploitation in 2026 is a lot like being trapped in a Russian doll.
You start in the smallest doll, and every time you escape one layer you discover you are still trapped inside another one.
Finding a low-level memory bug is not the same thing as finding an exploit. Most of these bugs die in the gap between “memory corruption happened” and “something meaningful crossed a security boundary.”
On the outside you have the browser process model. Even if renderer code goes wrong, the browser is trying very hard to keep that damage inside the web content process.
Inside that you have the web security model: Same-Origin Policy, CORS, opaque responses, cookie scoping, and credential modes. Even if a page can trigger a cross-origin request, the renderer, and especially the Gigacage, should not be able to access the response bytes. Right?…
The Bug
The original bug lives in the refresh logic for non-shared resizable WebAssembly memory.
When a non-shared WebAssembly.Memory grows in BoundsChecking mode, JavaScriptCore can replace the underlying memory handle. That part is not the bug. The bug is what happens after that to the JS-visible resizable buffer returned by memory.toResizableBuffer().
The bug is simple enough that once I saw it, it was hard to unsee it. Safari’s grow path effectively does this:
And the refresh step effectively does this:
After memory.grow(), WebKit updates the buffer metadata, but leaves m_data pointing at the old freed allocation.
So after a grow, JavaScript can hold a buffer whose reported size is new, whose handle is new, but whose actual data pointer still references the old freed Primitive Gigacage allocation.
That turns into a stale typed-array window over freed memory.
On its own, this is already a real bug. But we’re still stuck inside the JavaScriptCore gigacage, effectively sandboxed. Without a second bug to break out into the renderer, it doesn’t chain into anything meaningful. What we have is a solid first-stage primitive, but no real security impact on its own.
Why it did not look exploitable at first
The stale window is confined to the Primitive Gigacage, which immediately limits what you can do with it. Many typical targets either never land there, lack useful structure, or fail to produce any cross-boundary effect.
So early on, it had all the hallmarks of a bug that looks promising but rarely goes the distance:
easy source-level root cause
visible stale memory behavior
real reclaim
no clean escape path
This is where a lot of low-level browser bugs die.
What changed the problem was a very different framing: maybe I did not need to escape the cage at all.
Maybe I just needed the browser to place something valuable inside it.
The Pivot
Instead of asking “how do I get from my stale WASM view to some protected browser state?” I started asking a better question:
“What browser code takes data that JavaScript is not allowed to read, but still copies that data into normal renderer memory?”
Because that is all I need.
I don’t need to break the abstraction.
I just need the browser to break it for me.
That naturally narrows the search space to subsystems that:
handle sensitive cross-origin data, and
still allocate ArrayBuffer-backed memory as part of their internal pipeline
That points straight at Fetch. The Fetch API clearly indicates that the response is opaque, meaning that its headers and body are not available to JavaScript.
Opaque Responses Are Supposed to Be Opaque
At the API level, the Fetch model here is straightforward.
The browser may send the request, including cookies depending on context, but JavaScript receives an opaque response.
That means:
I can hold the Response object
but I cannot read the body bytes
And WebKit enforces that in the obvious place:
FetchBodyOwner::readableStream() blocks opaque bodies via isBodyNullOrOpaque().
So at first glance, everything looks fine. The body is hidden. The policy is enforced. Same-Origin Policy survives another day.
Except it does not.
The Fetch Behavior that Broke the Modal
The surprising part is Response.clone().
If FetchResponse::clone() is called while the response is still loading, WebKit will internally create a readable stream so it can tee the body between the original response and the clone.
That internal path does not apply the same opaque-body check first.
And once that happens, hidden response bytes start becoming very real renderer objects.
This is the part that made me stop and stare at the source, because the mismatch is right there.
The normal body path blocks opaque responses:
But FetchResponse::clone() does this while the response is still loading:
That is why it works.
The visible accessor path says “opaque bodies do not get a stream.” The clone path says “if it is still loading, create a stream so both clones can tee it.”
That second path is exactly what I needed.
The data flows through normal ArrayBuffer creation paths:
buffered chunks go through tryCreateArrayBuffer()
later chunks go through takeAsArrayBuffer()
shared buffer data gets copied into ordinary ArrayBuffer allocations inside the renderer
So the policy ends up split in two:
the public Fetch API says the body is opaque
the renderer still materializes the opaque body into readable byte arrays during clone-time streaming
Combined with the stale WASM window, it becomes a SOP break.
The Chain
At a high level, the exploit became:
Force the target WASM memory into the BoundsChecking path.
Call memory.toResizableBuffer().
Grow the memory.
Keep the stale resizable buffer whose pointer still targets freed Primitive Gigacage pages.
Trigger a cross-origin fetch(…, { mode: “no-cors”, credentials: “include” }).
Call response.clone() while the response is still loading.
Let Fetch internals materialize the hidden body bytes into ordinary renderer ArrayBuffers.
Reclaim the stale WASM-covered pages with those allocations.
Read the cross-origin bytes through the stale view.
That is the entire trick.
I never needed response.text(). I never needed response.arrayBuffer(). I never needed the public API to hand me the body.
The browser copied the body into memory for its own internal bookkeeping, and the stale WASM view read it directly.
That is why this bug stopped being “some weird WASM UAF” and became “this completely breaks the Same-Origin Policy.”
The file:// Detour
One of the weirdest parts of the research was that the request side behaved differently depending on where I launched it from.
In my testing, cross-origin requests were much easier to get moving from file:// than from a normal https attacker page.
That sounds backwards until you look at WebKit’s handling of local origins.
Document.cpp has explicit special-casing around local documents and settings like:
allowUniversalAccessFromFileURLs
allowFileAccessFromFileURLs
MiniBrowser exposes those knobs too, which made file:// very useful as a research environment. It let me focus on the memory side and confirm the leak path before I had a clean web-facing story.
But I did not want a local-file party trick.
I wanted a real web exploit.
And from a normal https page, the same request pattern was not giving me the reliability I wanted.
That is where about:blank saved me.
Why about:blank saved the final POC
The final PoC opens an about:blank popup and performs the fetches from there:
This ended up mattering a lot.
At first I thought this was just an origin-inheritance trick. That part is real:
So about:blank does inherit the opener’s origin.
But that alone does not explain why the popup path behaved differently.
What actually seems to matter is Safari’s cookie / first-party bookkeeping. Fetch subresource requests copy document->firstPartyForCookies() into the request:
And WebKit’s cookie blocking logic bails out immediately if that first-party domain is empty:
That is a very different path from a normal attacker-controlled https page. From a regular https://attacker.example origin, the first party is the attacker site, so a request to the victim site looks third-party and Safari’s tracking-prevention logic can suppress cookies.
From the about:blank popup path, the security origin still comes from the opener, but the popup’s top-level URL / first-party context is no longer a normal registrable https site in the same way. In practice, that was enough to make credentials: “include” requests behave differently and get me the authenticated traffic pattern I needed.
So the important point is not “about:blank disabled CORS.” It did not. The important point is:
the popup kept the opener’s origin
the request still went through normal Fetch/CORS code
Safari’s first-party cookie logic treated that popup context differently
That was the difference between “cross-origin request happens but is useless” and “cross-origin request comes back with authenticated bytes worth stealing.”
Why this was fun
This is my favorite kind of browser bug.
Not because the root cause was complicated. It was not. The WASM bug was almost embarrassingly direct.
And not because the final chain was huge. It was not.
It was fun because it is exactly the kind of bug modern browser architecture is supposed to suppress.
A stale pointer inside a cage is supposed to stay a stale pointer inside a cage.
An opaque response is supposed to stay opaque.
Those are both reasonable assumptions.
The exploit works because both assumptions were true only locally.
JavaScriptCore gave me a stale view that looked hard to use. WebCore Fetch gave me sensitive bytes that looked impossible to read.
Put them together and Safari’s Same-Origin Policy fell apart.
Disclosure
We reported our findings to Apple. Shortly after, a fix shipped, suggesting the issue was already known internally.
The vulnerability (CVE-2026-20664) is addressed in iOS 26.4 and iPadOS 26.4 (23E6254 and later), and macOS Tahoe 26.4 (25E253 and later). Make sure your systems are up to date.
Closing Thoughts
The biggest thing on my mind after working with these models is the leverage they provide, and what that means for N-days. A security patch in popular software used to hide the underlying exploit behind time, effort, and expertise. Now that you can scale tokens instead of effort, that barrier is mostly gone.
This doesn’t turn exploitation into a trivial task. You still need someone who understands what they are looking at, can filter noise, and can steer the process when it stalls. But AI changes the unit of work. Instead of deep, sequential effort, you get parallel exploration and rapid iteration. The constraint shifts from raw effort to how effectively an operator can guide multiple lines of inquiry at once.
`
Unit 42 reveals how multi-agent AI systems can autonomously attack cloud environments. Learn critical insights and vital lessons for proactive security.
The recent buzz around Anthropic’s Mythos model has been intense, and for good reason. Early reports suggest a model that significantly advances automated reasoning over large codebases, vulnerability discovery, and exploit generation. Some are already calling it a “game changer” for offensive security.
But like most breakthroughs in AI, the reality is more nuanced.
Let’s unpack what Mythos is, why it’s getting so much attention, and where the real impact will (and won’t) be.
What Is Mythos, and Why It Matters
At its core, Mythos is designed to operate deeply within software systems:
It can reason across entire codebases, not just snippets
It demonstrates strong capabilities in multi-step vulnerability discovery
It can potentially chain findings into realistic exploit paths
This is what sets it apart from earlier models. Traditional LLMs often struggled with:
Context fragmentation (limited memory of large systems)
Superficial pattern matching (vs. true reasoning)
Weakness in multi-stage attack logic
Mythos appears to push beyond that, closer to what human security researchers do when analyzing complex systems.
That’s the hype. Now let’s put it into perspective.
1. Closed Systems Still Have a Natural Advantage
One of the most important constraints, often overlooked, is access.
Organizations running:
Licensed binaries
Closed-source products
SaaS platforms
are inherently less exposed to this class of AI-driven analysis.
Why? Because Mythos appears to be most effective when it has full visibility into the source code. Without that:
Reverse engineering binaries is still hard and lossy
SaaS environments expose only interfaces, not logic
This creates a natural barrier for attackers.
Although “security through obscurity” isn’t a solution, in practice:
Open-source projects and exposed codebases will feel the impact first
Closed vendors still need to worry, but they’re not suddenly transparent overnight
2. The Real Pressure Point: Time-to-Mitigation
AI doesn’t just change what attackers can do, it changes how fast everything happens.
And this is where security vendors feel the most pressure. The challenge isn’t whether vulnerabilities exist, it’s how fast vendors can respond once they’re discovered.
The new race:
AI/ human finds vulnerability →
AI Exploit is generated quickly →
Attack traffic emerges earlier →
Defenses must adapt in near real-time.
This shifts the competitive advantage to vendors that can:
Automate security workflows to
Rapidly understand new attack patterns
Generate mitigations
Deploy protections before mass exploitation
3. The Budget Reality: AI Red-Teaming Isn’t Cheap
One of the least discussed aspects of Mythos is cost.
Running such a model at scale involves:
High compute costs
Expensive infrastructure
For example, Anthropic admitted that “Across a thousand runs through our scaffold, the total cost was under $20,000” for finding vulnerabilities in OpenBSD.
Significant human validation effort
And that last part is critical.
Every finding still requires:
Verification (is it real?)
Reproduction
Impact assessment
Which means more security engineers per finding, not less.
Organizations will need to start budgeting for:
AI-assisted red teaming
Dedicated pipelines to process findings
Integration into SDLC workflows
This mirrors what we’ve already seen with GitHub Copilot-style assistants and AI-based code analysis tools.
Implication for attackers:
These “doomsday” capabilities are not evenly distributed.
Otherwise, teams risk wasting cycles on low-quality reports and missing real vulnerabilities buried in noise. Ironically, AI will be needed to defend against AI-generated reports.
5. Not All Vulnerabilities Are Equal
Another important nuance:
Finding a vulnerability ≠ exploiting it at scale.
Even with Mythos:
Many findings will be low impact
Exploitation may require environment specific conditions
Real-world constraints (auth, rate limits, monitoring) still apply
This is where traditional security layers still matter:
WAF, API protection, Bot protection
Identity protection
Data protection
Threat reputation
Mythos increases discovery capability, but doesn’t eliminate defense in depth.
Final Thoughts
The Mythos model presents a meaningful step forward. It brings AI closer to acting like a real security researcher, capable of deep reasoning and complex analysis.
But it’s not a universal “break everything” button.
Closed systems still provide friction
Costs limit widespread misuse
Defensive technologies remain highly relevant
Operational processes (triage, mitigation) become the real bottleneck
The hype focuses on capability. The reality is about constraints and execution.
And as always in cybersecurity, the winners won’t be those with the best tools, but those who can operationalize speed, from detection to mitigation, at scale.
In this article, we disclose a new high severity unauthenticated remote denial‑of‑service vulnerability we identified and reported in React Server Components that we’ve dubbed “React2DoS”. In this blog, we’ll analyze its impact and place it in the broader context of recently found Flight protocol vulnerabilities, especially CVE‑2026‑23864.
Introduction
We are in a phase of the web where performance and developer experience are no longer trade-offs, they’re expectations. Modern frameworks compete to ship less JavaScript, reduce client-side complexity, and move logic back to the server.
React, as one of the dominant forces in frontend development, has been at the forefront of this evolution. With the introduction of React Server Components (RSC), the ecosystem embraced a new model: components that execute exclusively on the server, access databases and secrets directly, and stream a serialized UI representation to the client.
This architecture promises smaller bundles, cleaner separation of concerns, and more efficient rendering. Instead of hydrating everything on the client, Server Components emit a structured stream that the browser reconstructs locally.
At the heart of this mechanism lies a custom streaming protocol known as Flight. Through Flight, React can serialize complex structures, like arrays, maps, object references, even promises and async boundaries, allowing the server to describe rich UI trees in a compact format.
This is powerful.
But history has shown that when we introduce custom serialization formats and complex parsers, we also introduce risk. The server must deserialize and reconstruct object graphs from client-controlled input. And complex parsing logic has long been fertile ground for vulnerabilities.
In our research we discovered a denial-of-service vulnerability that allows an attacker to impose disproportionate computation to the remote server.
React2Shell and subsequent DoS vulnerabilities
Earlier this year, the disclosure of React2Shell caught much of the community off guard, triggering emergency patches and intense scrutiny of the React Server Components architecture, amplified by waves of low-quality AI-generated analysis that blurred the line between verified facts and speculation. This episode also prompted deeper investigations into and led to new discoveries related to the security of the Flight protocol and related parsing mechanisms.
CVE‑2026‑23864 (CVSS 3.1 of 7.5), stood out as a notable example and serves as a useful reference for understanding the mechanics behind the issue we explore in this research.
Among other vectors, this vulnerability concerned the BigInt deserialization path in Flight:
$n markers denote BigInt values
No limit was enforced on digit length
Therefore, sending a million‑digit BigInt could cause a significant computation cost, and CPU exhaustion. An example payload could look like this:
0:"$n9999999999...[repeated 1 million times]"
In our setup, a single query like this could delay the server’s execution by several seconds if the inbound payload reaches the maximum allowed size (1MB with Node.js runtime, 10MB with Edge runtime).
This was the starting point of our research, and we tried to find payload that would trigger a similar, or superior cost to the server. This is exactly what we found, actually more computationally-intensive by several orders of magnitude.
React2DoS
React relies on a mechanism known as the React Flight Protocol to serialize values that are sent to Server Functions.
On the client side, data is transmitted to the server as small pieces (or “chunks”), for example through form submissions:
As illustrated above, these chunks can reference one another.
After deserialization on the server, the reconstructed object looks like this:
{ "category": "vehicle", "model": "tesla" }
At first, we tried to measure the cost of execution of every type of reference supported by the Flight protocol. Among them, we looked at two promising ones: $Q and $W, respectively instantiating new Maps and Sets from the client request payload.
The first observation we made was that it was possible to reference the root element in the root element itself (!), which paved the way to recursive expressions:
“0” : [“$Q0”]
This, would cause the execution of the following JavaScript expression:
New Map([null])
Which makes perfect sense, because at the time of resolution of $Q0, $0 is not known yet.
However, what surprised us, was the fact that the following expression:
“0” : [“$Q0”, “$Q0” ..., “$Q0”] (x n)
did trigger the execution of the Map constructor n times!
Indeed, the ReactFlightReplyServer uses a `consumed` attribute to prevent multiple computations of the same reference and prevent abuse. But this mechanism only enters in action when the reference is successfully resolved (see Fig 1).
Fig. 1: Exception doesn’t prevent recomputation of the same faulty Map
Because the `new Map` expression failed (new Map([null]) is not a valid JavaScript expression), this outcome was not stored anywhere. But surprisingly, the deserialization is not interrupted by this exception!
The execution of the expression `new Map ([null])` is pretty cheap, it takes our server around 0.03ms. Virtually instant. But this is neglecting the fact that a threat actor can insert more than 100,000 instances in a 1MB payload, leading to the cost of several seconds, comparable to the CPU exhaustion issue behind CVE‑2026‑23864 and described above.
Considering this, we submitted a first report to Meta, sharing this POC and demonstrating the impact.
But soon after, we realized there was a way more impactful payload we could generate by exploiting our original idea.
Instead of sending a series of “$Q0” that would immediately trigger the exception, we decided to introduce a series of valid map entries at the start of the root entry, to force the Map constructor to iterate over them before triggering the expected exception (see Fig. 2).
Fig. 2: Internal recursive resolution of “$0”
By doing so, we achieved a quadratic complexity, and a much more expensive payload ! The optimal number setting is n/2 valid maps and n/2 map references to the 0 object (“$Q0”).
CVE‑2026‑23864 (CPU exhaustion) vs React2DoS (CVE-2026-23869)
With our new attack vector, the computation could easily last several minutes. Therefore, with only small payloads of tens of kilobytes, it was possible to initiate impactful DoS attacks.
To give ourselves an idea of the impact of this attack vector, we computed a chart showing the comparison between CVE‑2026‑23864 (CPU exhaustion) and React2DoS. The result showed that after only a few kilobytes, React2DoS starts to stand out, and when the payload size reaches hundreds of kilobytes, it is already more powerful by several orders of magnitude (see Fig. 3).
Fig. 3: Comparison React2DoS – CVE‑2026‑23864
Therefore, with a single request, a threat actor can trigger a computation that will take minutes to handle. By repeating this, complete denial of service can be achieved.
Mitigation
The React team fixed this issue via setting the consumed flag before any map/set constructor was called.
The issue affects React Server Components version 19.2.4 and below. We recommend that you update to the latest available version that patches this vulnerability as soon as possible.
If your application already sits behind an Imperva proxy, it is automatically protected against this attack.
Conclusion
This case highlights an important reality: the path to innovation inevitably introduces complexity, and therefore risk. As ecosystems evolve rapidly, staying up to date and remaining aware of newly discovered security issues is essential.
In a more personal way, it was a pleasure for me to delve into one of the most used framework in the world and discover a finding with meaningful impact. This wouldn’t have been possible if researchers before didn’t pave the way with their investigations and their recent findings (React2Shell, CVE‑2026‑23864…).
Unit 42 uncovers escalating Kubernetes attacks, detailing how threat actors exploit identities and critical vulnerabilities to compromise cloud environments.
Unit 42 research on multi-agent AI systems on Amazon Bedrock reveals new attack surfaces and prompt injection risks. Learn how to secure your AI applications.
Login
