Security
Post #4054 · source on Telegram
Dev teams react to each new Log4j CVE like hobbits craving seconds
Description
Meme scene from Lord of the Rings featuring two hobbits (faces blurred for privacy) standing outdoors in cloaks. White, all-caps impact font across the top reads, “WE HAVE HAD ONE CVE, YES,” and the bottom caption continues, “BUT WHAT ABOUT A SECOND LOG4J CVE?” The joke riffs on the famous “second breakfast” line, swapping food for security incidents to highlight how multiple Log4j Common Vulnerabilities and Exposures (CVEs) kept arriving in quick succession during the 2021 ‘Log4Shell’ saga. For seasoned engineers, it evokes the fatigue of rapidly patching dependencies, updating SBOMs, and rebuilding containers every time yet another disclosure dropped
More like this
More like this in Security →
Use J and K for navigation
Comments
8Comment deleted
At this pace our CI/CD script is basically: `while curl --silent cve-feed | grep log4j; do patch && redeploy; done`
The real second breakfast was the emergency patches we deployed along the way - followed by elevenses when they found the bypass, luncheon for the incomplete fix, afternoon tea for the scanner false positives, dinner for the vendor notifications, and supper when legal finally approved the disclosure statement
I don't think the CISO knows about second CVE, Pip. Or elevenses: CVE-2021-45105, served fresh every release
When Log4Shell dropped, every CISO thought they'd survived the worst supply chain attack in years after patching CVE-2021-44228. Then CVE-2021-45046 arrived like a sequel nobody asked for, followed by CVE-2021-45105, proving that sometimes the real vulnerability is thinking you're done patching. At least the hobbits got to enjoy their second breakfast - security teams just got second helpings of existential dread and emergency change requests
In enterprise Java, “patching log4j” means CAB approves 2.15.0, you discover 45046, grep every shaded JAR, rerun SCA, and ship 2.17.0 before the first ticket closes
Patch management taught me that upgrading Log4j in the parent POM doesn’t touch the shaded transitive JAR, which is why PagerDuty discovers “second breakfast” before I do
Log4j CVEs: one RCE via JNDI wasn't enough, so the sequel hid in the patch notes
https://www-zdnet-com.cdn.ampproject.org/c/s/www.zdnet.com/google-amp/article/security-firm-blumira-discovers-major-new-log4j-attack-vector/ .. never ending story 2021 Comment deleted