At least in the Maven world, you don’t need to wait for your dependencies to update their versions of log4j2 (or anything else)—you can add your own dependency on the latest log4j2, and it will always win because it’s earlier in the dependency tree than any of those transitively-depended-on older versions. (Of course this will only work if the new version of log4j2 doesn’t break those packages, but such breakage is quite unlikely given the Java ecosystem’s conservative approach to backward compatibility).
The OG Maven approach to dependency versioning was chosen because it makes builds deterministic, depending only on what’s explicitly mentioned in the POM (and transitively in explicitly depended-on POMs, of course). This does have disadvantages, but one of its corollaries is that if you explicitly mention ask for log4j 2.17.1 in your root POM, you will always get it.
It would be a shame if people were waiting for random dependencies to update instead of just fixing this themselves. (To be clear, I don’t think adding a dependency just to force it on your other dependencies is a good long-term solution, but it’s clearly better than the alternative here.)
This article tries to use open source metrics to measure the impact of log4j. But, since Java is used heavily by enterprises, it shouldn’t be shocking that most enterprises do not pull directly from Maven Central but either mirror it or have their own internal repo. Hence this article severely underestimates the impact in my opinion.
Some organizations also quickly realized it was going to be easy patching most hosts but perhaps impossible to patch all of them fast enough and release https://aws.amazon.com/blogs/opensource/hotpatch-for-apache-log4j/.
There are many down sides to Java, but this is one ugly and surprising up side. The JVM agent is a no-holds-barred way of not just monitoring but also modifying runtime behavior. I think this approach is horrific but fascinating, like a car crash.
This isn’t really Java’s fault. Many environments have similarly awful footgun APIs.
Many older serialisation schemes had a tendency to give RCE, posix systems have system(), and windows has an equivalent, that is even easier to trip on.
JNDI is just a particularly exciting case because by design it will happily download and execute remote content, but the above (and other) APIs have been abused in very similar ways in the past
This is an example of the way that a given languages larger ecosystem can impact you and why any analysis of a given languages suitability for a project should include discussion of the ecosystem. There are many things about java’s semantics and runtime that are quite good. However the Java ecosystem has devolved in some unfortunate ways. This doesn’t mean that java isn’t a good choice. But it does mean you should be aware of the ecosystem impact and be prepared to mitigate those impacts when you use it.