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.

At Wallarm, we’re constantly working to deliver new capabilities and enhancements to customers. We’re pleased to announce three new features for our Security Edge customers. 

Custom Block Pages

Security Edge now supports the ability to configure custom block pages. These pages are returned in response to blocked malicious activity in addition to the 403 response. This new capability gives customers the ability to provide a branded response to blocked traffic. Read more about custom block pages in Security Edge in the documentation. 

Access Control Lists

Security Edge now supports the creation and management of Access Control Lists (ACLs) defining which IP addresses can access specific hosts and locations of your APIs. ACLs are created as part of the Security Edge configuration and apply to Security Edge nodes. Read more about ACLs in the documentation. 

Content Caching

Security Edge now supports caching rules, defining how Security Edge Inline nodes store and reuses responses from specific hosts and locations. When cache rules are configured, the system stores and reuses responses to frequent requests instead of reprocessing them, reducing load on your backend servers, lowering response times, and improving user experience. You can read more about caching rules in the documentation. 

We have introduced configurable rate limiting in AASM to give customers greater control over scan intensity and to help protect their servers from excessive load.

🔧 What’s New

AASM now enables users to define maximum request rates across several dimensions:

• Per Tenant — limits the total number of requests per second sent to a client’s entire infrastructure.
• Per Domain — limits the requests per second for each domain and its subdomains.
• Per IP — limits the requests per second sent to each IP address, helping prevent unintended overload when multiple subdomains resolve to the same host.

Rate limits can be configured in the AASM “Configure” section. By default, no RPS limitations are enforced.

💡 Important Note

Applying rate limits may increase overall scan duration, depending on the configuration.

We’ve released a number of improvements to the Schema-Based Testing capabilities within the Wallarm platform.

Broken Authentication (OWASP API2) Testing

Schema-based Testing now includes extended coverage for Broken Authentication (OWASP API2) issues in OpenAPI-based scans. The new checks help uncover common weaknesses such as missing authentication enforcement, weak token validation, JWT tampering, and exposed credentials in query strings.

Running Tests Without a Test Policy

You can now run tests without creating a predefined Test Policy. All parameters for a test run can be provided directly at runtime, allowing scans to be executed entirely from the command line. This provides greater flexibility for integrating Wallarm testing into automated workflows and CI/CD pipelines.

The capability supports both OpenAPI and Postman-based scans, and the “Generate test run command” wizard helps quickly prepare the required Docker command.

Other Updates

Additional improvements make test management more transparent and configurable.

You can now define success criteria for each test run directly in the UI, specifying the severity level of security issues that will mark a test run as failed.

New status tracking and filtering options also make it easier to monitor progress and review results efficiently.

Schema-Based Testing is available as part of Wallarm Security Testing. Read more about Schema-Based Testing in the documentation. 

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+. 

We’ve made observability simpler, faster, and more powerful for Security Edge customers! 

Starting today, you can view and filter your inline node logs directly inside the Security Edge Telemetry Portal, giving you immediate visibility into what’s happening across your API traffic in real time.

What’s New

You’ll now find a new dashboard under:

Telemetry Portal → Wallarm → Inline Node Logs

From there, you can explore both access logs and error logs with powerful built-in facets, including:

• region: view traffic by data center or PoP
• host: isolate activity for specific APIs or services
• request_method: focus on GET, POST, DELETE, and more
• nginx_status / upstream_status: identify failed requests and backend issues
• remote_addr / upstream_addr: trace requests from source to origin
• request_uri / req_id: drill into specific transactions or sessions

Each facet supports wildcard and regex matching, making it easy to narrow results and quickly find what you need, whether you’re troubleshooting, validating configuration changes, or analyzing API behavior.

Why It Matters

Before this improvement, inline node logs for Security Edge were only available through a support request.

Now, everything is available in one place, giving you:

• Faster troubleshooting without leaving the portal
• Unified visibility across all inline nodes
• Reduced operational overhead with no manual access or forwarding required

This Security Edge update brings greater transparency into the filtering layer, allowing your teams to diagnose issues and validate traffic handling directly from the Telemetry Portal.

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.