Is log4js-node affected by the log4s vulnerability?

[saschafoerster]

https://cve.mitre.org/cgi-bin/cvename.cgi?name=2021-44228

I wonder if this tool is also affected by this vulnerability: it is used in etherpad and I found this dependency by searching for log4j on servers to find out, if they are affected in anyway.

[kjh0829]

i use 0.6.29 version,

I can't find the problematic 'jndi'.

Did anyone find it?

[westlakem]

Following, but in my research the issue seems to stem from JndiLookup, which wouldn't even apply to all uses of Log4J. I'm confident enough to come on here and say I'm fairly certain log4js isn't impacted, but would love someone more familiar with the CVE and Log4JS to confirm.

[gmillerd]

This is a JS implementation of a log4 like pattern in js, it is not a port of log4j nor log4j2. It doesn't use jini or ldap.

log4js doesn't have a native way to eval or execute code in the methods, you pass it values and it logs them (I think I am on solid ground for the appenders plugins as well, obviously someone could do that).

This is often where the format ("%a %b %U") has custom format values that hook code: how much memory, what is the heap size, what is the runtime since the last log, what is my execution path, etc.

logspec.PatternLayout.cspec.U = { return "under defined value" }

That said, anyone that can generate log messages can impact something, potentially disk filling a system, impacting your graylog, running up your costs with loggly; don't allow people to control code that "directly" pushing into your backend infrastructure. You should admin your infrastructure well.

If you are using log4js in a page for browsers gself and someone creates a script with a log.error() that points to the same end point the browser was, that is a problem.

CVE's are one thing, patterns that allow them to be significantly impactful is not a problem of the CVE.

[nomiddlename]

There is no Java in log4js, no JNDI, no LDAP. It shares a name, and partially the idea of appenders and loggers. So this vulnerability doesn't really apply to log4j, but @gmillerd 's general words of caution against logging user-supplied values directly are worth noting.