About the Log4j2 vulnerabilities

From Okapi Framework
Jump to navigation Jump to search

See CVE-2021-45105, CVE-2021-45046, CVE-2021-44228, and the Log4j Security page.

After the recent weave of remote code execution vulnerabilities related to Apache Log4j we checked all the Okapi code, and that of all Okapi-related projects hosted under https://bitbucket.org/okapiframework/:

None of that code depends on log4j, directly or indirectly.
So we are not affected.

But it does not mean you are safe and have nothing to do.
If a product using Okapi binds log4j with SLF4J, then they are at risk, but it is not because of Okapi.
They should apply the log4j updates as necessary, or switch to another logging framework.

The Okapi Framework uses SLF4J for logging.

That is an abstraction for various logging frameworks (e.g. java.util.logging, logback, log4j) allowing developers (or even end users) to plug in the desired logging framework at deployment time.

Okapi itself does not require an update, as it does not come "out of the box" with any one logging framework.

Some of our projects use Okapi to build applications that bind to a logging framework:

  • The Okapi binaries bind slf4j to logback.
  • Acorn binds with log4j12, which is not affected by the recent disclosures
    (but log4j12 is unmaintained, deprecated, and has its own share of problems)