Sometimes. A web application firewall can justify lowering urgency only when you can show it blocks the specific attack path for that specific flaw, that it is in blocking mode, and that traffic cannot go around it. Without that evidence, treat it as helpful, not as a reason to wait.
Define the term
A compensating control is a safeguard that reduces the risk of a vulnerability when you cannot fix it right away. It does not remove the flaw. It makes exploitation harder or limits the damage.
CVSS v4.0 acknowledges this in its Environmental group: it covers the presence of security controls which may mitigate some or all consequences of a successful attack. The key words are may mitigate. The score only changes if you assert the mitigation, so you need to be able to support it.
Four questions to ask about a WAF
| Question | Why it matters |
|---|---|
| Is it in blocking mode, or only logging? | A detection only WAF stops nothing |
| Does a rule match this exploit pattern? | Generic rules often miss specific payloads |
| Can traffic reach the origin directly? | A public origin address bypasses the WAF |
| Is the flaw reachable over HTTP at all? | Flaws in background jobs or message handlers are not web traffic |
If any answer is no or unknown, do not lower the priority.
How to test it
- Find a public proof of concept request or construct a safe test payload for the flaw, in a test environment you own.
- Send it through the WAF and directly to the origin.
- Record both results with timestamps.
- If the WAF blocks and the origin is unreachable from outside, note the rule that fired.
- Repeat after any rule update, because rules change.
Keep the evidence with the finding. An exception that says "WAF protects this" with no proof will not survive a review.
What a WAF rule is and is not
Rules are written against known patterns. Attackers vary payloads, encodings and request paths. A rule that blocks one exploit string may let a variation through. Treat the WAF as a speed bump that buys time for the fix, not as the fix.
This matters most for flaws on the CISA Known Exploited Vulnerabilities Catalog, where exploitation has already been observed. The catalog lists a due date for each entry. A compensating control may help you through the window, but plan the real fix.
Setting an expiry
Every compensating control based exception should carry:
- An owner who accepts the residual risk
- The evidence of the test
- An expiry date, short enough that someone must look again
- The fix plan and the date it should land
When the date arrives, either the fix has shipped or the exception is renewed with new evidence. It should never renew silently.
When to ignore the WAF entirely
- Authentication bypass flaws where the request looks legitimate
- Flaws in logic that depends on valid business requests
- Vulnerable code that processes data from sources other than the web, such as uploaded files or queue messages
In those cases the WAF cannot see the attack as an attack, and the original priority should stand.
Quick check
Can I lower severity in the scanner because of a WAF?
Only through a recorded exception with evidence and an expiry. Do not edit the base severity.
Is a WAF in detection mode a compensating control?
No. It records attacks but does not stop them.
Sources
Last reviewed: 19 October 2026.
