Logback is not affected by Log4Shell. CVE-2021-44228 lives in Apache Log4j 2, specifically inside its core module, and does not touch Logback or SLF4J. Confusion persists because Logback, SLF4J, and Log4j 2 are all Java logging libraries that often sit side by side in a project. Here is exactly what was exposed and how to confirm your own application's exposure.

What Each Library Does

You need to know the role each library plays.

SLF4J Is Only the Facade

  • SLF4J is a logging facade. An API. It provides a common interface but never writes a log line itself. SLF4J routes messages to an implementation: Log4j 2, Logback, or another. Because it is only an API, it is not vulnerable to CVE-2021-44228. The question of slf4j log4shell exposure comes up often. The answer is clear: SLF4J itself is safe.

Logback

  • Logback is an implementation, designed as the successor to the original Log4j (version 1). It is not affected by Log4Shell. Logback did have its own separate issue, CVE-2021-42550, a lower-severity vulnerability. That flaw requires an attacker to already have write access to the Logback configuration file. Upgrade to Logback 1.2.9 or later to close it.

Log4j 2 Is the One That Matters

  • Log4j 2 (the core module) is the only library directly affected by CVE-2021-44228. If your application uses Log4j 2 as its implementation, update that core module to version 2.17.1 or later on Java 8+.

Spring Boot and Log4Shell

Spring Boot ships with Logback as its default implementation. A stock Spring Boot application is not vulnerable to Log4Shell.

You can change the implementation. Add the spring-boot-starter-log4j2 artifact, or let any transitive pull in the Log4j 2 core module, and your application becomes exposed. The spring boot log4shell question is common because many developers assume Spring Boot uses Log4j 2. It does not by default. The only way to be certain is to inspect the resolved tree of your project's dependencies.

Check Which Implementation Your Project Uses

Confirm whether Log4j 2 is present.

  1. Run your build tool's reporting command. Maven: mvn dependency:tree. Gradle: gradle dependencies.
  2. Search the output for log4j-core. If it appears, your project uses Log4j 2.
  3. Check its version. It must be 2.17.1 or later on Java 8+.
  4. If log4j-core is absent, your implementation is likely Logback (the Spring Boot default) or another, and you are not affected by CVE-2021-44228.

If you use SLF4J, the output shows which implementation SLF4J routes to. Look for logback-classic, log4j-core, or another concrete library in the tree.

Logback's Own Vulnerability CVE-2021-42550

Logback is not affected by Log4Shell. It does have its own security issue: CVE-2021-42550. This allows arbitrary code execution if an attacker can write to the Logback configuration file. Severity is lower because it requires prior access to the system. If you use Logback, upgrade to version 1.2.9 or later.

Do not confuse CVE-2021-42550 with CVE-2021-44228. Separate vulnerabilities. Separate libraries.

Common Misunderstandings

Three points get muddled.

  • SLF4J is not an implementation. It is an API. Even if your code calls SLF4J, the actual work is done by a backend. That backend determines your exposure.
  • Spring Boot does not automatically use Log4j 2. The default is Logback. Only you or a transitive can bring in Log4j 2 and open the exposure.
  • Logback and Log4j 2 are different projects. Logback is not a fork or variant of Log4j 2. Separate codebases, separate vulnerabilities.

Checking for Log4j 2 in Complex Projects

In larger applications, Log4j 2 may arrive transitively through a library you did not directly add. A dependency of a dependency might pull in the core module. This is why checking the resolved tree is the reliable way to confirm the active implementation. Do not rely on your own code or configuration files alone. Inspect the full graph.

If you find the core module at a version below 2.17.1, update it. This may mean upgrading the library that brought it in or overriding the version in your build configuration.

Using Log4Shell Tools for Verification

Use log4shell.tools to check your project for Log4j 2 payloads and verify versions. The site runs defensive, detection-only checks for Log4Shell.