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.

The post CVE-2026-23870: Imperva Customers Protected Against Critical React Server Components DoS Vulnerability appeared first on Blog.

Introduction

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.

The post Your Redis Server Looks Fine. That’s the Problem. appeared first on Blog.

Unit 42 uncovers high-risk AI browser extensions. Disguised as productivity tools, they steal data, intercept prompts, and exfiltrate passwords. Protect your browser.

The post That AI Extension Helping You Write Emails? It’s Reading Them First appeared first on Unit 42.

What is CVE-2026-41940?

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.

The post Imperva Customers Protected Against CVE-2026-41940 in cPanel & WHM appeared first on Blog.