CVE-2026-78224 in Mirth Connect
Summary
by MITRE • 09/11/2026
The XSLT Transformer Step builds a bare TransformerFactory without the proper security options set, so XXE injection can allow data exfiltration and denial-of-service attacks.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified in the XSLT Transformer Step stems from an insecure configuration of the underlying XML processing engine, specifically within the Java-based javax.xml.transform.TransformerFactory implementation. When this step is executed, it instantiates a bare TransformerFactory without applying necessary security constraints or feature flags that are standard practice for secure XML parsing. This oversight creates a critical attack surface where malicious actors can exploit the lack of restrictions on external entity resolution and network access during the transformation process. The core technical flaw lies in the failure to disable features such as http://javax.xml.XMLConstants/feature/disallow-doctype-decl or to set appropriate security managers, which effectively leaves the parser vulnerable to XML External Entity (XXE) injection attacks.
In a typical XXE scenario involving an XSLT transformation, an attacker can supply a crafted XML input that includes external entity declarations pointing to local file systems or internal network resources. Because the TransformerFactory does not enforce strict security policies by default in this specific implementation context, the parser resolves these entities during the stylesheet processing phase. This resolution allows for arbitrary file read operations on the host system where the application is running. An attacker could potentially access sensitive configuration files, source code, credentials stored in local directories, or other confidential data that would otherwise be inaccessible through normal application interfaces. The ability to exfiltrate this data represents a severe confidentiality breach and can serve as an initial foothold for further lateral movement within the network infrastructure.
Beyond data exfiltration, the insecure configuration also facilitates denial-of-service attacks against the target system. By crafting XML inputs that trigger resource-intensive entity expansions or recursive external references, attackers can consume excessive amounts of CPU and memory resources on the server processing the XSLT transformation. This type of attack, often referred to as a Billion Laughs attack or XML bomb, exploits the parser's tendency to expand entities fully before performing the transformation. Since the TransformerFactory lacks safeguards against such resource exhaustion patterns, the application can become unresponsive or crash entirely, leading to service disruption for legitimate users and requiring manual intervention or restarts to restore availability.
This vulnerability aligns with CWE-611, which describes Improper Restriction of XML External Entity Reference, a common issue in applications that process user-supplied XML without adequate validation or configuration hardening. From an offensive security perspective, this flaw maps directly to the MITRE ATT&CK technique T1059.007, specifically Command and Scripting Interpreter via XML parsing mechanisms, as well as data exfiltration techniques such as Exfiltration Over Unencrypted Non-C2 Protocol if the external entities are directed to attacker-controlled servers. The lack of input validation combined with permissive parser settings creates a high-severity risk that requires immediate remediation to prevent both information disclosure and service degradation.
To mitigate this vulnerability, developers must explicitly configure the TransformerFactory instance before use by disabling DTD processing entirely or restricting access to external resources. This can be achieved by setting specific features on the factory object, such as enabling http://javax.xml.XMLConstants/feature/disallow-doctype-decl which prevents the parser from recognizing DOCTYPE declarations altogether. Alternatively, if DTDs are required for legitimate business logic, a custom EntityResolver should be implemented to restrict external entity resolution to only trusted and expected sources, effectively sandboxing the parsing operation. Additionally, implementing resource limits on the XML parser can help mitigate denial-of-service risks by capping the depth of entity expansion or limiting memory usage during transformation operations. Regular security audits of XML processing components are essential to ensure that default insecure configurations do not persist in production environments.