Ramblings of an aging IT geek
← Ramblings of an aging IT geek
news

the one everyone's calling "the next log4shell"

A few calm thoughts on the Apache Commons Text vulnerability doing the rounds this week, and why "the next Log4Shell" framing rarely helps.

A tech news headline on a screen

If you spent any of last week on security Twitter, you will have seen the Apache Commons Text bug doing the rounds, CVE-2022-42889, promptly nicknamed "Text4Shell" and breathlessly billed as the next Log4Shell. The interpolation feature could evaluate strings like ${script:...} and run code, which is exactly the kind of thing that makes everyone reach for the panic button.

The panic was, mercifully, overdone. Unlike Log4Shell the vulnerable code path is not something most applications exercise by default, and the affected versions are narrower than the headlines suggested. The Apache folks shipped a fix and the advice was the usual: work out whether you actually use the dangerous bit, then upgrade regardless.

My honest reaction was tiredness more than alarm. Every "the next Log4Shell" comparison trains people to either over-react to everything or, worse, tune the noise out entirely. Both are bad. The useful work this week was not arguing about severity scores; it was running a dependency scan and finding out, concretely, whether the library was even on the path.

So that is what I did across the homelab and the work estate. A mvn dependency:tree here, a quick SBOM check there, and the answer was mostly "no, and where yes, behind a bump". Undramatic, which is rather the point. The genuinely valuable lesson from Log4Shell was never the specific bug, it was that you should already know what is in your software. If a disclosure like this sends you scrambling to find out, the disclosure is not really the problem.