Log4Shell was exploitable via a commit introduced from merging a user-provided patch. It went through the entire review process. Had something like CodeQL existed back when that was merged, maybe it would have helped detect the issue, but that would have also required it to not put Log4j is an ignore list of code to skip over. Given the lack of public knowledge of the exploitability of JNDI at the time (July 2013), it would have required an oracle to foresee the vulnerability it introduced. In fact, JNDI exploitability wasn’t publicly known until around 2016 when it was presented in a Blackhat talk about a class of vulnerability discovered from Operation Pawn Storm (likely discovered and weaponized by a Russian government organization based on its targets). Interestingly enough, Log4shell was based on an exploit that initially targeted Java itself in a zero-day. The CVEs published for Java that _might_ correspond to that zero-day are frustratingly vague about what was fixed (see for example [1] and [2]).
Suffice to say, Log4shell was the result of systemic problems in software, and use of RTC or any sort of human review of code history had nothing to do with the situation. While I might agree that code review and static analysis tools and such are useful things, I would strongly disagree that they would have helped prevent Log4shell. If you’re interested, I have a more detailed writeup about the whole incident. [3] [1]: https://nvd.nist.gov/vuln/detail/cve-2015-2590 [2]: https://nvd.nist.gov/vuln/detail/cve-2015-4732 [3]: https://musigma.blog/2023/11/10/log4shell-history.html > On Oct 29, 2025, at 10:40 AM, Elliotte Rusty Harold <[email protected]> > wrote: > > On Wed, Oct 29, 2025 at 11:56 AM Gary Gregory <[email protected]> wrote: > >>>> the vine IMO due to all of of the hoops and requests it makes on >>>> contributions. >>> >>> Log4Shell > > I have. I was directly involved in the response to that clusterfuck at > probably the largest Java shop on the planet. And having been through > that, and multiple other emergency security response efforts caused by > holes in open source software deep in the stack, I am astonished that > people still think it's OK to build and build on top of projects where > all that's needed to compromise the global infrastructure is to buy or > steal the GitHub account of one unpaid hobbyist. > > No, this is not the only way systems are compromised, but it > absolutely is one way, and one that's easy to protect against. Not > doing that is profesional misfeasance. > > -- > Elliotte Rusty Harold > [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
