It's probably worth refining it to `log4j-core`. `log4j-api` or various bridges like `log4j-to-slf4j` are not affected, but will show up in nearly any spring boot app.

Just for reference here's the posting that confirms such:

https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-s...

Also worth noting this is not log4j 1, but log4j 2, like angular vs. angularjs. Version 2 is a backwards-incompatible rewrite with a different package structure, effectively a different product. Version 1 is unaffected by this mess.

Ed: linked as "infoworld article" in TFA.

This article[1] probably seems like a bit of convenient self-promotion from Anchore - but the two tools grype and syft

https://github.com/anchore/grype

https://github.com/anchore/syft

Turned out to be very helpful in easily looking through folders, installed services (in particular an installed mobile device manager running on windows) and container images.

[1] https://www.infoworld.com/article/3644492/how-to-detect-the-...

Submitted to hn as: https://news.ycombinator.com/item?id=29543589 in case there's more discussion of tooling that might fit there.

Also found this link today -

https://support.lucidworks.com/hc/en-us/articles/44156492440...

I'm glad I couldn't get SOLR to work on indexing PDFs for a client project last year and I chose an alternate solution after reading it today...

I mitigated our SOLR install over the weekend. Best I could tell it wasn't logging queries by default so I couldn't get it to trigger. Adding an extra JVM arg to the opt list is a pretty standard SOLR thing to do, so I already have automated ways to update and push out configuration changes.

The Maven enforcer plug-in lets you fail the build if you'd depend on it either directly or indirectly [1]. Note this wouldn't find shaded usages.

[1] https://twitter.com/gunnarmorling/status/1469603432269062146

Could it be you already are on Java 8u121? They say it:

> protects against remote code execution by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".

you better hope one of your dependencies hasn't vendored it!

The key for me is to have a solid backup/disaster recovery plan in place and to first assess what rollback would entail and to verify that backup data is not corrupted. Rollback is more of a final (nuclear) option, but I always need to verify that it is an option...

Data loss from rollback is far better than total corruption (if it ever gets to that point, God forbid).

It also depends greatly on the availability needs for a system of course, but everyone has to be reasonable over things they can't pre-conceive or control in these types of situations because there's no way anything can operate flawlessly and without failure.

1. The Titanic

2. The Hindenburg

3. The AWS-East Service Outage This Month

:\