Web Application Security

Testing CVE Mitigation in Web Apps

Phillip Maddux

Your friendly neighborhood AppSec advisor and honeypot enthusiast. Formerly @ Goldman Sachs and Ernst & Young. Find his thoughts in code form committed to Github.



With Internet-exposed web applications, prompt mitigation of CVE (Common Vulnerabilities and Exposures) is critical. When a new CVE has been announced the response drill is all too familiar to InfoSec teams. Here’s how the overall response usually breaks down:

  1. The team evaluates the details of the CVE to determine if any of their applications are impacted. In many cases, it’s a scramble to try and discover if the vulnerable framework or code is even being used in their environment.
  2. Then they search Google to find any proof of concept (PoC) exploit code that may have been published.
  3. Finally, when vulnerable web applications have been identified, they initiate the patching process as soon as a patch is available.

Patching a CVE as quickly as possible is critical as published PoC exploit code is typically weaponized within malicious automation that is continuously scanning the Internet for vulnerable victims.

A Simple Tool for Testing CVE Mitigation Controls

Getting to the point of this post, I want to share a tool that aims to help with validating CVE mitigation controls (WAF rules or other server filters) you’ve implemented. The tool contains various PoC payloads (collected from various PoC exploit code on Github and other sources) to test that your mitigating control is properly detecting and blocking the attacks. The tool is not attempting to exploit the vulnerability for verification, but rather it is simulating the attack based on exploit code and expecting the mitigating control to return a specific status code. The status code is the indicator that determines the attack was detected and blocked. For example, some WAFs will return a 403 status code to indicate a block has been enforced. In addition, ease of use helps make testing repeatable for regression testing.

This simple tool is a Python script and does not have a fancy name, it’s just humbly called web-cve-tests. You can find it on Github here:

It currently contains tests for 26 CVEs (the full CVE list is available here), but I’ll continue to update it as often as I can, and as new CVEs impacting web applications are announced. As an open source project, contributions are always welcome. Especially, if the broader community finds this tool useful and would like to see it evolve. If you are in AppSec and are handy with the Python — hint hint ;-)

By just passing the target URL, web-cve-tests will launch all CVE tests. You can also specify a single CVE to test or a group of CVEs. For example, if you only want to test all Struts CVEs you’d pass the command line option --group struts.

Below is an example of execution and output. In this example, a status code of 406 is expected to confirm detection, a single CVE is specified for the test (CVE-2017–9791), and output is set to verbose. Each test has a variant attack payload for the one CVE. 

./webcve.py --url https://target-site.com --status-code 406 \

--cve CVE-2017-9791 -v


The Struts 1 plugin in Apache Struts 2.3.x might allow remote code execution via a malicious field value passed in a raw message to the ActionMessage.

Test passed (406)

Test passed (406)

Test passed (406)

Test passed (406)

A Quick and Repeatable Process for Regression Testing

When patching a CVE is not possible or delayed, implementing a mitigating control is critical to mitigating the risk of being exposed. Vulnerability scanners can help with indicating the presence of the vulnerability, but they will not necessarily verify that mitigating controls are detecting attacks. PoC exploit code can be effective at verifying if the mitigating control is working as expected, but if you need to test for numerous CVEs collecting and managing the various PoC scripts can be burdensome — although Metasploit can help reduce the burden. The web-cve-tests tool aims to provide a simple way to test CVE mitigation by leveraging PoC exploit code from various sources. This tool can be leveraged for quick testing and validation and also made part of a repeatable process for regression testing.