Reading view

Imperva Customers Protected Against “wp2shell” Pre-Authentication RCE in WordPress Core

TL;DR: A critical pre-authentication Remote Code Execution (RCE) vulnerability, dubbed “wp2shell” (CVE-2026-63030), has been identified in WordPress Core. This vulnerability allows an unauthenticated attacker to execute arbitrary code on a vulnerable WordPress installation without any preconditions, such as plugins or specific configurations. 
Given that WordPress powers over 500 million websites, this vulnerability poses a significant risk to the global web ecosystem. 

Vulnerability Overview  

The vulnerability exists within the WordPress REST API, specifically affecting the /wp-json/batch/v1 and ?rest_route=/batch/v1 endpoints. An unauthenticated attacker can exploit this endpoint to achieve RCE.

Affected WordPress Versions: 

  • 6.9.0 – 6.9.4 (Fixed in 6.9.5) 
  • 7.0.0 – 7.0.1 (Fixed in 7.0.2) 

(Note: WordPress versions older than 6.9.0 are not affected by this specific vulnerability.)

Mitigation and Protection 

Imperva customers with both Cloud WAF and WAF-GW deployments are protected against exploitation attempts associated with the “wp2shell” vulnerability. Cloud WAF automatically inspects and blocks requests targeting the vulnerable REST API endpoints at the edge, mitigating the risk before it reaches your backend services. 

For organizations utilizing WAF-GW, we are providing policy updates to further harden protection. Administrators should apply the latest security policy updates to their WAF-GW environments to ensure these enhanced inspection capabilities are active. These updates provide another layer of defense, blocking the specific patterns associated with unauthorized batch API access before they can be processed by the WordPress core.

Recommended Best Practices 

While Imperva provides protection at the edge, we strongly recommend that all WordPress administrators take the following steps: 

  1. Update Immediately: Ensure your WordPress installation is updated to the latest secure versions (6.9.5 or 7.0.2) as soon as possible. This is the only definitive way to resolve the underlying vulnerability. 
  2. Emergency Mitigation: If an immediate upgrade is not possible, you can temporarily mitigate the risk by blocking access to the affected REST API endpoints:
    • Block requests to the path: /wp-json/batch/v1
    • Block requests containing the query parameter: rest_route=/batch/v1 

Note: These mitigation measures may impact legitimate site functionality and should only be used as a temporary stopgap until you are able to perform the necessary software updates. For more technical details regarding the vulnerability discovery, please refer to the official research advisory from Searchlight Cyber. 

The post Imperva Customers Protected Against “wp2shell” Pre-Authentication RCE in WordPress Core appeared first on Blog.

  •  

Imperva Customers Protected Against CVE-2026-49975 (HTTP/2 Bomb) DoS

TL;DR: CVE-2026-49975, dubbed the “HTTP/2 Bomb,” is a critical remote Denial-of-Service (DoS) vulnerability affecting default HTTP/2 configurations of major web servers including NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora. Discovered by security firm Calif using OpenAI’s Codex, the attack combines a unique HPACK compression bomb variant with a Slowloris-style flow-control window hold to cause immediate server outages and memory exhaustion. NGINX and Apache have rolled out fixes, while others remain exposed. Imperva customers are fully protected against exploitation attempts associated with this vulnerability.

About CVE-2026-49975

On June 3, 2026, California-based cybersecurity firm Calif disclosed a novel, highly disruptive remote denial-of-service attack chain tracked as CVE-2026-49975. The exploit targets structural similarities across default HTTP/2 protocol implementations, potentially threatening over 880,000 websites operating on default stack configurations.

Remarkably, the vulnerability chain was identified using OpenAI’s Codex. The AI model parsed multiple public codebases, recognizing that two distinct techniques, (each public or partially resolved for nearly a decade), could be seamlessly chained together to cripple enterprise web servers.

The exploit functions by combining two distinct phases:

  1. The Bookkeeping Compression Bomb (HPACK): Unlike traditional compression bombs that expand huge, stuffed data strings to trigger decoded-size limits, this variant relies on an optimized, nearly empty header payload. Instead of triggering maximum header restrictions, it forces the server to spend immense memory allocations purely on the internal per-entry bookkeeping and structural tables of the HTTP/2 HPACK scheme.
  2. The Flow-Control Slowloris Hold: Once the massive internal memory overhead is forced, the attack client advertises a zero-byte flow-control window. This effectively forces the server to hang, preventing it from sending a response while concurrently resetting the send timeouts. The connection stays active, trapping the allocated server memory indefinitely.

Because the attack vectors utilize standard, valid HTTP/2 frame properties, an unauthenticated attacker using a basic home computer over a 100 Mbps connection can exhaust up to 32GB of server memory within 20 seconds, knocking targeted infrastructure offline almost instantly.

CVE 2026 49975 blog

What We’ve Seen

Following the public disclosure, Imperva Threat Research has been actively tracking reconnaissance and proof-of-concept (PoC) validation activity corresponding to the newly released guidelines.

