CVE-2025-11226

What it actually does

This vulnerability allows arbitrary code execution during Logback conditional configuration processing when logback-core up to and including 1.5.18 is used in a Java application that also has Janino and Spring Framework on the class path. The issue is not typically exploitable as a standalone remote unauthenticated bug: the attacker must already be able to modify an existing Logback configuration file or influence startup-time configuration, such as a configuration file reference or environment/property value, before the Java process starts or reloads logging configuration. If successful, attacker-controlled expressions or configuration content can execute code in the context of the Java application process, with the privileges of that service account.

Why it matters to the business

An attacker who already has significant access to an application host, deployment pipeline, writable configuration location, or service startup environment could turn that access into code execution inside a Java application. This may enable data theft, tampering with application behavior, persistence through malicious configuration, credential harvesting from process memory or environment variables, or staging of additional malware. Current public exploitation signals are low: it is not listed in CISA KEV, is not known to be used in ransomware campaigns from the provided data, has no reported exploit maturity, and has a low EPSS score of 0.00181. However, affected logging libraries are often broadly embedded in Java applications, so organizations should prioritize inventory and remediation for internet-facing, business-critical, or highly privileged Java services.

How an attack unfolds

An attacker first obtains existing privilege in a location that can affect Java application startup or logging configuration, such as write access to logback.xml, logback-test.xml, an externalized configuration directory, a container image layer, a mounted volume, a CI/CD artifact, or service environment variables. The attacker confirms that the target application uses a vulnerable version of logback-core and that Janino and Spring Framework are present on the class path. They then modify or replace the Logback configuration, or set a startup property/environment-controlled configuration reference to point to a malicious configuration file. When the application starts, restarts, or reloads logging configuration, Logback processes the conditional configuration and evaluates attacker-controlled content. The injected code runs with the Java process privileges, allowing the attacker to execute commands, load additional payloads, alter application behavior, or maintain persistence by keeping the malicious configuration in place.

How to fix it

Upgrade logback-core to a version newer than 1.5.18 once available from the upstream or application vendor, and rebuild/redeploy applications that bundle the vulnerable JAR. Where distribution packages are used, apply the vendor-fixed package versions supplied for the affected platform; the provided fixed Ubuntu package references are: Ubuntu 14.04 LTS fixed in 2.7.1-4ubuntu2.4 and Ubuntu 16.04 LTS fixed in 2.7.5-1ubuntu0.16.04.1. Remove unnecessary Janino from application class paths where conditional Logback processing is not required. Restrict write access to Logback configuration files and directories to deployment automation or administrators only. Prevent untrusted users from controlling service environment variables, Java system properties, startup scripts, container environment, Kubernetes ConfigMaps/Secrets, or externalized logging configuration paths. Treat logging configuration as executable-sensitive configuration: code review changes, integrity-monitor files, and redeploy from trusted artifacts. As a mitigation until upgrade, disable or remove conditional Logback configuration constructs where possible and ensure applications cannot load logging configuration from user-writable locations or remote/untrusted paths.

How to confirm the fix worked

Confirm dependency versions by inspecting build manifests, SBOMs, dependency lockfiles, container images, and deployed JARs for logback-core versions up to and including 1.5.18. For Java artifacts, inspect WEB-INF/lib, BOOT-INF/lib, application lib directories, and container layers for logback-core, janino, and Spring Framework JARs. Validate that patched builds no longer include vulnerable logback-core versions and that runtime class paths match the remediated artifacts. Verify file permissions on Logback configuration files and parent directories so only trusted administrative or deployment identities can write them. Review service definitions, container specs, startup scripts, and orchestration manifests for configuration references such as -Dlogback.configurationFile, logging.config, or environment-derived logging paths. Confirm that applications do not load logging configuration from writable temporary directories, shared upload directories, world-writable paths, or untrusted network locations. After remediation, restart affected Java services and verify logs show the expected trusted Logback configuration file being loaded.

Typical attack path

1. Gain existing privileged access to a host, container, build artifact, deployment manifest, configuration repository, mounted volume, or service startup environment.
2. Identify a Java application using logback-core version 1.5.18 or earlier with Janino and Spring Framework available on the class path.
3. Locate or influence Logback configuration sources, such as logback.xml, logback-test.xml, an external configuration file path, startup property, or environment-derived logging configuration value.
4. Insert malicious conditional configuration content or redirect the application to an attacker-controlled Logback configuration file.
5. Trigger application startup, restart, redeploy, or configuration reload so Logback parses the malicious configuration.
6. Achieve code execution in the context of the Java application process and use that access for persistence, credential access, lateral movement, data access, or further payload execution.

How to detect it

Investigate whether Logback configuration files or service startup settings were changed unexpectedly before application starts or restarts. Review source control history, CI/CD logs, artifact repository events, package build logs, container image history, orchestration audit logs, service manager logs, and endpoint file modification telemetry for changes to Logback configuration files or Java startup parameters. On hosts and containers, collect and compare logback.xml, logback-test.xml, external logging configuration files, service unit files, startup scripts, environment files, Kubernetes ConfigMaps/Secrets, Docker Compose files, Helm values, and application deployment manifests. Look for conditional Logback elements containing Java execution patterns, ProcessBuilder, Runtime.exec, reflection, network retrieval, encoded payloads, or references to files in /tmp, /var/tmp, writable application directories, mounted volumes, or remote URLs. Review application logs around startup/reload time for messages indicating a nonstandard Logback configuration file was loaded. Correlate suspicious configuration changes with process creation telemetry from the Java process, outbound network connections from the Java service account, unexpected child processes, new files written by the Java process, or credential access behavior. Because exploitation requires existing privilege, also review authentication, sudo/admin activity, deployment-token use, repository commits, pipeline job runs, and container/orchestration audit events for the identity that modified the configuration.

• logback.xml
• logback-test.xml
• logback-core-1.5.18.jar
• logback-core-1.5.17.jar
• logback-core-1.5.16.jar
• janino-
• -Dlogback.configurationFile=
• logging.config=
• LOGBACK_CONFIGURATION_FILE=
• <if condition=
• <then>
• <else>
• java.lang.ProcessBuilder
• Runtime.getRuntime().exec
• getRuntime().exec
• /bin/sh -c
• cmd.exe /c
• powershell.exe
• curl http
• wget http
• http://
• https://
• file:/tmp/
• file:/var/tmp/
• ConfigurationWatchList
• Found resource [logback.xml]
• Found resource [logback-test.xml]

What your security team should do

• Inventory Java applications and container images for logback-core version 1.5.18 or earlier, prioritizing systems that also include Janino and Spring Framework.
• Patch or rebuild affected applications with a fixed logback-core version or vendor-provided fixed package; apply the provided Ubuntu fixed package versions where applicable.
• Remove Janino from production class paths unless conditional Logback configuration is explicitly required.
• Lock down Logback configuration files, configuration directories, startup scripts, service unit files, container manifests, and environment variable sources to prevent modification by non-administrative users.
• Search repositories, deployment manifests, and runtime configurations for use of -Dlogback.configurationFile, logging.config, externally mounted logback.xml files, or configuration references to writable or remote locations.
• Enable file integrity monitoring for Logback configuration files and alert on unexpected changes to logging configuration or service startup environment.
• Hunt for suspicious Logback conditionals that invoke Java process execution, reflection, scripting, network download behavior, or references to temporary/external configuration locations.
• Because current exploitation signals are low and the issue requires existing privilege, prioritize remediation based on exposure, application criticality, service account privileges, and ease of configuration tampering rather than treating it as mass internet-exploitable.