Before any developer sees requirement 1 ("A server with a vulnerable log4j version") and dismisses their product's exposure, I should clarify that the vulnerability is not actually limited to servers. Any use of log4j with attacker-controlled input is potentially dangerous (see, for example, people getting hacked via Minecraft chat messages).

Since logging is a generally good development practice, and it's very common for even release builds of software to ship with a logging capability (and not uncommon for it to be enabled by default), it's prudent to assume that any Java software, until proven to be unaffected, could be using a vulnerable version of log4j to log about anything it's doing--and if one of the things it does is handle untrusted input in any form, then that software could be vulnerable.

For example, say Product X uses Library Y to read (let's say) Microsoft Access databases. Library Y is a Java package which includes a vulnerable version of log4j, and it logs about some of the strings it encounters while reading .mdb files. Now suppose a user of Product X handles .mdb files as part of their usual workflow. One day they try to import into Product X a .mdb file that has a malicious string in it: Product X hands the file to Library Y, which reads the malicious string and passes it to log4j; the string exploits the vulnerability in log4j, and the user gets hacked.

Since Mathematica uses a lot of Java--not all of it written by Wolfram--and also has the potential to handle untrusted data, it seemed like it'd be a good idea to ask if there is or will soon be a patch.

Hi Derek,

Your scenario sounds reasonable, but if you think about the whole play, there would still need to be a point 1 and 2. Just replace "server" with the user's machine running some software, and add deception to item 2. How does the malicious file get into the user's queue? What protocol? SMTP?

Before we go throwing around ad hominems, I tried to be careful saying "more immediate concern". The reason is that active http / tcp analysis can happen right away, while deceptions take time to evolve. Additionally, most analysts should be looking for a big data set on a centralized server, not trying to get a reputation for attacking academic non-targets (these days, who knows).

Ultimately, I think you are right to worry about what's hidden in the closed box. If user data is at risk, of course a fix is high priority. In that case, maybe you should send the PoC to technical support with the CVE number.

Users running powerful software need to be confronted by such issues from time to time, but it probably isn't a good idea to post exploits in computable form here. If you know where to look, there are "journals" for this sort of thing, ha ha.

Hi, no I'm afraid that's a rather old version--if it were the patched version, it would read 2.16.0. One way to check is to unzip the .jar file (JARs are actually ZIP archives, just with ".jar" instead of ".zip" at the end of the name); doing so shows files dated 2010.

Note that the vulnerable log4j code could be nested into other .jar files, i.e., files named *log4j*.jar visible at the file system level may not be the only vulnerable instances of the log4j code on the system.

[Clarification: The previous post apparently refers to the log4j used by Mathematica's RLink.]