[clackers]

On-line banking etc is a different and more serious matter, but I guess banks will deal with this as a prority, even if many hobby and interest websites don't - some of which don't get attended to by their admins for years

You will be surprised by how variable the proficiency of bank IT staff - lots of outsourcing and subcontracting involved - and the infrastructure they have are. I've heard lots of war stories.

One thing financial institutions are good at is remaining silent about how often they have been compromised or ripped off during a year.

[BigMackCam]

One thing financial institutions are good at is remaining silent about how often they have been compromised or ripped off during a year.

Next thing is, they'll be releasing update notes for their software with phrases like "Improved stability for general performance"...

[beholder3]

I've already added LOG4J_FORMAT_MSG_NO_LOOKUPS = true to my environment variables, updated my Java SDK and runtime, and I'm running the latest version of Arduino IDE (although it's still using v2.12 of log4j ). I'm not sure there's much else I can do at this point... nor, indeed, if the few online services I connect to put me at any real risk...

Just fyi, the apache guys write this:

Other insufficient mitigation measures are: setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the logging configuration to disable message lookups with %m{nolookups}, %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.
The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above, there are still code paths in Log4j where message lookups could occur: known examples are applications that use Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not implement StringBuilderFormattable. There may be other attack vectors.
The safest thing to do is to upgrade Log4j to a safe version, or remove the JndiLookup class from the log4j-core jar.

[BigMackCam]

Just fyi, the apache guys write this:

Yes, I saw that. The updated information came after my post in this thread.

Seems like the only way to fully mitigate the issue is upgrading the libraries to 2.15... but then, that's still just local protection. None of us can address the server side issues... Only the sysops can do that