CVE-2026-61741: XML External Entity (XXE) Injection in http4s-scala-xml

The library http4s-scala-xml is an integration component in the http4s ecosystem. It is designed to facilitate the parsing and serialization of XML payloads in Scala-based HTTP services. To achieve this, it provides an implicit EntityDecoder that parses incoming request bytes directly into Scala scala.xml.Elem objects. By default, applications exposing endpoints that accept XML payloads depend on this decoder to process user input without additional validation.

Historically, the library relied on the default configuration of the Java Runtime Environment's XML processing utilities. Specifically, it initialized javax.xml.parsers.SAXParserFactory using default parameters, which do not restrict external entity resolution. This creates an attack surface where any unauthenticated client capable of sending HTTP requests to an XML endpoint can control the input parsed by the underlying JVM parser.

The vulnerability is classified under CWE-611 (Improper Restriction of XML External Entity Reference). The impact of this security gap includes arbitrary local file read access, resource starvation via nested entity loops, or outbound network pivoting via server-side request forgery. Because the parser boundaries cross the application context to local OS resources and network endpoints, the vulnerability has been assigned a CVSS v3.1 base score of 9.3.

The root cause of this vulnerability lies in the default configuration behavior of the Java Virtual Machine's built-in SAX parser factory. When an application instantiates a parser factory using SAXParserFactory.newInstance, the underlying JVM relies on the platform's default provider, which is typically Apache Xerces. By default, Xerces is configured to process DOCTYPE declarations, resolve external parameter and general entities, and load external Document Type Definitions (DTDs).

In the vulnerable codebase, the scalaxml package object defined its factory as override val saxFactory = SAXParserFactory.newInstance. This global parser factory instance was then shared across all parsing operations triggered by the implicit XML entity decoder. Since no security features were explicitly enabled on this factory, the standard security controls mandated for handling untrusted input were entirely absent.

When the parser processes a document containing an inline DOCTYPE definition with a SYSTEM identifier, it attempts to fetch the target resource. If the identifier points to a local file path, the parser reads the file from the local file system using the privileges of the active JVM process. If the identifier points to a remote URL, the parser initiates an outbound HTTP request, making the system highly vulnerable to unauthorized internal network discovery.

A detailed inspection of the vulnerability patch in commit 326f965a2c45fc2ddbc22545dcf551b0f719f4c8 reveals the vulnerable pattern and the corresponding remediation. The vulnerable implementation in scala-xml/src/main/scala/org/http4s/scalaxml/package.scala was defined as follows:

package object scalaxml extends ElemInstances {
  override val saxFactory = SAXParserFactory.newInstance
}

The patch replaces this line with an explicitly hardened initializer block that disables multiple insecure XML capabilities. Below is the patched code showing how features are disabled to enforce secure processing:

package object scalaxml extends ElemInstances {
  override val saxFactory = {
    val parserFactory = SAXParserFactory.newInstance
    // Enable Secure Processing to limit entity expansion limits
    parserFactory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true)
    // Disable external DTD loading
    parserFactory.setFeature(
      "http://apache.org/xml/features/nonvalidating/load-external-dtd",
      false,
    )
    // Reject DOCTYPE declarations completely
    parserFactory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)
    // Stop resolution of external general entities
    parserFactory.setFeature("http://xml.org/sax/features/external-general-entities", false)
    // Stop resolution of external parameter entities
    parserFactory.setFeature("http://xml.org/sax/features/external-parameter-entities", false)
    // Disable DTD URI resolution
    parserFactory.setFeature("http://xml.org/sax/features/resolve-dtd-uris", false)
    // Disable XML Inclusion mechanisms
    parserFactory.setXIncludeAware(false)
    parserFactory.setNamespaceAware(false)
    parserFactory
  }
}

The most important security control introduced here is the disallow-doctype-decl feature set to true. This instructs the parser to immediately halt processing and throw a parsing exception if the XML input contains a <!DOCTYPE structure. Disabling parameter and general entities serves as a secondary layer of defense in depth, ensuring protection even if some child classes bypass the DOCTYPE restriction.

Exploitation of this vulnerability requires network access to any HTTP route configured to consume XML bodies. The target route must use the implicit xmlDecoder to parse the request payload. No authentication is required to interact with the XML parser if the route itself is publicly accessible.

An attacker seeking to read arbitrary files from the server hosts a request containing a customized DTD. The payload specifies the target local file using a SYSTEM URI, then references the defined entity in the main body. If the application processes the XML and includes the parsed elements inside its HTTP response or an application log, the content of the file is rendered back to the attacker.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE root [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>
  <data>&xxe;</data>
</root>

If the application does not reflect the input (blind XXE), the attacker can execute Server-Side Request Forgery. By supplying an internal network URL in the SYSTEM entity definition, the attacker forces the JVM parser to perform GET requests against internal assets, potentially exposing cloud service provider metadata endpoints. Furthermore, recursive entity expansion, or the Billion Laughs attack, can be sent to cause the server's heap to exhaust, inducing a denial of service.

The impact of successful exploitation is severe and varies depending on the local file permissions and the internal network architecture. An attacker can access configuration files, database credentials, server certificates, and private key files stored on the host filesystem. This is limited only by the operating system user permissions under which the JVM process runs.

In containerized or cloud-hosted environments, SSRF vectors pose a significant escalation path. An attacker can query metadata service endpoints such as http://169.254.169.254/latest/meta-data/ to retrieve temporary IAM credentials. These credentials can then be used to compromise the wider cloud infrastructure hosting the vulnerable container.

Finally, the threat of denial of service via XML entity expansion remains high for unpatched systems. A single small request can expand into gigabytes of data in memory. This resource consumption triggers intensive garbage collection pauses and eventually leads to an OutOfMemoryError, crashing the server process and causing downtime.

The vulnerability is remediated by upgrading the http4s-scala-xml dependency to version 0.24.1 for the 0.24.x series, or version 1.0.0-M39 for the 1.x.x milestone series. These releases hard-code secure settings directly on the shared SAXParserFactory instance, removing the insecure defaults.

If upgrading is not an immediate option, developers can mitigate the risk by manually declaring a secured SAXParserFactory inside their project scope. This custom factory must explicitly define features disabling DTDs, parameter entities, and external general entities. This secure factory can then be wrapped into a custom implicit EntityDecoder to override the vulnerable default decoder.

The fix applied in commit 326f965a2c45fc2ddbc22545dcf551b0f719f4c8 is complete. It blocks XML External Entities, parameter entities, and disables XML Inclusion (XInclude) and XML namespaces. Because disallow-doctype-decl is set to true, all adjacent exploitation techniques utilizing DTD-based validation or external schemas are neutralized.