CVE-2026-1225

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 resource injection vulnerability (CVE-2026-1225) has been identified in the configuration file processing of logback-core, which allows attackers who can write to an existing Logback configuration file to make Logback instantiate any class already present on the class path.

Per OWASP: This attack consists of changing resource identifiers used by an application in order to perform a malicious task. When an application defines a resource type or location based on user input, such as a file name or port number, this data can be manipulated to execute or access different resources.

This issue affects all versions of Logback prior to 1.5.25.

Details

Module Info

• Product: Logback
• Affected packages: ch.qos.logback:logback-core
• Affected versions: <1.5.25
• GitHub repository: https://github.com/qos-ch/logback

• Published packages: https://central.sonatype.com/artifact/ch.qos.logback/logback-core

• Package manager: Maven
• Fixed in:
  
  • OSS Logback 1.5.25
  • NES for Logback

Vulnerability Info

This Low-severity vulnerability is found in the ch.qos.logback:logback-core package in all versions of Logback prior to 1.5.25. When Joran processes a configuration file, a nested element that maps to a complex property of its parent component (a setter such as setEncoder or an adder such as addAppender) may name its implementation in a class attribute. Logback loads that class and creates an instance of it without checking that the class is compatible with the parameter type the setter or adder expects. In the 1.2.x line this happens in NestedComplexPropertyIA.begin():

String className = attributes.getValue(CLASS_ATTRIBUTE);
// perform variable name substitution
className = ec.subst(className);

Class<?> componentClass = null;
try {
    if (!OptionHelper.isEmpty(className)) {
        componentClass = Loader.loadClass(className, context);
    } else {
        // guess class name via implicit rules
        ...
    }
    ...
    actionData.setNestedComplexProperty(componentClass.newInstance());

Because the constructor runs before Logback tries to pass the object to the setter or adder, any class on the class path with a public no-argument constructor is instantiated, and its constructor and static initializer execute, even when the object is of the wrong type. The type mismatch is only reported, as a configuration error, when Logback later tries to attach the object to its parent; before that, Logback hands the object its context if it is context-aware, applies any nested configuration elements to it, and starts it if it implements LifeCycle. An attacker who can modify a configuration file can use this to trigger the construction-time side effects of arbitrary classes already present on the class path. Exploitation requires write access to the configuration file and a suitable class on the application's class path.

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

• Code Intelligence (finder)
• Google Fuzz (finder)