Jackson is not affected by log4j/logback CVEs

(because it does not use either logging framework)

TL;DNR;

Before explaining things in more details, I will make a simple statement: neither core Jackson library nor any of its FasterXML-maintained extension modules use either Log4j or Logback logging frameworks.
The only known use of logging from two extension modules (Afterburner, Blackbird): they use JDK logging in 2 error handling cases.

Given this, Jackson is not affected by log4j 2.x (or 1.x) or Logback-related security vulnerabilities.

Background: CVE-2021–44228

Most of you are by now aware of a severe security vulnerability — CVE-2021–44228 — reported against log4j versions 2.0–2.15. This vulnerability is considered of CRITICAL severity as it may allow Remote Code Execution (RCE) to attackers. There are also a somewhat related but less serious CVEs against log4j 1.x and Logback (alternative logging framework to log4j), for example CVE-2021–42550.

The usual fix to apply is to either avoid use completely (unlikely and difficult as logging is an important part of most modern systems) or to upgrade to a newer version of the affected library, one with the fix.

Version upgrade for direct dependencies is usually relatively easy — although even this can be challenging for older legacy systems — but the real challenge is to figure out how to do upgrade in case of transitive dependencies: cases where your application or service does not define direct dependency (and may not even use the logging framework in question), but where dependency is brought in by something application does depend on.
In those cases it is usually necessary to actually upgrade to a later version of the dependency or dependencies that bring in log4j 2.x (in this case), one that itself depends on fixed version.
Alternatively it may be enough to add a direct dependency and force use of a new fixed log4j/logback version: but even in this case testing is needed to ensure that the version used is what you expect. Either way it is important to know which dependencies use one of these frameworks.

Jackson and Logging: no direct relationship

So: does Jackson (its core components, extensions maintained by FasterXML) use either log4j framework or Logback?

No. From the beginning I have felt that the logging frameworks are best suited for use by applications and other frameworks — but less so by libraries. As such Jackson has never (*) directly used logging frameworks.

(*) There is one specific exception, mentioned earlier: Afterburner/Blackbird modules use JDK logging for one specific case of errors.

Reasons include:

• Due to existence of multiple logging APIs, library traditionally had to decide which one to use/support — while less of a problem these days (just use slf4j), this used to be a bigger challenge when Jackson started.
  Not using logging also removes the need for one or more external dependencies.
• Logging framework configuration is a global concern, whereas configuration of a library like Jackson is much more localized: there may be multiple unrelated uses of Jackson by frameworks and service/application itself. It seemed difficult to come up with meaningful logging where there is no real context for execution (that is, it is hard to know how Jackson is being used and what kind of processing is “log-worthy”)
• Almost all potential logging use cases for Jackson have been (or could be) better handled by an extension point which allows SOMETHING ELSE to handle responsibilities like logging — so Jackson in effect prefers handing over possible need for logging to however is in better position to do so.
• Many logging use cases would, in general, be better handled by tracing, or metrics/statistics interfaces: logging systems allow printing out semi-formatted text, which for events is about the least convenient and useful way to do it. It seems much better to provide structured, contextual data, over printing out human-readable (but not very machine-processable) log lines.

Of these points I think my current thinking can be summarized as follows:

1. Jackson core does not use logging frameworks directly and there are no plans for it to do so in future.
2. Jackson core should provide extension points to expose all pertinent information so that frameworks, applications and services may produce all log output of interest they desire.

Coda

While there are many security problems, concerns, related to Jackson and other libraries, current issues wrt Log4j and Logback are not one of them. :)

Happy, Secure Holidays everyone!