In addition to the vulnerabilities previously published, React has disclosed new vulnerabilities affecting applications using React Server Components.

• Denial of Service (DoS) — High severity, CVSS 7.5
   CVE-2025-55184, CVE-2025-67779: Crafted requests can exhaust server resources, causing hangs or service unavailability.
  
  
• Source Code Exposure — Medium severity, CVSS 5.3
   CVE-2025-55183: Specially formed requests may lead to disclosure of server-side source code

These issues affect the same React Server Components request handling surface as React2Shell (CVE-2025-55182) but do not enable remote code execution. The previously released React2Shell fixes continue to prevent RCE, while these new vulnerabilities impact availability and confidentiality.

Recommendations:
Upgrade to the latest patched React versions and review the exposure of React Server Components endpoints.

Wallarm mitigation:
To protect customers who aren’t using blocking mode across all apps and APIs, Wallarm has rolled out a virtual patch that blocks exploitation regardless of whether customers use blocking or monitoring mode. Please contact support if you’d like to opt out.

We have introduced a new grouped view for security issues to enhance visibility and streamline analysis.

• Automatic Grouping of Similar Issues
   Security issues sharing the same title, type, risk level, and discovered-by fields are now automatically grouped into a single entry. This grouped view is enabled by default, and users can easily switch back to the atomic view using a simple toggle.
  
  
• Enhanced Issue Exploration
   Users can expand any group to view all individual issues within it, along with their affected resources and current statuses.
  
  
• No changes to existing workflows: all filters continue to operate as expected, and bulk actions remain fully supported within grouped issues.
  
  

This enhancement significantly simplifies issue triage and analysis by reducing noise and helping teams focus on patterns and trends, rather than scanning through repetitive entries.

Update: The vulnerability is being actively exploited in the wild. To protect customers who aren’t using blocking mode across all apps and APIs, we rolled out a virtual patch that blocks exploitation of CVE-2025-55182 regardless of whether customers use blocking or monitoring mode. Reach out to support if you want to opt out.

A critical flaw (CVE-2025-55182) in React Server Components was publicly disclosed together with a working PoC. We are already seeing active exploitation attempts, including early scans and payload variants.

Wallarm Protection

Wallarm provides protection against attacks leveraging this CVE out of the box. We started detecting and blocking early exploitation attempts immediately after disclosure. Additionally, Wallarm has deployed new detection rules specifically targeting malicious RSC requests and PoC-derived payload patterns.

Summary & Technical Details

The vulnerability allows attackers to send malformed RSC metadata and tampered component streams, which can lead to:

• Unauthorized access to server-side data
• Manipulation of serialized RSC payloads
• Potential remote code execution depending on application logic

Impact

Successful exploitation may result in data exposure, privilege escalation, or server-side execution in vulnerable setups.

Recommendation

Update React to the latest patched release as soon as it becomes available.

Wallarm now supports OpenAPI Specification (OAS) v3.1 for API specification enforcement. 

Customers using the API specification enforcement feature in Wallarm can now upload specifications in the OAS v3.1 format. Wallarm will correctly interpret the specification format and keywords. 

Read more about specification enforcement in the documentation. OAS v3.1 support requires node 6.6.1+. 

The Security Issues page is now the centralized point for storing and tracking vulnerabilities detected by any module of the Wallarm platform. The previous Vulnerabilities section in the Events is now deprecated.

This unified section consolidates data from:

• AASM (Advanced API Security / API Attack Surface Subscription)
  
  
• Schema-Based Testing (Security Testing subscription)
  
  
• Threat Replay Testing (Advanced API Security and Security Testing subscriptions)
  
  
• Passive Detection (WAAP and Advanced API Security subscription)
  
  

All vulnerabilities are unified, classified, and prioritized according to a single methodology, enriched with CWE and OWASP classifications. The Security Issues page provides statistics charts, flexible filters, including negative filters, and bulk actions for efficient vulnerability management.

Vulnerability management actions, such as marking false positives, closing, reopening, or commenting, are now standardized across all detection sources. The Historical and Resolution charts aggregate data from multiple modules, and the “Discovered by” filter allows users to view security issues originating from specific components. Read more in the documentation. 

We’re continually working to expand and maintain our deployment options for Wallarm filtering nodes. We have three updates to share regarding connector-based integrations. 

New Azure APIM Connector:

For customers with APIs managed by Azure APIM, Wallarm now offers a new connector to collect relevant API traffic for analysis. This connector can be deployed in both synchronous and asynchronous modes. 

Read more about our Azure APIM connector in the documentation. 

Updated Apigee Connector: 

Wallarm has updated our existing Apigee connector to parse and analyze API responses in addition to requests. This change expands the Wallarm features supported by the connector. 

