Log4Shell Finding Versus a WAF Waiver
A Java Spring Boot payment API runs in production on 60 containers. A runtime vulnerability scan flags CVE-2021-44228 (Log4Shell) in a bundled logging library, CVSS 10.0. The same image also has a separate high-severity CVE in a test utility that is not loaded at runtime. The security team sees 3 exploit attempts against the Log4j endpoint in the last 24 hours, all returned 403 by a WAF, and no outbound LDAP traffic from the pods. The platform team says a base-image rebuild takes 5 days because of a shared library dependency; a hot patch can disable JNDI lookup via a JVM flag in 1 hour. The application owner wants to waive the finding because the WAF blocks it. The API is internet-facing and processes cardholder data; the WAF is in blocking mode but has a known JSON parser bypass for encoded payloads.
1. Rank the two vulnerability findings and justify the ranking with runtime evidence.
Read the worked answer
Rank the Log4Shell finding first, then the test-utility CVE. Ranking should not rest on CVSS alone.
For Log4Shell: the library is loaded at runtime in an internet-facing payment API, the component is reachable through request processing, exploit attempts have already been observed, and the asset handles cardholder data. Those factors raise likelihood and impact. The fact that the WAF returned 403 on three attempts is evidence of attempted exploitation, not proof of safety.
For the test-utility CVE: the library is reportedly not loaded at runtime. That lowers exposure substantially, but verify it with runtime evidence: process and library inventory, class-loading telemetry, and whether any test endpoint or packaging mistake makes it reachable. If it is truly dormant, it can follow the normal patch cycle rather than the emergency path.
The key judgement is that runtime reachability, internet exposure, data sensitivity, and active attempts outweigh a headline severity score. A CVSS 10 in a dormant test dependency is not equivalent to a CVSS 10 in a reachable request path.
2. Should the application owner's waiver be approved? Recommend an interim control plan.
Read the worked answer
Do not approve an open-ended waiver based only on WAF blocking. The WAF is a compensating control, but the stated JSON parser bypass for encoded payloads means it cannot be treated as a guarantee. The absence of observed outbound LDAP traffic is also weak evidence: exploitation can use other channels, DNS, or delayed callbacks, and a short observation window may miss it.
A time-bound risk acceptance is defensible only with layered controls:
- Apply the JVM flag to disable JNDI lookup within one hour and verify it in a staging canary.
- Block outbound LDAP, RMI, and unusual DNS from the payment pods at egress.
- Increase monitoring for exploitation indicators and review WAF bypass patterns.
- Complete the base-image rebuild and patch within the five-day dependency window.
- Record a named risk owner, expiration date, and rollback conditions.
This is not a waiver of the vulnerability; it is a controlled, temporary risk reduction while the proper fix is completed.
3. What detection content would you add to confirm and respond to exploitation attempts?
Read the worked answer
Add detections at three layers and correlate them:
- Application and WAF: JNDI strings and encoded variants in request parameters and headers, WAF rule hits followed by unexpected 200 responses, and parser-bypass patterns. Alert when a blocked attempt is followed by a successful request to the same endpoint from the same source.
- Process behavior: Java spawning shell, curl, wget, or reconnaissance commands; unexpected child processes from payment containers; writes to temporary directories.
- Network: outbound LDAP, RMI, DNS, or HTTP to newly seen or low-reputation destinations from payment pods; unusual egress volume or beaconing.
The response runbook should isolate the pod from the network, preserve the container image and memory if possible, capture the request and trace IDs, rotate credentials reachable from the pod, and check for lateral movement. A single blocked WAF event is not an incident, but a blocked attempt followed by anomalous egress or process behavior is.