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.
