Sigh. After years of SQL Injection, one would think ability to log active content would have been suppressed years ago.

It appears that this was intented feature that had really bad default. For me personally, using any formatting codes in the log data sounds like a really bad idea but Log4j seems to have all formatting enabled by default and you have to opt-in for no-automatic-prosessing behavior. And the automatic prosessing option also included using remote formatters for extra flexibility, which is the actual vulnerability used here. in short, no real world developer expected this library to default to full automatic processing with remote host support.

"It impacts Apache Log4j versions 2.0-beta9 to 2.14.1.". Is it also impacts the versions 1.x? or just the versions 2.x?

Version 1.x doesn't have the features exploited here but all 1.x versions are already vulnerable to other attacks and 1.x series has been EOL for quite some time already so it will not see any fixes for any vulnerability (already known or future).

Version 1.x has been vulnerable to another RCE attack since 2019: https://nvd.nist.gov/vuln/d...

I'm pretty sure versions 1.x are vulnerable to lots of attacks, but not this one it seems.

Only if the targeted host is able to make the outbound ldap connection though…

You can be pretty sure that if the targeted host used Log4j with default settings, it will also allow outbound ldap, too. Had formatMsgNoLookups=true been the default, this whole mess would have never occurred.

Fair point, but I'm afraid that many of them will have no restrictions in place.