Are you ever logging strings that come from outside your software, be it things users type in, HTTP headers, ...? Then you don't control if you are "using any of the jni special Uris".
But the underlying bug is because log4j uses the equivalent of printf(userData).
I think this vulnerability should be used as a lesson against the vagaries of the classic Java API design issues that we're now finally starting to turn away from. Having an extensible formatting mechanism is not necessary a bad idea, but the problem with this and so many other "magic" features provided by Java libraries is that they are:
* Opt out, instead of opt-in * Hard to discover - if you don't read the ENTIRE log4j documentation (which is pretty large!), it's hard know that this stuff is happening. * Too inclusive - adding JNDI was a bad idea, but even allowing things like environment variables or JMX Beans to be looked-up wholesale from a non-sanitized message is a bad idea.
The problem is much deeper than log4j really. In hindsight, features like JNDI, RMI, and most of all Java Serialization should have never been part of Java in the first place.
[1] LOG4J2-2109: https://issues.apache.org/jira/browse/LOG4J2-2109
[2] LOG4J2-905: https://issues.apache.org/jira/browse/LOG4J2-905