CVE-2025-11226
Patch Available.
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
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.
An arbitrary code execution vulnerability (CVE-2025-11226) has been identified in the conditional processing of Logback configuration files, which allows attackers to execute arbitrary code by compromising an existing Logback configuration file or by injecting an environment variable that points the application at a malicious configuration file. A successful attack requires the Janino library and Spring Framework to be present on the class path, and the attacker must already have the privileges needed to modify the configuration file or the process environment.
Per OWASP: Code Injection is the general term for attack types which consist of injecting code that is then interpreted/executed by the application. This type of attack exploits poor handling of untrusted data.
This issue affects multiple versions of Logback.
Details
Module Info
- Product: Logback
- Affected packages:
ch.qos.logback:logback-core - Affected versions: <1.3.16, >=1.4.0 <1.5.19
- 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.3.16, 1.5.19
- NES for Logback
Vulnerability Info
This High-severity vulnerability is found in the ch.qos.logback:logback-core package in multiple versions of Logback. Logback configuration files support conditional processing through <if condition="..."> elements. When the Janino library is on the class path, the condition attribute is not treated as a restricted expression: after variable substitution, its text is spliced into the body of a Java method and compiled and instantiated at configuration time.
In the 1.2.x line, IfAction.begin() reads the attribute and passes it, unfiltered, to PropertyEvalScriptBuilder.build():
String conditionAttribute = attributes.getValue(CONDITION_ATTR);
if (!OptionHelper.isEmpty(conditionAttribute)) {
conditionAttribute = OptionHelper.substVars(conditionAttribute, ic, context);
PropertyEvalScriptBuilder pesb = new PropertyEvalScriptBuilder(ic);
pesb.setContext(context);
try {
condition = pesb.build(conditionAttribute);
} catch (Exception e) {
addError("Failed to parse condition [" + conditionAttribute + "]", e);
}
if (condition != null) {
state.boolResult = condition.evaluate();
}
}PropertyEvalScriptBuilder.build() wraps the condition text in a method declaration and hands it to Janino's ClassBodyEvaluator, then instantiates the generated class:
private static String SCRIPT_PREFIX = "" + "public boolean evaluate() { return ";
private static String SCRIPT_SUFFIX = "" + "; }";
ClassBodyEvaluator cbe = new ClassBodyEvaluator();
cbe.setImplementedInterfaces(new Class[] { Condition.class });
cbe.setExtendedClass(PropertyWrapperForScripts.class);
cbe.setParentClassLoader(ClassBodyEvaluator.class.getClassLoader());
cbe.cook(SCRIPT_PREFIX + script + SCRIPT_SUFFIX);Any Java expression in the condition attribute, including one that constructs objects with new or calls into classes available on the class path, is therefore compiled and executed with the privileges of the application when the configuration is loaded. An attacker who can write to a Logback configuration file, or who can set the environment used to locate the configuration file so that it points to a file under their control, can run arbitrary code inside the process.
Mitigation
Logback 1.2.x is End-of-Life and will not receive any updates to address this issue. For more information, see here.
Removing the Janino library from the application's class path disables conditional processing in configuration files and prevents the condition attribute from being compiled.
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
- Heihu577 (finder)