Read more about our Apigee connector in the documentation. 

Updated Akamai Connector: 

Wallarm has updated our existing Akamai connector to parse and analyze API responses in addition to requests. This change expands the Wallarm features supported by the connector. 

Read more about our Akamai connector in the documentation. 

Wallarm delivers outstanding automated attack protection, but there are situations where you want to create custom criteria, rules, and thresholds for taking action. Previously, these capabilities were distributed within Wallarm rules and triggers, making it complicated to manage. In order to streamline the process of configuring and managing custom response actions, Wallarm has introduced Mitigation Controls. 

You can find Mitigation Controls as a separate menu item in the Security Controls section of the menu. The new Mitigation Controls capability brings together a collection of response options in a centralized, easy to manage interface. Here you can configure capabilities like blocking modes, GraphQL policies, custom BOLA protection, and more. 

The configuration and response options available for each mitigation control vary based on the control, providing you with the information you need to generate the mitigation results you want. Mitigation Controls are available with node 6.5.x+. Existing customers with configured triggers for Brute Force, Forced Browsing, and BOLA will be individually migrated once all nodes are compatible. Read more about each mitigation control and their configurations in the Wallarm documentation.

Attackers are evolving — rotating IPs, spreading abuse across multiple requests, and bypassing traditional defenses. In this environment, simply detecting attacks is not enough. Security teams need precise tools to stop attacks without breaking customer experiences.

With the introduction of session-based blocking, Wallarm gives customers surgical control over active attacks. This capability allows teams to terminate compromised API sessions in real time, even when attackers switch IPs or distribute activity, while keeping legitimate users unaffected.

Wallarm now offers three advanced options for active attack mitigation:

• Block Individual Requests — Instantly shut down malicious requests such as SQL injection, RCE, and path traversal exploits.
• Block IP Addresses — Eliminate abusive IPs proactively or reactively when needed.
• Block Compromised Sessions (New) — Target and terminate malicious sessions to neutralize sophisticated, multi-request API abuse.

Unlike traditional IP-based blocking, session-based blocking focuses on attacker behavior, not network location. It enables security teams to stop ongoing attacks with granular precision, preserving user experience while strengthening API defenses.

Users can enable API session blocking in their API Abuse Prevention profiles and in specific Mitigation Controls. 

You can read more about using session-based blocking in the Wallarm documentation. 

We’re excited to announce that Schema-Based Testing is now generally available as part of the Wallarm Security Testing suite.

This release introduces Dynamic Application Security Testing (DAST) for APIs, enabling shift-left API testing and seamless integration into CI/CD pipelines and the SDLC process.

Key Highlights

Expanded Vulnerability Coverage:

• OWASP API Top 10 risks
• Business Logic flaws (BOLA, BFLA)
• Input validation issues (Injections, RCE, Path Traversal)
• Environment misconfigurations
• GraphQL misconfigurations

Supported Inputs:

• OpenAPI specifications
• Postman collections (for advanced testing of business logic scenarios and access control violations)

Schema-Based Testing runs on a lightweight Docker-based agent, ensuring fast and isolated execution. It supports both one-time scans for quick assessments and continuous testing integrated into CI/CD pipelines, making it flexible for different stages of the development lifecycle.

Test results are available locally for immediate review and are also synced to the Wallarm Console, where issues can be tracked and prioritized. Users can define a configurable risk-level threshold to automatically determine when a test run should fail, aligning security checks with organizational policies. You can learn more in the Wallarm documentation.

Attackers continue to adapt and Wallarm continues to innovate API protection. We’ve introduced improvements to API Abuse Prevention in order to improve detection of Account Takeover (ATO) attacks. Wallarm now supports two additional machine learning detectors. 

IP Rotation

The IP rotation detector identifies account takeover attacks where attackers utilize a pool of IP addresses to perform an attack. In these types of attacks, the session remains stable, with cookies, headers, and other key fields unchanged, but each request or a small set of requests is made from a different IP address, often using each IP only once. This results in a single long session involving multiple IPs.

The detector analyzes this IP diversity within a consistent session to flag sophisticated automated attacks that evade traditional security measures.

Session Rotation

The Session rotation detector identifies account takeover attacks where attackers rotate session identification to avoid detection. In these types of attacks, a unique session (e.g., a cookie-based ID) is assigned to each client, but an attacker intentionally modifies or removes the session identifier. This results in one attacker using a single IP address with multiple sessions.

The detector analyzes this unusual behavior of high session diversity from the same IP to detect sophisticated automated attacks.

Both of these new detectors were created to better identify anomalies in API traffic that indicates an account takeover attack. You can read more about API Abuse Prevention in the documentation.