Bishop Fox named “Leader” in 2024 GigaOm Radar for Attack Surface Management. Read the Report ›

Zero-Day Collaboration: Working With Imperva to Eliminate a Critical Exposure

String of blue purple lights


During a recent investigation, the Bishop Fox Cosmos Adversarial Operations experts identified a WAF rule bypass in the Imperva Cloud Web Application Firewall. Through our coordinated Responsible Disclosure Process, Bishop Fox notified Imperva, kicking off a great collaboration between teams to share information about the exploit. This cooperative effort enabled Imperva’s team to quickly develop a patch and deploy it in record time to the Imperva Global Network.

We believe that this type of collaborative work between organizations is a model for how Responsible Disclosure can and should work. It also illustrates how offensive and defensive security organizations can combine forces to ensure the best outcomes for organizations and continually improve security.

Bishop Fox’s Approach to Responsible Disclosure

At Bishop Fox, we are focused on improving security for everyone. When we find vulnerabilities, our goal is to work with organizations to close potential attack windows as quickly and efficiently as possible. We don’t believe in leveraging vulnerabilities for our own benefit or stockpiling exposures to further our own siloed testing abilities or line our pockets.

We believe in:

  • Working with organizations to help accelerate their response and remediation efforts
  • Providing detailed information that enables organizations to protect themselves against potential exposures and understand impact

In this instance, the Imperva team was immediately responsive to our findings and quickly resolved the issue – which is always our desired outcome.

Remediating a Zero-Day Vulnerability

In the course of testing a client environment, the Bishop Fox team discovered the Imperva Cloud WAF was vulnerable to a bypass that allowed attackers to evade WAF rules when sending malicious HTTP POST payloads, such as Log4j exploits, SQL injection, command execution, directory traversal, and XXE. This was of particular concern given the recent prevalence of the Log4j vulnerability.

Imperva activated their team as soon as Bishop Fox reported the vulnerability to them, and they turned around a global fix in just a few days. All customers of Cloud WAF were automatically patched as of December 23, 2021.

Tune into Our Webcast as We Unpack the Process

We’ve teed up a webcast to talk about the collaboration between Imperva and Bishop Fox and unpack what we consider an ideal example of the Responsible Disclosure process. We invite you to go behind the scenes with executives from both companies as they discuss this recent real-world example and explore how offensive and defensive security organizations can and should be combining forces.

Register for our webcast on February 2, 2022 at 2 p.m. ET / 11 a.m. PT for insights into:

  • How responsible disclosure and CVE processes work
  • How Imperva and Bishop Fox mobilized teams to accelerate information sharing and remediation efforts
  • How offensive security strengthens defensive security products and why Imperva’s CTO prioritizes it
  • How Log4j has and will change the security landscape in the coming weeks and months

Exploring the Vulnerability

Post Request Bypass

The Imperva WAF was affected by a post request vulnerability. This security vulnerability could lead to attackers evading WAF rules when sending malicious HTTP POST payloads, such as log4j exploits, SQL injection, command execution, directory traversal, XXE, etc.

Vulnerability Details

  • CVE ID: CVE-2021-45468
  • Vulnerability Type: Post Request Bypass
  • Security Risk: Critical

Replicating the Vulnerability

Add the header Content-Encoding: gzip to HTTP POST requests. Leave POST data as-is. Don't encode it. So long as the first four bytes of the Content-Encoding header are gzip, no WAF rules will be applied to POST requests. You can do this in Burp by using the proxy's Match & Replace feature:

Using Burp Suite Professional proxy's match and replace feature example

Add a new header like this:

Example of adding a new header using Burp Suite Match and Replace rule

That's it; you're good to go.

Running the Test Script

Run against a URL that supports POST requests like this: Syntax: ./ [[-t] | [-r]] URL

Guess the WAF type for a given URL:

$ ./ -t
Imperva Incapsula
$ ./ -t
$ ./ -t

Check to see if the WAF is vulnerable to the gzip bypass:

$ ./
[+] Can we make POST requests to
[+] Checking for Imperva WAF...
[+] Attempting gzip bypass for UNIX trigger...
[+] Vulnerable! HTTP response code: 200
[+] Attempting gzip bypass for Windows trigger...
[+] Vulnerable! HTTP response code: 200

If you get this error:

$ ./
[+] Can we make POST requests to
[!] Can't POST to Try -r if 30x redirects are allowed. HTTP response code: 302

then try passing -r on the command line to enable relaxed mode. Relaxed mode is off by default, which means a POST request is expected to elicit an HTTP 200 response from the server. -r expands the acceptable responses to HTTP 2xx, 3xx.


The exit codes for are as follows:
0: Returned after getting WAF type.
1: Command-line was invalid.
2: There was an error connecting. Could be DNS error, timeout, etc.
3: No WAF was detected; malicious UNIX/Windows payloads weren't blocked.
4: A WAF was detected, but it wasn't Imperva.
5: The server responded to a test POST request with something other than HTTP 200.
128: There is an Imperva WAF, but it is not vulnerable to the gzip bypass.
129: The bypass was effective for the UNIX payload, but not the Windows one.
130: The bypass was effective for the Windows payload, but not the UNIX one.
131: The bypass was effective against both Windows and UNIX payloads.

Process to Manually Test for Vulnerability

Send three POST requests:

  1. Establish a baseline POST request/response with a valid but harmless POST request
  2. Trigger the Imperva WAF using the same POST request, but with extra “malicious” data such as Example of malicious code added to trigger the Imperva WAF in the body to verify that Imperva blocks it
  3. Add the header Content-Encoding: gzip to the same malicious request and verify that Imperva doesn't block it

Other Encoding

According to, there are four valid values for the Content-Encoding header: 

  • compress
  • deflate
  • gzip
  • br

In testing, only gzip worked as a bypass.

Subscribe to Bishop Fox's Security Blog

Be first to learn about latest tools, advisories, and findings.

Carl Livitt

About the author, Carl Livitt

Bishop Fox Alumnus

Carl Livitt is a Bishop Fox alumnus. He was a Principal Researcher at Bishop Fox with decades of experience in mobile and application security, hardware and embedded devices, reverse engineering, and global-scale penetration testing.

Carl is credited with the discovery of many vulnerabilities within both commercial and open-source software. He was brought in as a third-party expert to lead the team that confirmed several security issues with St. Jude Medical implantable devices. His work eventually led to an official communication from the FDA.

Carl has served as a contributing author to Hacking Exposed Web Applications 3rd Edition as well as a technical advisor for Network Security Assessment 1st Edition. He has been interviewed on NPR and quoted in publications including USA Today and eWeek. Carl co-authored the iOS reverse engineering framework iSpy, which was featured at Black Hat USA's Tools Arsenal.

More by Carl

This site uses cookies to provide you with a great user experience. By continuing to use our website, you consent to the use of cookies. To find out more about the cookies we use, please see our Privacy Policy.