Log4j has been ported to other languages, such as log4perl, log4php, log4net, and log4r. Are these ports vulnerable to CVE-2021-44228 as well? I believe that they aren't because the vulnerability uses JNDI (Java Naming and Directory Interface), which I doubt would be relevant in other languages.


3 Answers 3


That CVE does not impact the ports, only Log4j, since it requires the use of Java interfaces (and some JVM versions prevent the vulnerability from being exploited). It may be that the ports have similar vulnerabilities, but they would likely be of a substantially different nature such that we would issue a different CVE for them to help distinguish the vulnerabilities, patching, and remediation steps.

  • 12
    are you able to cite any references to help support your answer? This is an important question, and it would be great to have some references to help. Thanks! Commented Dec 11, 2021 at 21:48
  • 43
    The CVE entry clearly states that it uses JNDI. Since Perl, PHP, .NET, and R don't use the JVM, they can't possibly support the requisite interface. The CVE entry also states no other vulnerable software.
    – bk2204
    Commented Dec 12, 2021 at 1:23
  • 4
    @GaryEwanPark The exploit is that arbitrary Java byte code can be run using JNDI on the JVM. If you don't have a JVM there is nothin to run on. Commented Dec 14, 2021 at 15:08

Let me start with some background info. As I understand it, the CVE-2021-44228 ("Log4Shell") vulnerability has three main components:

  1. A design flaw in Log4j that makes it (by default, before version 2.15.0) parse and expand certain substrings delimited by ${ and }, known as lookups, not only in hardcoded formatting patterns but actually in all logged data, including any user inputs provided as parameters. This is the part that the recommended mitigation techniques (upgrade to 2.15.0+ or set log4j2.formatMsgNoLookups to true in version 2.10.0+) address.

  2. A particular lookup named jndi, enabled by default, that allows using the JNDI (Java Naming and Directory Interface™) API to load data from arbitrary remote sources using protocols such as LDAP. Some of the alternative mitigation techniques for older pre-2.10.0 Log4j versions, like this Java agent hotfix, work by disabling this lookup.

  3. Bugs and/or design flaws in the Java LDAP implementation that make it vulnerable to remote code execution if given suitable input data. There are known ways to mitigate these, but apparently the attack surface is broad and hard to eliminate completely.

The possibility of using JNDI + LDAP for remote code execution has actually been known for some time; the last link above is to a presentation from 2016 discussing it. Issues with the inappropriate application of lookups to all logged data in Log4j have also been known at least since 2017, when the option to turn it off was added in version 2.10.0. But apparently it wasn't considered a major security problem at the time (although IMO it should've been), since without the jndi lookup's ability to make external requests all(!) it allows is a limited form of log forgery.

It was really the combination of all three of these flaws that allowed elevating this easy-to-use but limited log forgery exploit (part 1) into an easy-to-use remote code execution exploit (parts 2 and 3).

(Also, once the RCE exploit became widely known, people figured out that parts 1 and 2 could also be used to leak sensitive data, like private keys stored in environment variables, in the remote requests without actually needing the RCE exploit from part 3. But AFAIK this was only discovered, or at least publicized, in the past few days after the RCE was already known.)

Anyway, the upshot of all this is that log4j ports to other languages may have the same design flaw (part 1 above) allowing lookups to be parsed in user input. However, JNDI (part 2) is specific to Java, so the full RCE exploit in its current form is unlikely to work on log4j ports to non-Java systems.

Of course, I would still consider parsing any string substitutions in untrusted log data to be a security flaw and at least a potential entry point for exploit. Given a potentially vulnerable system, you should be able to test its vulnerability to log4j-style lookup exploits by entering a string like:

TEST ${upper:foo} ${env:HOME:~} ${date:MM-dd-yyyy} ${base64:SGVsbG8gV29ybGQhCg==} $${foo}

somewhere where it will get logged. If all that gets logged is the verbatim input string with no changes, your system is probably not vulnerable. If any of the ${} blocks are replaced with something else in the logs, however, or if the $$ gets turned into $ or any other changes appear, you should report this to the maintainers of the port ASAP and, until it is fixed, look for ways to change this behavior locally e.g. via configuration.

  • 14
    I can confirm that log4net version 2.0.13 outputs the string verbatim and does not perform any substitutions.
    – John
    Commented Dec 13, 2021 at 15:23
  • 6
    When I've read about that vulnaribility, I couldn't understand a bit how it was expected to work, until I've run a code sample. It was beyond my understanding how someone could build in such an un-feature in an open source project on the reputable platform (Apache). A design flaw is the most diplomatic term to describe it.
    – user9850
    Commented Dec 14, 2021 at 7:49
  • 3
    using the test string here, log4perl does not appear to be affected
    – AKHolland
    Commented Dec 14, 2021 at 19:43
  • 1
    Also note that anything that parses the logs might be vulnerable. Twitter thread: twitter.com/ebrandwine/status/1470876450744147978 Commented Dec 15, 2021 at 20:18

As per the CVE site where common vulnerabilities are posted, it says it affects Log4J through JNDI configurations.

JNDI is – The Java Naming and Directory Interface™ (JNDI) is an application programming interface (API) that provides naming and directory functionality to applications written using the Java™ programming language.

Since in .Net applications we do not use Java or it's runtime, this vulnerability won't be affecting .Net world.

  • 2
    Why are you only considering the .net environment, the question was about more. Also I don’t know if the .net doesn’t implement the jdni interface. Cause that’s where the bug “comes from”…
    – LvB
    Commented Dec 13, 2021 at 11:41
  • 4
    Well @LvB one cool thing about Q&A sites is that you can provide an answer that only focuses on one part of the question without having to also explain how every compiler since the beginning of computing was constructed. Focusing on a framework/language that Prasad is familiar with is of benefit to people also using that particular framework/language, while people not using that framework/language can ignore it, or learn more that may tangentially relate to them. As Ruby also does not implement Java, this applies to Ruby as well.
    – jcolebrand
    Commented Dec 13, 2021 at 19:48
  • Firstly, if you do that you should clarify you are only awnsering the question partly. Secondly you totally disregard the actual vulnerability… regarding the JDNI lookup… (I don’t think it’s vulnerable but that’s just my suspicions I didn’t check it.)
    – LvB
    Commented Dec 13, 2021 at 19:50
  • 3
    Then perhaps @LvB it is better to link to the meta- conversation here to help the clearly (21 rep) new user understand the norms of the site, and be helpful to introduce them to how this particular SE site operates, and what the shared norms are. Inclusivity is something we should all practice daily, nobody is perfect at it. Part of inclusivity is introduction to social norms in a constructive way. Your comment clearly comes across to me as hositle, altho I can now see your attempt to merely provide pro-social-contract form. I understand better now, because you explained to me.
    – jcolebrand
    Commented Dec 13, 2021 at 20:01
  • 1
    @jcolebrand I am sorry you felt my interaction it was hostile, it wasn’t meant to be. (It’s also why I didn’t link to the meta article… since that feels like trying to best someone with the rules) I’ll try next time to be make my intentions more clear what I mean. And I don’t think inclusivity is at all at play… still what is at play is trying to get the right type of responses. And create a community that feels safe. So thank you for your comments. It helps to improve me, us all and the site.
    – LvB
    Commented Dec 13, 2021 at 20:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .