CVE-2026-13006
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.
A remote code execution vulnerability (CVE-2026-13006) has been identified in the conditional configuration processing of logback-core, which allows attackers who can modify a logback configuration file, or set an environment variable that points logback at one, to execute arbitrary code when the Janino library is on the class path. It circumvents the existing protection against CVE-2025-11226.
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: >=0.9.20 <=1.5.36
- 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.37
- NES for Logback v1.2.15
Vulnerability Info
This High-severity vulnerability is found in the ch.qos.logback:logback-core package in multiple versions of Logback. Joran's <if> element takes a condition attribute that Logback hands to the Janino compiler as a Java expression. After variable substitution, PropertyEvalScriptBuilder.build() wraps the attribute in a method body, compiles it, and the result is evaluated while the configuration is processed:
private static String SCRIPT_PREFIX = "" + "public boolean evaluate() { return ";
private static String SCRIPT_SUFFIX = "" + "; }";
public Condition build(String script) throws ... {
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);
...
}Because the condition is compiled as ordinary Java, it can call any class visible to the application, not only the property helpers that conditions are documented to use. The 1.2.x line applies no filtering before compiling. Later releases added a guard for CVE-2025-11226 that rejects the condition only when it contains the literal text new :
private boolean hasNew(String conditionStr) {
return conditionStr.contains("new ");
}That check is easy to get around. Janino decodes Java Unicode escapes (a backslash, the letter u and four hex digits) before it parses the source, so an escaped new keyword never matches the text test. A condition can also run commands without constructing an object at all, for example by calling a static factory such as Runtime.getRuntime().exec(...). In both cases the expression compiles and runs with the privileges of the application as soon as logback reads the configuration file. Exploitation requires Janino on the class path and the ability to write a configuration file or to point logback at an attacker-controlled one through an environment variable.
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
- IcySun (finder)
- yulate (finder)