Because the exploit relies on native HTTP/2 frame manipulations, specifically targeting HPACK table modifications combined with restrictive WINDOW_UPDATE flow mechanics, initial traffic patterns show distinct automated probing behavior rather than standard application-layer payloads. Attackers are running specialized tools designed to map out whether target servers handle aggressive, dense bursts of small header blocks under restricted windows without terminating the connection. Given that HTTP/2 is almost universally adopted across modern web infrastructure, any unpatched asset running default configurations of the affected servers remains a viable target for these generic probes.

Mitigation and Protection

Organizations are advised to audit their web server footprints and apply vendor updates immediately:

  • NGINX: Upstream fixes were quietly addressed in version 1.29.8+ and supported branches in April.
  • Apache HTTPD: Fixes addressing the specific chaining behaviors have been integrated into late-May releases.
  • Microsoft IIS, Envoy, and Cloudflare Pingora: Default configurations remain exposed at the time of writing; organizations using these platforms should closely monitor infrastructure memory thresholds or consider temporarily disabling HTTP/2 on unpatched public endpoints if downstream mitigations are not in place.

Imperva Protection

Imperva customers with Cloud WAF deployments are protected against exploitation attempts associated with CVE-2026-49975. Cloud WAF automatically inspects and manages anomalous stream and frame structures at the edge, mitigating malicious HPACK anomalies before they reach backend services.

For organizations utilizing Imperva WAF-GW protecting environments where HTTP/2 is enabled, administrators should take immediate action to verify that HTTP/2 Header Restrictions are actively applied and enforced within their security policies. Ensuring these granular protocol constraints are enabled provides a critical layer of defense, blocking the dense, high-frequency header bookkeeping manipulation characteristic of the HTTP/2 Bomb exploit before it can consume backend server resources. For detailed configuration steps, please refer to the following KB article.

Bottom Line

CVE-2026-49975 represents a significant shift in threat discovery, showing how agentic AI capabilities can systematically bridge known, siloed software behaviors into destructive new exploit chains. Because the “HTTP/2 Bomb” requires minimal bandwidth to trigger complete memory exhaustion across major web servers in their default states, patching and perimeter mitigation are urgent priorities.

Imperva customers remain protected. Imperva Cloud WAF and WAF Gateway inspect and drop malicious stream and frame structures, ensuring that anomalous HPACK table definitions and malicious flow-control holds are neutralized at the edge before they can induce memory stress on backend enterprise systems.

The post Imperva Customers Protected Against CVE-2026-49975 (HTTP/2 Bomb) DoS appeared first on Blog.

  •  

Imperva Customers Protected Against React Server Components (RSC) Vulnerability

Overview

On December 3, 2025, the React and Next.js teams disclosed a critical security vulnerability (CVSS 10.0), identified as React2Shell, affecting applications that leverage React Server Components together with Server Actions or Server Functions.

The React2Shell vulnerability stems from improper validation of client-supplied data within certain server-side React features. An unauthenticated attacker could exploit this flaw by sending specially crafted requests, leading to unexpected server-side behavior. Successful exploitation could result in unauthenticated remote code execution.

This vulnerability requires no authentication and affects a wide range of modern React/Next.js deployments.

What Causes the Vulnerability

The affected functionality involves the mechanism React uses to receive and interpret data for server-side features. Certain malformed or intentionally crafted inputs may trigger unsafe processing paths on the server.

The React and Next.js teams have released security updates that strengthen these validation steps and prevent unintended behavior.

Impact

The vulnerability allows unauthenticated remote code execution (RCE) on servers running React Server Components.

Applications using React Server Components are vulnerable even if they do not explicitly define Server Function endpoints.

In effect, a malicious actor can send specially crafted requests to a vulnerable server and, due to insecure deserialization of serialized payloads, trigger unintended server behavior including arbitrary code execution.

As of this advisory, there is no evidence of active exploitation in the wild. However, numerous unauthorized or fake proof-of-concept (POC) exploits have been circulated publicly, which may cause confusion or unintended harm if tested without proper validation.

Affected Versions:

  • React: 19.0.0, 19.1.0–19.1.1, 19.2.0
  • js (App Router): 15.x ≤ 15.5.6, 16.x ≤ 16.0.6

Patched versions:

  • React: 19.0.1, 19.1.2, 19.2.1
  • js: 15.5.7+, 16.0.7+, 16.1+

Imperva Proactive Response

Imperva’s Threat Research team initiated an immediate investigation to assess the potential impact on customer environments.

Within hours, we:

  • Analyzed the vulnerability and mapped out the most plausible exploitation paths
  • Developed and validated virtual patching rules designed to detect and block malicious request patterns associated with the issue
  • Rolled out these protections automatically across the entire Imperva Cloud WAF customer base

All cloud protections are already active, require no change from customers, and continue to be monitored and refined as new information becomes available. On-prem customers should review the Community Guide to manually deploy this policy.

Conclusion

This is a significant framework-level security issue affecting widely used technologies. Imperva customers are already protected through our rapid response and proactive security controls. We will continue to track this vulnerability closely and update protections as new information becomes available.

While Imperva protections mitigate known attack vectors, customers should:

  1. Update React and Next.js to the vendor-provided patched versions
  2. Review any server-side features that accept data directly from clients
  3. Continue monitoring vendor advisories for future updates

For further assistance, please contact Imperva Support or your Customer Success representative.

The post Imperva Customers Protected Against React Server Components (RSC) Vulnerability appeared first on Blog.

  •  
❌