Two new connectors, for SAP API Management and Traefik, plug Wallarm into more of the platforms that already front your APIs. Their traffic gets inspected right where it flows, and the APIs behind it land in the same Console as the rest of your estate.

These connectors are for one situation: your APIs sit behind SAP API Management or Traefik, and you want Wallarm working at that gateway. If your current deployment already sees that traffic, you're set. Carry on.

What's new

SAP API Management

Protect the APIs you publish through SAP API Management. Wallarm inspects their traffic at the gateway, so the attacks against those APIs, and the APIs themselves, show up in the Console you already use. Run it inline to block malicious requests before they reach your backend, or out of band to inspect copies of the traffic without adding a millisecond to response time.

Traefik

A Wallarm middleware plugin for Traefik 2.x and 3.x in Kubernetes. No sidecars, no traffic mirroring. Requests route through a Wallarm node you host, so inspection and enforcement stay on infrastructure you control.

Same detection, same inventory

Traffic through either connector feeds the same attack detection and API Discovery as the rest of your deployment. There's no new dashboard to learn. Attacks show up in Attacks, and the APIs show up in API Discovery, right where you'd look for them.

Your detection hasn't changed. What's changed is where you can put it.

Learn more in the SAP API Management connector and Traefik connector documentation, or see all Wallarm connectors.

Attack traffic can create a lot of noise. Incidents represent the signal.

An incident is an attack that hit a real security issue in your application and got a response proving it worked. The new Incidents page puts that signal in the same interface you already use for Attacks. The attacks that matter most now get the same investigation flow as everything else.

There's nothing to install and nothing to migrate. The new page shows up in your dashboard automatically.

Only confirmed incidents appear here. If it's on this list, it got through.

What's new

A dashboard for what got through
See requests with incidents over time. Alongside the chart you get the top source IPs, endpoints, hosts, attack types and subtypes behind them, plus a breakdown of the response codes your application sent back.

A month of incidents, and who and what was behind them.

Grouped the way you investigate
Incidents are grouped by attack type, then HTTP method, domain, path, and the parameter the payload landed in. Open any level to drill down, all the way to individual requests.

The exact attack that became the incident
One request can carry several attack payloads, and usually only some of them hit a vulnerability. The request details now mark the one that raised the incident, so you don't have to guess which payload did the damage.

One incident, 120 requests, and the RCE payload flagged with the vulnerability it exploited.

Severity on every row
The Security Issues column shows the severity and state of each linked issue. If something is critical and still open, you'll see it without clicking in.

Shareable views
Your filters and time range live in the page address. Reload, bookmark, or drop the link in a ticket, and the same view opens for whoever clicks it.

Export
Export the incidents in your current view, filters included, for incident response or reporting.

Links into Incidents from the Threat Prevention dashboard and from Security Issues now open the new page.

Your detection and your security issues haven't changed. What's changed is how fast you get from "something got through" to the exact request that did it.

Learn more in the Incidents documentation.

Your WAF rules just got a lot easier to read. Same rules, same enforcement, new interface.

There's nothing to install and nothing to migrate. Your existing rules carry over exactly as they are, and the new interface shows up in your dashboard automatically.

Rules are where Wallarm's detection depth becomes yours to direct. A rule can target any part of a request, including a value buried deep inside a nested payload. The problem was never what rules could do. It was seeing what they covered without opening them one at a time. That's what we fixed.

What's new

Every rule type in one view
Browse all of your rule types from a single panel instead of clicking through a tree of hosts and paths. Pick a type to narrow the list, or look at everything at once. Each view has its own address, so you can bookmark a filtered list or send it to a teammate.

Every rule type, right from the start.

Visible request targeting
You can now see the exact part of the request each rule applies to, right in the list. A rule might point at a value several layers deep: a field inside a JSON object, inside a Base64 segment, inside a JWT, inside a request header. The full path shows up on the row. So the next time someone asks which of your parameters a rule covers, you can just look.

Filters for applications and scope
Narrow the list to specific applications, or separate the rules Wallarm creates and manages for you (marked Default, and not editable) from the ones your team built. Filters live in the address bar, so your view survives a reload.

