CVE-2024-12798

What it actually does

The vulnerability allows arbitrary code execution through malicious Logback configuration when JaninoEventEvaluator is enabled or referenced. An attacker who can modify an existing Logback configuration file, or influence application startup so that Logback loads an attacker-controlled configuration file, can place Janino expressions that execute code in the context of the Java process. Because exploitation requires prior local or configuration-level influence, this is not typically a direct unauthenticated remote exploit, but successful exploitation can let the attacker run commands with the privileges of the affected application. The described vulnerable Logback ranges are 0.1 through 1.3.14 and 1.4.0 through 1.5.12; upgrade to a corrected Logback release where JaninoEventEvaluator behavior is removed or constrained. The supplied package metadata also references Ubuntu 14.04 LTS flashplugin-nonfree fixed in 11.2.202.569ubuntu0.14.04.1, but the vulnerability description is specific to QOS.CH Logback/JaninoEventEvaluator in Java applications, so software composition and package validation should confirm the actual affected component in use.

Why it matters to the business

If exploited, this flaw can turn a logging configuration change into code execution inside a production Java application, potentially causing service disruption, data exposure, credential theft, or lateral movement from the application runtime. The risk is highest where configuration files are writable by non-administrative users, deployment pipelines accept untrusted configuration, environment variables can be influenced before application startup, or containers mount Logback configuration from writable locations. It is not listed in CISA KEV, is not identified as ransomware-used, has no known exploit maturity in the provided data, and has a low EPSS score, which lowers immediate internet-scale exploitation urgency; however, it has been public for 598 days, so affected systems should still be remediated as part of dependency hygiene and configuration hardening.

How an attack unfolds

An attacker first obtains a foothold or limited privilege that allows them to influence the Java application's Logback configuration, such as write access to logback.xml, access to a mounted configuration directory, control of a deployment artifact, or the ability to set a startup variable or JVM property that redirects Logback to an attacker-controlled configuration file. The attacker then adds or references JaninoEventEvaluator content containing a malicious expression that invokes Java runtime functionality such as Runtime.exec or ProcessBuilder. When the application starts, reloads logging configuration, or evaluates the malicious logging rule, Logback processes the evaluator expression and executes code in the Java process. The resulting commands inherit the permissions, network access, secrets, and filesystem visibility of the application account, enabling persistence, credential collection, further payload staging, or operational disruption.

How to fix it

Upgrade vulnerable Logback components to fixed versions newer than the affected ranges: avoid logback-core/logback-classic versions 0.1 through 1.3.14 and 1.4.0 through 1.5.12, and move to a vendor-fixed release such as 1.3.15 or later in the 1.3 line, or 1.5.13 or later in the 1.5 line, according to the application’s supported dependency path. If the package metadata is applicable to the asset being assessed, update Ubuntu 14.04 LTS flashplugin-nonfree to 11.2.202.569ubuntu0.14.04.1 or later. Remove use of JaninoEventEvaluator from Logback configurations where possible. Lock down Logback configuration file permissions so only trusted deployment or administrative identities can write them. Prevent untrusted users from setting application startup environment variables, JVM properties, or container arguments that control logging configuration. In containerized and orchestrated deployments, mount logging configuration read-only and restrict ConfigMap/Secret update rights. As interim mitigation, search for and remove Janino evaluator expressions from Logback configuration, disable dynamic configuration reload where not required, and enforce code review for logging configuration changes.

How to confirm the fix worked

Confirm dependency versions through software composition analysis, build manifests, Maven/Gradle dependency trees, SBOMs, container image scans, and runtime classpath inspection. Validate that no vulnerable logback-core or logback-classic versions in the affected ranges remain packaged in application artifacts, fat JARs, application servers, or container images. Review active Logback configuration files for JaninoEventEvaluator, evaluator expressions, or suspicious Java execution constructs. Verify file permissions on logback.xml, logback-test.xml, and external logging configuration paths are not writable by application users, service accounts, web users, or non-administrative operators. Confirm startup scripts, service units, container specs, and deployment manifests do not allow untrusted override of Logback configuration path settings. After upgrade, restart affected applications and verify the loaded Logback version at runtime where possible.

Typical attack path

1. Gain limited access to the host, container, deployment pipeline, configuration store, or startup environment for a Java application using vulnerable Logback versions.
2. Identify where Logback configuration is loaded from, such as logback.xml, logback-test.xml, an external mounted file, or a startup property pointing to a custom configuration file.
3. Modify the configuration or redirect application startup to an attacker-controlled configuration containing JaninoEventEvaluator and a malicious expression.
4. Wait for the application to start, restart, reload logging configuration, or process a log event that triggers evaluator execution.
5. Execute commands as the Java application user and use that access to stage tools, read secrets, pivot, or disrupt the service.

How to detect it

To assess prior exploitation, review source control history, artifact repositories, CI/CD logs, container image layers, configuration management logs, Kubernetes audit logs, host file integrity monitoring, and endpoint telemetry for unauthorized changes to Logback configuration files or startup parameters. Focus on additions of JaninoEventEvaluator, evaluator expressions, Java runtime execution methods, shell commands, or configuration paths redirected to writable locations such as /tmp. On hosts and containers, examine modification times, owners, permissions, and hashes of logback.xml, logback-test.xml, and externally referenced Logback configuration files. Review process telemetry for Java processes spawning shell interpreters or command-line utilities, especially sh, bash, cmd.exe, powershell.exe, curl, wget, nc, python, perl, or chmod. Review application logs around restarts or logging reload events for Logback status messages indicating unexpected configuration files, evaluator setup, Janino compilation, or parsing errors. If EDR is available, hunt for child processes launched by java or the application server immediately after configuration changes or service restarts. There are no named threat actors in the supplied data; detection should therefore focus on behavior and configuration artifacts rather than actor-specific infrastructure.

• JaninoEventEvaluator
• ch.qos.logback.classic.boolex.JaninoEventEvaluator
• <evaluator
• <expression>
• java.lang.Runtime
• Runtime.getRuntime().exec
• getRuntime().exec
• java.lang.ProcessBuilder
• new ProcessBuilder
• logback.configurationFile=
• LOGBACK_CONFIGURATION_FILE=
• logback.xml
• logback-test.xml
• /tmp/logback.xml
• /var/tmp/logback.xml
• java -> /bin/sh
• java -> /bin/bash
• java -> cmd.exe
• java -> powershell.exe
• java -> curl
• java -> wget
• java -> nc

What your security team should do

• Inventory Java applications and container images for vulnerable Logback versions, prioritizing internet-facing, privileged, and secret-bearing services.
• Upgrade Logback to a fixed release and rebuild/redeploy applications rather than only patching the host operating system.
• Search repositories, deployment artifacts, mounted configuration directories, and running containers for JaninoEventEvaluator and suspicious evaluator expressions.
• Harden ownership and permissions on Logback configuration files and ensure they are read-only at runtime wherever practical.
• Restrict who can modify deployment configuration, environment variables, JVM system properties, service unit files, Kubernetes manifests, ConfigMaps, and Secrets used by Java applications.
• Review recent changes to logging configuration files and deployment manifests for unauthorized edits since the vulnerability became public.
• Add detection rules for suspicious Logback evaluator usage and Java child-process execution from application processes.
• Because the provided EPSS is low and there is no KEV listing, treat this as a prioritized dependency/configuration hardening issue rather than an emergency internet-wide exploitation event unless local evidence of exposure or suspicious configuration changes exists.