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/

Your attack surface doesn’t stop at domains. Now your visibility doesn’t either.

We’ve rolled out a set of API Attack Surface Management (AASM) updates that expand what you can scan, speed up how you validate fixes, and make it easier to share what actually matters.

What’s new?

• Scan IPs and network ranges
  Go beyond domains and hosts. You can now scan single IPs, subnets, and CIDR ranges to uncover more internet-facing assets and hidden exposure.
• Security Report Card (PDF)
  Get a clean, executive-ready snapshot of your security posture—plus your 10 most critical findings—in a concise, shareable format.
• Rescan a single host
  No need to rerun everything. Quickly rescan one asset to validate fixes and confirm remediation.

Why it matters
Attack surfaces are messy. Assets live outside neat domain boundaries, fixes need verification, and stakeholders want clear answers.

These updates help you:

• Find more assets you didn’t know you had
• Validate fixes faster without slowing down your workflow
• Communicate risk clearly to both technical and non-technical audiences

Where to find it

• IP and network scans → AASM Configuration
• Security Report Card → Share Report widget
• Host rescan → Available per asset

Read more in our documentation.

You shouldn’t have to guess who changed what in your Wallarm configuration. Now you don’t.

We’ve introduced a fully redesigned Activity Log that gives you a clear, attributable record of every action across your Wallarm platform so you can move faster, stay compliant, and actually trust what you’re seeing.

What’s new?

• Full event coverage: Track configuration changes, access updates, and system activity in one place
• Clear attribution: See exactly who performed each action and when. No more detective work
• Operational clarity: Quickly understand what changed and follow up with the right person
• Compliance-ready logging: Built to support audit requirements across regulated industries
• Enterprise-friendly: Designed for teams with multiple users and shared responsibility

Where to find it Settings → Activity Log

Documentation

Better inputs. Better outputs. Better control.

We've improved Wallarm's Schema-Based Testing with updates that make it easier to plug into your existing workflows and test APIs the way you actually run them.

What’s New

RAML Support
Upload RAML files as input. We’ll automatically convert them to OpenAPI specifications so you can get testing without rework.

JUnit Output for CI/CD
Export test results in JUnit format for clean CI/CD integration. Your pipelines stay happy. Your developers stay informed.

Full Request & Response Log Export
Need visibility? Export complete logs for all requests and responses to support troubleshooting, validation, and reporting.

mTLS Support
Mutual TLS authentication is now supported, so you can test APIs that require stronger identity verification.

Because the fastest way to reduce API risk is to test it before someone else does. You can learn more about these capabilities in the documentation. 

Security teams don’t need more noise. They need fewer distractions.

False Positive Rules are now Generally Available, giving you the ability to automatically mark security issues as false positives (or prevent them from being created) based on conditions you define.

You can:

• Create rules from Security Issues → Configuration
• Generate a rule directly from an existing issue using Ignore similar issues
• Suppress findings for specific parameters, endpoints, hosts, or vulnerability types

Rules are evaluated before issues are created and apply across API Attack Surface Management, Threat Replay Testing, Passive Detection, and Schema-Based Testing. If an issue is auto-marked as false, the change is logged in Status History.

Simple idea. Less clutter. More focus on real threats.

API sessions are one of the most powerful ways to understand what’s really happening across your APIs. They give you the context you need to investigate suspicious behavior, connect related requests, and block bad actors without disrupting legitimate users.

The catch? Session configuration isn’t always obvious, especially if you didn’t build the API yourself.

That’s where Wallarm steps in.

We already know your APIs inside and out thanks to API Discovery, including the parameters and headers they actually use in production. Now we combine that data with a little LLM-powered intelligence to recommend the right session context parameters for each API.

What’s new?

When you configure API sessions, Wallarm now suggests parameters based on real API discovery data. You can review the recommendations, select what makes sense, and start getting meaningful session insights in minutes, not days.

Why it matters

Less guesswork. Faster setup. Better session context from day one.

Use Wallarm’s recommendations to get more value from API sessions across your environment and focus on stopping attacks, not tuning configs.

Ready when you are, and our documentation is here to help. 

We’ve given the Wallarm documentation portal a refresh, and it’s a little more than a new coat of paint.

The updated experience makes it easier to find what you need, when you need it, whether you’re getting started, digging into a specific feature, or troubleshooting in the middle of a busy day. A clearer structure helps you navigate across products with less guesswork, and our new AI-powered search gets you to relevant answers faster without ‘tab overload.’

Take the updated docs for a spin at docs.wallarm.com and see how much smoother finding answers can be.

Your API security data has a story to tell. Unfortunately, it’s been distributed across multiple tools … until now. 

Today, we’re introducing customizable API security dashboards with BI-style views that bring API traffic, attack activity, and user or account behavior together in one clear, usable place. No duct tape. No spreadsheet gymnastics. Just answers.

Every day we see teams stitching together signals from WAFs, API gateways, log platforms, and SIEMs just to answer basic questions like:

• Which APIs are under attack right now?
• Which consumers or accounts are involved?
• Is this traffic surge a business win—or a security problem?

The result? Slow investigations, inconsistent reports, and executives getting one-off summaries that don’t reliably connect API security to real business impact. That’s not a tooling problem. That’s a visibility problem.

With customizable dashboards in Wallarm, teams get ready-to-use views built directly from live API traffic, attack telemetry, and user activity.

Out of the box, dashboards include live charts for:

• API call volume and traffic trends
• Top endpoints and API consumers
• Error rates and latency patterns
• Attack counts and affected accounts

Time-range selectors and quick filters let you zoom in on exactly what matters: an incident, a single API, or a suspicious consumer. Save views for recurring questions, and export charts to PDF when it’s time to brief leadership.

These dashboards make abnormal behavior obvious and actionable. Security teams can quickly see what’s under attack and which accounts are at risk Platform teams get clarity on which endpoints need attention. Leaders get clean, repeatable summaries that actually tell the same story every time

Fewer tools to juggle. Less manual reporting. Faster, shared understanding across teams. Check out the pre-configured Security Metrics dashboard or build your own from scratch. Read more in our documentation. 

Security Edge now provides JA4 TLS client fingerprinting to identify bots and automated tools regardless of IP address or User-Agent spoofing. JA4 analyzes TLS handshake characteristics (cipher suites, extensions, supported groups) to create unique client identifiers that reveal the actual implementation, not just what the client claims to be.

Key Capabilities

• Passive extraction during TLS handshake with zero latency impact
• Threat detection for known malicious tools (Burp Suite, sqlmap, scrapers)
• Bot classification distinguishing legitimate from malicious automation
• Rate limiting by fingerprint to prevent IP-rotation attacks
• Forensic logging for audit trails and incident investigation

Use Cases

Credential Stuffing Prevention
Detect automated tools even when attackers rotate IPs and User-Agents.

API Abuse Prevention
Block scraping tools and unauthorized clients that appear as legitimate traffic.

Multi-Cloud Security
Consistent client identification across hybrid deployments regardless of network topology.

Compliance Logging
PCI-DSS compliant connection logging with forensic-grade client identification.

JA4 fingerprinting is enabled by default in Security Edge with node version 6.7.4-1 and later. For additional information, check out our documentation. 

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.