Notifications
Clear all
Topic starter
02/08/2026 9:43 am
TL;DR: Log4Shell turned a logging library into a remote code execution path across widely used Java frameworks, with attackers able to trigger code via LDAP-delivered payloads, according to StackHawk. The incident shows why dependency visibility, runtime testing, and rapid patching must sit beside traditional vulnerability management.
NHIMG editorial — based on content published by StackHawk: Log4Shell issue overview and response to the Log4j remote code execution vulnerability
By the numbers:
- CVE-2021-44228 was categorized as Critical with a CVSS score of 10.
- All current versions of log4j2 up to 2.14.1 are vulnerable.
- Only 5.7% of organisations have full visibility into their service accounts.
Questions worth separating out
Q: What breaks when a logging flaw becomes remote code execution in production apps?
A: The main break is the boundary between application input and trusted execution.
Q: Why do Java application vulnerabilities often become credential problems?
A: Java application flaws often sit close to configuration, dependency management, and runtime secrets, so a successful exploit reaches more than code.
Q: How do security teams know if Log4j-style exposure is still dangerous after patching?
A: Patch status is not enough.
Practitioner guidance
- Inventory transitive Java dependencies Build a complete list of where Log4j and similar libraries enter production images, application bundles, and CI/CD artefacts.
- Remove secrets from reachable runtime paths Move service account credentials, API keys, and certificates out of environment variables and local config where possible, and isolate workloads so an RCE cannot easily enumerate them.
- Test exploitability in running applications Use runtime testing to confirm whether a vulnerable component is actually triggerable in production, not merely present in a software bill of materials.
What's in the full article
StackHawk's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for updating vulnerable Log4j2 versions in affected Java applications.
- StackHawk's explanation of how HawkScan and ZAP were updated to address Log4Shell detection.
- Practical examples of OAST-based testing to verify whether a deployed app is actually exploitable.
- Details on when to use software composition analysis versus runtime testing in remediation workflows.
👉 Read StackHawk's response to the Log4j remote code execution vulnerability →
Log4Shell and Java runtime RCE: what security teams missed?
Explore further
02/08/2026 12:36 pm
Log4Shell showed that runtime code execution is an identity event once secrets live in the workload. The vulnerability started as an application flaw, but its practical risk expanded because compromised runtimes often contain service account tokens, API keys, and other secrets. That makes application security and NHI governance interdependent, not separate disciplines. Practitioners should treat exposed runtime secrets as part of the blast radius, not a secondary concern.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should teams do after discovering a remotely exploitable library in a live workload?
A: Contain the workload first by limiting network reach, then rotate any credentials the process could access, and finally rebuild from trusted artefacts with the vulnerable dependency removed. If the workload has touched secrets, treat the incident as both a vulnerability response and a credential hygiene event.
👉 Read our full editorial: Log4Shell exposed runtime code execution gaps in Java application security
