A compromised web application firewall exposes the decrypted traffic of your most public applications, the TLS private keys that prove their identity and the secrets that let requests through to the origin, while quietly switching off the protection you think is in place. WAFs have been compromised in all the ways that matter for response: an appliance flaw (CISA's Known Exploited Vulnerabilities catalog lists several WAF appliance vulnerabilities, including CVE-2025-64446, which the vendor says allowed unauthenticated attackers to run administrative commands), a provider-side breach that exposed customers' keys and certificates, and a WAF host whose cloud role was used to reach data. The hard part is that you usually cannot just switch the WAF off, because the applications behind it then lose protection. This guide is for application security, platform and network teams and incident responders. It is vendor-neutral: confirm exact settings in your vendor's documentation. Preventive hardening is in Securing the web application firewall (WAF) itself, and this page does not repeat it.
Key takeaways
- Protect the applications while you contain the WAF. Move traffic to a standby or cloud-native WAF, or restrict access to the application, rather than leaving it exposed.
- Assume TLS keys and decrypted traffic were exposed. Reissue certificates with new keys, revoke the old ones and plan for user sessions and credentials that passed through the WAF.
- Rotate origin trust. Shared headers, client certificates and allow-listed WAF addresses that let requests reach the origin must change, or the attacker can go straight past the WAF.
- Restore policy from version control, not from the running WAF. Exclusions, mode changes and disabled rules made in the window are the attacker's bypass.
- Cut the WAF's own cloud and pipeline identities. A WAF host's role or a policy deployment key can be worth more to an attacker than the WAF itself.
What an attacker gains, by deployment model
This is our view of the exposure in the common models. Your WAF may combine several.
| Model | What a compromise exposes | Containment lever |
|---|---|---|
| Appliance or virtual appliance | Operating system and admin access, TLS private keys, decrypted traffic, origin credentials, local logs | Fail over to a standby, isolate, replace |
| Self-hosted reverse proxy or module (for example a rule engine running the OWASP Core Rule Set) | The host, its keys and its cloud role or service account | Rebuild the host from a clean image, rotate host identity |
| Cloud or CDN WAF service | Your tenant's policies, certificates uploaded to the provider, API tokens, origin secrets; on a provider breach, possibly the same for many customers | Lock the tenant, rotate certificates and tokens, follow provider instructions |
| Cloud provider native WAF | Web ACLs and rules managed through cloud IAM | Contain the cloud identities that can change the web ACLs |
How the compromise shows up
- Exploitation of the management plane: a vendor advisory or KEV entry for your WAF version, or unexpected administrator accounts. The vendor advisory for CVE-2025-64446 recommends reviewing configuration and logs for unexpected modifications and for the addition of unauthorised administrator accounts (ATT&CK T1190 Exploit Public-Facing Application).
- Protection quietly reduced: applications moved from blocking to detection only, broad exclusions added, rules or whole rule groups removed, or new allow-listed IP ranges (ATT&CK T1685 Disable or Modify Tools).
- Traffic diversion: changed origin addresses, new routes or redirect rules, or DNS records for protected sites changed outside change control.
- Key or certificate events: certificates exported or uploaded unexpectedly, or certificate transparency logs showing certificates for your names that you did not request.
- Use of the WAF's identities: its cloud role or service account used from outside the WAF host, which is what happened when credentials were taken from a WAF host through the instance metadata service (ATT&CK T1552.005 Cloud Instance Metadata API).
- Origin access not via the WAF: origin logs show requests that carry the origin secret but come from addresses that are not WAF egress addresses.
Triage: the first hour
- Establish what was compromised: the management plane, the data plane host, your tenant of a WAF service, the provider, or an identity that manages the WAF.
- List protected applications and rank them by data and exposure; containment order follows this list.
- Inventory secrets held: TLS certificates and keys, origin secrets and client certificates, API tokens, policy pipeline credentials, the host's cloud role and log shipping credentials.
- Check current protection: export the running policy and compare it with the version in source control to see what is disabled now.
- Decide the safe traffic path for each critical application before touching the WAF.
Containment by priority
- Move critical applications to a safe path. Fail over to a standby WAF or a cloud-native WAF with the reviewed policy, or temporarily restrict access (for example to known networks or behind an authenticating proxy) for applications where that is acceptable. Do not simply bypass the WAF for internet-facing applications.
- Isolate the compromised WAF. For appliances, remove management interfaces from any internet exposure; the vendor's interim advice for CVE-2025-64446 was to disable HTTP or HTTPS on internet-facing interfaces until upgraded. Then isolate the device except for evidence collection.
- Cut its identities. Deny or revoke the WAF host's cloud role sessions, disable its service accounts and revoke API tokens and policy deployment keys. On AWS hosts, requiring IMDSv2 (
HttpTokensset torequired) or turning the metadata endpoint off for the replacement host closes the metadata path; see the EC2 Instance Metadata Service Hardening Guide. - Lock origin access to the new path. Change the origin secret or client certificate and update origin firewall rules so only the new WAF path is accepted.
- Freeze and export policy and logs before any further changes.
Rollback: keep the previous traffic path documented so you can return an application to it if the new path breaks functionality, provided that path no longer runs through the compromised component.
Keys, certificates and secrets to rotate
| Item | Action | Why |
|---|---|---|
| TLS certificates and private keys for protected sites | Generate new keys, issue new certificates, ask the CA to revoke the old ones citing key compromise | A stolen key allows impersonation of your sites and, without forward secrecy, decryption of recorded traffic |
| Origin shared secrets and client certificates | Replace and update origin validation | Old values let an attacker reach the origin without passing the WAF |
| WAF admin accounts and SSO trust | Remove unknown admins, reset all others, re-establish SSO | Persistence in the management plane |
| API tokens and policy pipeline keys | Revoke and reissue with narrow scope | Used to push weakened policy later |
| Host cloud role or service account | Revoke sessions, replace credentials, reduce permissions | The route from WAF host to data |
| Application secrets seen in traffic | Invalidate sessions, rotate API keys and tokens that pass through the WAF, consider password resets | Decrypted traffic contains cookies, bearer tokens and credentials |
| Log shipping and SIEM credentials | Rotate | Can be used to tamper with or flood logs |
For mass certificate replacement see the CA Compromise and Mass Certificate Replacement Playbook. Application API keys and tokens that crossed the WAF are non-human credentials: rotate them with the same urgency as the WAF's own, using the Cloud Credential Compromise Playbook where they are cloud keys.
Eradication and rebuild
- Replace compromised appliances or hosts from a clean image on a fixed release; do not restore a configuration backup taken during the window.
- Rebuild policy from source control. Re-apply the last reviewed policy, then review every exclusion. The OWASP Core Rule Set documentation favours narrow exclusions of a single variable over removing whole rules or tags, and warns that adding a content type without the matching body parser can result in a complete WAF bypass; check for exactly these changes.
- Check mode per application: confirm blocking mode where it was approved, and that no application was quietly left in detection only.
- Review routes and DNS: remove unknown origins, redirects, custom edge code and DNS changes.
- Hunt behind the WAF: review application and origin logs for the window for attacks that the weakened policy let through, and for direct origin access.
Recovery and return to service
- Stand up the rebuilt WAF in detection mode on mirrored or low-risk traffic to confirm the policy behaves as expected.
- Move one low-risk application to it in blocking mode and watch false positives and latency for a full business cycle.
- Move remaining applications in rings, highest risk last only if the interim path is stable; otherwise highest risk first to end the interim exposure.
- Decommission the interim path and its temporary secrets.
- Verify: run your WAF regression tests and confirm logs reach the SIEM with the expected fields.
Evidence and notification
- Preserve: the appliance image or host disk, WAF admin audit logs, traffic and security event logs, policy exports, origin logs and cloud audit logs for the WAF's identities.
- Personal data: decrypted traffic usually contains personal data and credentials; under GDPR Article 33 the controller notifies the supervisory authority within 72 hours of becoming aware where feasible, unless the breach is unlikely to result in a risk to individuals. See the Data Breach Notification Checklist.
- Other regimes: see the Cyber Incident Reporting Requirements Map.
- Customers of your applications: if credentials or tokens may have been exposed, decide whether to force resets and tell users.
Decision guidance
| Situation | Choose | Trade-off |
|---|---|---|
| Appliance management plane exploited | Fail over, replace, rotate all keys | Cost and time of replacement against residual implant risk |
| Tenant admin account misused, provider unaffected | Reset access, restore policy from source, rotate tokens; certificates if exportable by admins | Faster, depends on a complete audit log |
| Provider-side breach | Rotate every certificate, token and origin secret given to the provider | Large certificate workload; automation pays off here |
| No standby WAF available | Restrict access to critical applications, enable cloud-native WAF where possible | Possible loss of availability for some users |
| Small organisation with one WAF | Use the provider's native WAF or a managed service as the interim path | Policy differences; test critical flows |
Detection and measurement
- Policy drift: differences between running policy and source control, checked daily; target zero unexplained.
- Mode coverage: share of approved applications in blocking mode.
- Time to safe path: minutes from declaration to critical applications behind a trusted WAF or restricted.
- Certificate rotation time: hours to reissue and deploy all certificates held by the WAF.
- Direct origin hits: requests reaching origins from outside WAF egress addresses.
- Management exposure: WAF management interfaces reachable from the internet; target zero.
Framework mapping
| Framework | Reference | Where it applies |
|---|---|---|
| NIST CSF 2.0 | RS.MA-01, RS.AN-03, RS.MI-01, RS.MI-02, RC.RP-03, RC.RP-05 | Response, analysis, containment, eradication, restore from verified policy |
| NIST SP 800-53 Rev. 5 | IR-4, IR-6, SC-12, SC-17, IA-5, CM-3, SI-4 | Incident handling, keys and certificates, authenticators, change control, monitoring |
| CIS Controls v8.1 | Control 4, Control 13, Control 16, Control 17 | Secure configuration, network monitoring and defence, application software security, incident response |
| ISO/IEC 27001:2022 Annex A | 5.24 to 5.28, 8.9, 8.24 | Incident management and evidence, configuration management, cryptography |
| MITRE ATT&CK | T1190, T1685, T1557, T1552.005, T1078.004 | Exploitation, defence impairment, traffic interception, metadata credentials, cloud accounts |
Common failure patterns
- Not rotating what you gave the provider. In the Imperva breach, a stolen cloud API key exposed cloud WAF customers' API keys and the TLS certificates they had uploaded, so both had to be treated as exposed.
- Overlooking the WAF host's role. In the Capital One breach, credentials for a firewall host's over-broad cloud role were obtained and used to reach data.
- Bypassing the WAF to restore service. Removing protection during containment exposes the applications to exactly the attacks the WAF was blocking.
- Keeping the old origin secret. The attacker then reaches the origin directly, and the rebuilt WAF sees nothing.
- Restoring the running configuration. A backup from the window brings back the attacker's exclusions and admin accounts.
Practitioner checklist
- Keep WAF policy in source control and alert on drift.
- Maintain a tested interim path for every critical application.
- Inventory every certificate, origin secret, token and role the WAF holds.
- On compromise, move critical applications first, then isolate the WAF.
- Revoke the WAF's cloud role sessions and pipeline credentials.
- Reissue certificates with new keys and revoke the old ones.
- Replace origin secrets and restrict origins to the new path.
- Invalidate application sessions and tokens that crossed the WAF.
- Rebuild from a clean image and the last reviewed policy.
- Hunt behind the WAF for attacks let through during the window.
Standards and references
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- CISA: Known Exploited Vulnerabilities Catalog
- OWASP Core Rule Set: False positives and tuning
- NCSC: Secure system administration
- Fortinet: PSIRT advisory FG-IR-25-910 (CVE-2025-64446)
- AWS: Modify instance metadata options for existing instances
- MITRE ATT&CK: Adversary-in-the-Middle
Related NHI Mgmt Group resources: Web Application Firewall Guide · Securing the web application firewall (WAF) itself · Edge Device Compromise Investigation Playbook · Web application firewall (WAF) integration security guide