Rule management in the list
Enable or disable a rule without deleting it, duplicate one as a starting point for the next, and clear out the ones you don't need anymore. All from the list, with endpoints, applications, and last updated on every row.

Creating a rule works the same way. You build the target one step at a time, choosing from the options that are valid at each step.

Cookie → JWT → Base64 → JSON → sub, built one step at a time.

Your rules and the way they're enforced haven't changed. What's changed is how fast you can find, read, and manage them.

Sometimes you need visibility into your APIs without touching production traffic.

Wallarm’s TCP traffic analysis engine now supports AWS VPC Traffic Mirroring, so you can mirror traffic from your AWS environment to a Wallarm Node and see what’s happening across your APIs, without adding latency or changing your request path.

What you get

Mirror traffic directly from your AWS Elastic Network Interfaces (ENIs) and unlock:

• API Discovery — Know what APIs you actually have
• API Session analysis — Understand how they’re being used
• Attack detection — See threats targeting your APIs

All out-of-band. No impact to live traffic.

What’s new

• Support for Geneve-encapsulated traffic (used by AWS Traffic Mirroring)
• Support for VXLAN encapsulation
• Native compatibility with AWS traffic mirroring workflows

Why it matters

Some environments require absolutely zero added latency. Others just prefer to observe instead of actively block.

This gives you a clean way to get API visibility and threat detection in AWS without changing how your traffic flows.

Get started

Check out the documentation to start mirroring your AWS traffic to Wallarm.

The new Wallarm NGINX Ingress Controller 7.0 is now available. This release is based on the open-source NGINX Ingress Controller and is fully integrated Wallarm security services. It replaces all previous versions based on the Community NGINX Ingress Controller, which is end of life in March 2026.

Who should upgrade: Teams currently running the Community-based Wallarm Ingress Controller are strongly encouraged to migrate. The upstream Community NGINX project has been retired. If you are running previous versions of the Wallarm NGINX Ingress Controller, there will be no further security updates, bug fixes, or updates of any kind. 

A migration guide from Wallarm is available.

Full deployment guide: https://docs.wallarm.com/7.x/admin-en/installation-kubernetes-en/

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.

We’re excited to introduce the Native Node, a new deployment option for the Wallarm Node that operates independently of NGINX. This solution was developed for environments where NGINX is not required or where a platform-agnostic approach is preferred. 

The Native Node allows both request and response analysis with Wallarm connectors. It is currently designed for connectors and supports deployment with MuleSoft, Cloudflare, and CloudFront. 

In addition, the Native Node now supports new connectors, allowing you to secure APIs running through Kong API Gateway and Envoy, expanding its use for modern API management solutions.

To provide flexibility across various self-hosted environments, we have released several deployment artifacts for the Native Node:

• All-in-one installer for Linux-based machines
• Docker image for containerized environments
• Helm chart for Kubernetes deployments

If you are wondering if Native Node is right for your deployment, please contact support or read the documentation. 

We are excited to announce the release of Wallarm Node 5.0! This major update represents a significant shift in our technology stack, bringing enhanced performance and scalability to your Wallarm deployment.

Key Highlights:

• New Technology Stack: The Wallarm node has been re-engineered from a Ruby-based implementation to Go, resulting in a faster, more scalable, and resource-efficient solution.
• Performance Improvements: The Wallarm Postanalytics module’s performance has been improved:
  • CPU Usage: Reduced from 0.5 CPU cores to just 0.1 CPU cores.
  • Memory Usage: Lowered by 400 MB at a traffic rate of 500 requests per second.

File System Updates:

• Consolidated Logging: Logs from almost all services are now recorded in a single file, wcli-out.log, simplifying log management.
• Updated Diagnostic Script Path: The diagnostic script has been moved to /opt/wallarm/collect-info.sh from its previous location.

Important Notes:

• This release focuses on technical refactoring and does not introduce any changes in functionality. All features supported in the previous version (4.10) are retained in 5.0.

For a detailed overview of all changes and update instructions, please refer to our updated documentation.