Summary
Netty's XmlDecoder can expose an XML External Entity (XXE) risk when it uses AsyncXMLInputFactory without hardened security settings, leaving DTD and entity handling enabled.
Any component that can feed XML into such a pipeline and include a DOCTYPE declaration may cause the Aalto XML parser to resolve external entities, potentially leaking data or interacting with internal services.
Netty's XmlDecoder can expose an XML External Entity (XXE) risk when it uses AsyncXMLInputFactory without hardened security settings, leaving DTD and entity handling enabled.
Any component that can feed XML into such a pipeline and include a DOCTYPE declaration may cause the Aalto XML parser to resolve external entities, potentially leaking data or interacting with internal services.
Affected context
This vulnerability arises in Netty-based applications that:
- Use
XmlDecoderin their channel pipeline - Instantiate
AsyncXMLInputFactory(via Aalto XML) without disabling DTDs or external entities - Accept XML input from callers that are not fully trusted or are only partially validated
It is most relevant in server-side pipelines where XML payloads are processed asynchronously and the underlying parser behavior is not explicitly locked down.
This vulnerability arises in Netty-based applications that:
- Use
XmlDecoderin their channel pipeline - Instantiate
AsyncXMLInputFactory(via Aalto XML) without disabling DTDs or external entities - Accept XML input from callers that are not fully trusted or are only partially validated
It is most relevant in server-side pipelines where XML payloads are processed asynchronously and the underlying parser behavior is not explicitly locked down.
Exploit preconditions
- Attack surface: Any Netty channel pipeline that includes
XmlDecoderand processes XML from external or semi-trusted sources. - Required access: Ability to send arbitrary XML bytes into the affected pipeline (e.g., over TCP, HTTP, WebSocket, or other protocols using Netty).
- Trigger point: Submission of XML containing a
DOCTYPEdeclaration with external or parameter entities, which theAsyncXMLInputFactorypasses to Aalto with entity resolution active. - Why exploitation is possible: The XML factory is instantiated without a security configuration that disables DTDs, external entities, or restricts resolution, allowing the parser to fetch external resources or expose internal data based on entity expansion.
- Attack surface: Any Netty channel pipeline that includes
XmlDecoderand processes XML from external or semi-trusted sources. - Required access: Ability to send arbitrary XML bytes into the affected pipeline (e.g., over TCP, HTTP, WebSocket, or other protocols using Netty).
- Trigger point: Submission of XML containing a
DOCTYPEdeclaration with external or parameter entities, which theAsyncXMLInputFactorypasses to Aalto with entity resolution active. - Why exploitation is possible: The XML factory is instantiated without a security configuration that disables DTDs, external entities, or restricts resolution, allowing the parser to fetch external resources or expose internal data based on entity expansion.
Why this happens
The root cause is insecure default handling of XML entity resolution when wiring Netty's XmlDecoder to an AsyncXMLInputFactory that does not enforce secure parsing rules.
This maps to CWE-611: Improper Restriction of XML External Entity Reference, because the parser is allowed to process DOCTYPE declarations and external entities from potentially untrusted XML input.
At a design level, the XML processing pipeline implicitly trusts parser defaults instead of explicitly disabling external entities, restricting DTD usage, or enforcing a safe configuration profile for all XML sources.
The root cause is insecure default handling of XML entity resolution when wiring Netty's XmlDecoder to an AsyncXMLInputFactory that does not enforce secure parsing rules.
This maps to CWE-611: Improper Restriction of XML External Entity Reference, because the parser is allowed to process DOCTYPE declarations and external entities from potentially untrusted XML input.
At a design level, the XML processing pipeline implicitly trusts parser defaults instead of explicitly disabling external entities, restricting DTD usage, or enforcing a safe configuration profile for all XML sources.
Potential impact
- Attackers may exfiltrate sensitive files that the Netty process can read by referencing them in XML entities.
- Attackers can perform server-side request forgery (SSRF) by forcing the parser to fetch resources from internal network services.
- Attackers could probe internal infrastructure topology by observing timing or error behavior from entity resolution.
- Attackers may cause performance degradation or resource exhaustion if large or recursive entities are processed.
- Attackers may exfiltrate sensitive files that the Netty process can read by referencing them in XML entities.
- Attackers can perform server-side request forgery (SSRF) by forcing the parser to fetch resources from internal network services.
- Attackers could probe internal infrastructure topology by observing timing or error behavior from entity resolution.
- Attackers may cause performance degradation or resource exhaustion if large or recursive entities are processed.
General mitigation guidance
Effective mitigation focuses on hardening XML parsing behavior and reducing trust in incoming XML data:
- Configure XML factories and parsers to disable DTDs, external entities, and any non-essential entity resolution features by default.
- Apply strict parser features and limits (e.g., maximum entity expansion, request timeouts, and resource limits) to reduce attack surface.
- Design Netty pipelines so that components handling XML are only exposed to input that has been validated against a known schema or format.
- Isolate XML processing from high-privilege contexts and avoid running parsers with access to sensitive file systems or unrestricted internal network connectivity.
- Favor data formats and parsing libraries that provide secure-by-default configurations when XML features are not required.
Effective mitigation focuses on hardening XML parsing behavior and reducing trust in incoming XML data:
- Configure XML factories and parsers to disable DTDs, external entities, and any non-essential entity resolution features by default.
- Apply strict parser features and limits (e.g., maximum entity expansion, request timeouts, and resource limits) to reduce attack surface.
- Design Netty pipelines so that components handling XML are only exposed to input that has been validated against a known schema or format.
- Isolate XML processing from high-privilege contexts and avoid running parsers with access to sensitive file systems or unrestricted internal network connectivity.
- Favor data formats and parsing libraries that provide secure-by-default configurations when XML features are not required.
How teams detect issues like this
XXE-related weaknesses can be surfaced through a combination of code analysis and runtime monitoring:
- Static analysis rules can flag use of XML parsers,
XmlDecoder, orAsyncXMLInputFactorywhere DTDs and external entities are not explicitly disabled. - Manual code review should look for XML factory instantiation with default settings, as well as any use of DOCTYPE handling in Netty pipelines that process untrusted input.
- Security policy checks in CI/CD can enforce that all XML parsing utilities must follow a central hardened configuration profile.
- Runtime application security monitoring and penetration tests can attempt XXE payloads to confirm whether external entities are resolved or blocked.
- Automated dependency and configuration scanners may help identify high-risk XML parsing patterns or insecure defaults within Netty-based services.
XXE-related weaknesses can be surfaced through a combination of code analysis and runtime monitoring:
- Static analysis rules can flag use of XML parsers,
XmlDecoder, orAsyncXMLInputFactorywhere DTDs and external entities are not explicitly disabled. - Manual code review should look for XML factory instantiation with default settings, as well as any use of DOCTYPE handling in Netty pipelines that process untrusted input.
- Security policy checks in CI/CD can enforce that all XML parsing utilities must follow a central hardened configuration profile.
- Runtime application security monitoring and penetration tests can attempt XXE payloads to confirm whether external entities are resolved or blocked.
- Automated dependency and configuration scanners may help identify high-risk XML parsing patterns or insecure defaults within Netty-based services.
