WAF

When your WAF needs its own WAF

Security products have their own security issues, which can affect products that they were designed to secure. It's not a recursive loop, but the reality. WAFs there are not an exclusion.

You can remember CloudFlare self-DoS that happened last year (https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/) because of an issue in RegExp signature they applied. Or Imperva's data breach that disclosures API keys of their clients https://krebsonsecurity.com/2019/08/cybersecurity-firm-imperva-discloses-breach/

The latest thing with ModSecurity (https://www.secjuice.com/modsecurity-vulnerability-cve-2019-19886/) is another one example of how it's possible to shut down an entire webserver by just a little cookie. I mean the COOKIE header inside HTTP request. Funny, that theMiddle is initially tried by find a bypass for cookie parser itself, to put SQLi, XSS, RCE, and other attacks there avoiding blocking at the WAF side.

The DoS exploit they found is simple and dangerous at the same time. Basically, any cookie value with an empty name will cause the crash. Like this:

curl -H 'COOKIE: =crashyou;' https://localhost
from https://www.secjuice.com/modsecurity-vulnerability-cve-2019-19886/

Since some of our customers are still using ModSecurity for some applications, and Wallarm for API security, multi-tenancy, and other cases, we decided to release a virtual patch on it. Yes, this is strange a bit to protect WAF by another one WAF, but the mission is so critical when it's possible to crash the server by a single request.

From the GUI, it looks like HEADER COOKIE, than COOKIE parser applied to the value there, and an empty key as the value.

From the wconsole shell, available for standalone customers, it seems like this:

HintStorage.create(type:'vpatch', action: [], clientid: <ID>, point: Proton::Point.new([[:header, "COOKIE", :cookie,""]]), attack_type: "any" )

As a result of applying this virtual patch, requests with an empty COOKIE name with some value or without it will be blocked.

So, that's pretty much everything for today. Stay secure with Wallarm!

Recent Posts

From Agent2Agent Prompt Injection to Runtime Self-Defense: How Wallarm Redefines Agentic AI Security

Is an AI-to-AI attack scenario a science fiction possibility only for blockbusters like the Terminator…

1 week ago

CISO Spotlight: Lefteris Tzelepis on Leadership, Strategy, and the Modern Security Mandate

Lefteris Tzelepis, CISO at Steelmet /Viohalco Companies, was shaped by cybersecurity. From his early exposure…

2 weeks ago

2026 API and AI Security Predictions: What Experts Expect in the Year Ahead

This is a predictions blog. We know, we know; everyone does them, and they can…

3 weeks ago

Update on React Server Components RCE Vulnerability (CVE-2025-55182 / CVE-2025-66478)

The attack landscape has been dynamic following the disclosure of the React Server Components RCE…

4 weeks ago

2025 in Review: A Year of Smarter, Context-Aware API Security

As the year draws to a close, it’s worth pausing to look back on what…

4 weeks ago

Wallarm Halts Remote Code Execution Exploits: Defense for Vulnerable React Server Component Workflows

On December 3, 2025, React maintainers disclosed a critical unauthenticated remote code execution (RCE) vulnerability…

4 weeks ago