CVE-2024-12801

What it actually does

The flaw is a server-side request forgery condition in QOS.CH Logback's XML configuration parsing path, specifically involving SaxEventRecorder handling of XML DOCTYPE declarations. If an attacker can modify or influence a Logback XML configuration file, such as logback.xml or logback-test.xml, they can introduce external entity or external DTD references that cause the Java process to initiate outbound requests to attacker-controlled or internal network locations while parsing the configuration. The attacker prerequisite is important: exploitation generally requires prior ability to alter configuration content or a deployment pipeline artifact. Successful exploitation may allow internal network probing, access to cloud metadata services, interaction with localhost-only services, or exfiltration of limited data reachable through XML entity resolution. Affected Logback versions are reported as 0.1 through 1.3.14 and 1.4.0 through 1.5.12.

Why it matters to the business

Applications using vulnerable Logback versions may be abused as a network pivot if an attacker can tamper with logging configuration. The most significant operational risk is unauthorized access to internal-only services or cloud instance metadata from trusted application servers, potentially exposing credentials, service tokens, or sensitive internal endpoints. Because exploitation requires configuration compromise and current public exploitation likelihood is low, with EPSS reported at 0.00225 and no CISA KEV listing, this is typically a hardening and supply-chain hygiene priority rather than an emergency internet-wide incident; however, it becomes high priority for systems where configuration files are user-controlled, externally supplied, dynamically reloaded, or modified through CI/CD automation.

How an attack unfolds

An attacker first obtains a way to influence a Logback XML configuration file, commonly through compromised deployment artifacts, write access to application configuration, a vulnerable configuration management process, or abuse of an administrative feature that accepts logging configuration. The attacker then modifies the XML DOCTYPE declaration to reference an external DTD or entity hosted on attacker infrastructure or an internal URL of interest. When the Java application starts or reloads Logback configuration, SaxEventRecorder parses the XML and resolves the external reference. That resolution causes the application process to make outbound network requests from the server's network position. The attacker observes callbacks to confirm code path reachability, then attempts requests to internal targets such as metadata services, localhost ports, service discovery endpoints, or private management interfaces. If sensitive data is retrievable through the XML resolution behavior, the attacker may exfiltrate it indirectly through controlled external entity references or use the SSRF behavior for internal reconnaissance.

How to fix it

Upgrade Logback to a fixed release newer than the affected ranges: use 1.3.15 or later for the 1.3.x line, or 1.5.13 or later for the 1.5.x line. If direct upgrade is not immediately possible, prevent untrusted users and automation from modifying Logback XML configuration files, disable dynamic configuration reload where feasible, remove any DOCTYPE declarations from Logback configuration, and enforce strict file integrity monitoring on logging configuration. Apply outbound egress controls from Java application hosts, especially blocking access to cloud metadata IPs and unnecessary internal management networks. For Ubuntu 14.04 LTS package data provided in the input, flashplugin-nonfree is listed as fixed in 11.2.202.577ubuntu0.14.04.1, but this package does not align with the Logback library described by the vulnerability; teams should verify both operating-system package advisories and application dependency inventories rather than relying on OS package status alone.

How to confirm the fix worked

Confirm application dependency inventories and runtime classpaths do not contain vulnerable Logback versions from 0.1 through 1.3.14 or 1.4.0 through 1.5.12. Check Maven, Gradle, SBT, shaded JARs, container images, and vendor-supplied application bundles for logback-core and logback-classic versions. Inspect Logback XML configuration files for DOCTYPE or external entity declarations and confirm they are absent unless there is a documented, safe business requirement. Validate that configuration files are not writable by application users or untrusted deployment jobs. Test egress controls by confirming application hosts cannot reach cloud metadata endpoints or arbitrary external hosts except through approved paths. After remediation, restart or redeploy affected Java applications so the corrected Logback library and sanitized configuration are active.

Typical attack path

1. Identify a Java application using Logback versions 0.1 through 1.3.14 or 1.4.0 through 1.5.12.
2. Gain the ability to modify or supply a Logback XML configuration file, such as through compromised filesystem access, deployment pipeline access, configuration management abuse, or an exposed administrative configuration feature.
3. Insert a malicious DOCTYPE declaration or external entity reference into the XML configuration.
4. Trigger application startup, restart, or configuration reload so Logback parses the modified XML.
5. Receive an outbound callback from the Java process to attacker-controlled infrastructure, confirming exploitability.
6. Change the external reference to target internal resources such as cloud metadata services, localhost services, service discovery endpoints, or private management APIs.
7. Use the SSRF channel for internal network reconnaissance or limited data retrieval, depending on egress controls and XML parser behavior.

How to detect it

Investigate whether Logback XML configuration files were modified unexpectedly, especially around application restarts, deployments, or configuration reload events. Review source control history, artifact repository metadata, CI/CD job logs, configuration management logs, container image diffs, and host file integrity monitoring for additions of DOCTYPE, ENTITY, SYSTEM, or PUBLIC declarations in logback.xml or logback-test.xml. On hosts and containers, inspect filesystem timestamps and ownership changes for Logback configuration files. Review application logs for XML parsing errors, external entity resolution failures, DTD loading errors, or configuration reload events near suspicious outbound network activity. Network telemetry should be searched for outbound connections from Java processes to unusual external domains, attacker-controlled infrastructure, internal IP ranges, localhost, link-local metadata endpoints, or cloud provider metadata services. Cloud audit logs should be checked for unusual credential use shortly after any suspicious metadata endpoint access. Because exploitation requires configuration tampering, correlate outbound callbacks with configuration changes and deployment activity rather than treating every DOCTYPE finding as confirmed compromise.

• <!DOCTYPE
• <!ENTITY
• SYSTEM "http://
• SYSTEM 'http://
• SYSTEM "https://
• SYSTEM 'https://
• PUBLIC "-//
• logback.xml
• logback-test.xml
• SaxEventRecorder
• 169.254.169.254
• http://169.254.169.254
• https://169.254.169.254
• metadata.google.internal
• metadata/computeMetadata/v1
• 169.254.170.2
• 100.100.100.200
• fd00:ec2::254
• latest/meta-data
• latest/user-data
• instance-data
• java.net.UnknownHostException
• java.net.ConnectException
• External Entity
• DOCTYPE is disallowed
• DocumentBuilderFactory
• SAXParseException

What your security team should do

• Inventory Java applications and container images for logback-core and logback-classic versions 0.1 through 1.3.14 and 1.4.0 through 1.5.12.
• Prioritize applications where Logback XML configuration can be modified through administrative interfaces, tenant-controlled inputs, mounted volumes, CI/CD jobs, or externalized configuration stores.
• Upgrade to Logback 1.3.15 or later, or 1.5.13 or later, depending on the supported application line.
• Search repositories, deployed configuration directories, and container images for suspicious DOCTYPE and external entity declarations in Logback XML files.
• Lock down permissions on logging configuration files and disable dynamic reconfiguration if not required.
• Add egress controls preventing Java application workloads from reaching cloud metadata endpoints, localhost-only administrative ports, and unnecessary internal networks.
• Review deployment pipeline and configuration management audit logs for unauthorized changes to Logback configuration files.
• Treat unexpected outbound HTTP, HTTPS, DNS, or LDAP traffic from Java application processes during startup or configuration reload as suspicious.
• Do not rely solely on the listed Ubuntu flashplugin-nonfree fixed package because the vulnerability description concerns the Logback Java library; validate application dependencies directly.