Keypoints
- The xml-security-c library (Apache Santuario) dereferences external URIs in XML Signatures by default, causing SSRF risks.
- There is no configuration-only option to disable URI resolution in xml-security-c; mitigation requires code changes or recompiling a patched library.
- A crafted XML Signature Reference element (e.g., URI=”http://www.example.com/ssrf”) forces the parser to make outbound HTTP requests in affected versions (≤ 2.0.4).
- Some projects (e.g., Shibboleth xmltooling) mitigated by overriding the default URI resolver with a no-op implementation, but this must be applied wherever xml-security-c is used.
- Mandiant produced a patch that replaces the default resolver (XSECURIResolverXerces) with a no-op resolver (XSECURIResolverNoop); recompilation is required to apply it.
- Apache did not issue a CVE or release a fixed version; instead they added a disclaimer and recommend moving away from using xml-security-c standalone.
- Recommended actions: scan C++ codebases for xml-security-c usage, apply setDefaultURIResolver with a custom no-op resolver where possible, or apply and recompile the provided patch to make the library secure by default.
MITRE Techniques
- [T1190] Exploit Public-Facing Application – The library’s default behavior allows crafted XML Signatures to force server HTTP requests, enabling SSRF: [“By default, the library resolves references to external URIs passed in Extensible Markup Language (XML) signatures, allowing for server-side request forgery (SSRF).”]
Indicators of Compromise
- [URL] example SSRF trigger – http://www.example.com/ssrf (used in sample XML Reference URI to trigger outbound request)
- [Library / Class Names] affected components – xml-security-c, XSECProvider, XSECURIResolverXerces, XSECURIResolverNoop
- [CVE] related disclosures – CVE-2024-21893 (Ivanti), CVE-2023-36661 (Shibboleth/xmltooling)
- [Source] advisory post – https://cloud.google.com/blog/topics/threat-intelligence/apache-library-allows-server-side-request-forgery/
Rewritten technical summary:
The xml-security-c library (Apache Santuario) automatically dereferences Reference URIs found in XML Signature elements, which permits server-side request forgery when untrusted XML is parsed. A minimal exploit example uses a ds:Reference with URI=”http://www.example.com/ssrf” to force the library to make an outbound HTTP request; affected xml-security-c versions (including 2.0.4 and earlier) perform this resolution by default.
To mitigate without rebuilding the library, locate every use of XSECProvider in your code and call setDefaultURIResolver with a custom XSECURIResolver implementation that performs no network operations (a no-op resolver). This preserves the stock library binary while preventing SSRF. The superior mitigation is to apply a source patch that replaces the default XSECURIResolverXerces with XSECURIResolverNoop and recompile xml-security-c; this makes URI resolution safe-by-default but requires rebuilding and, for legitimate external-URI use cases, explicitly setting the original resolver where needed.
Action items: scan C++ projects for xml-security-c usage, apply the no-op resolver where you can pinpoint XSECProvider instances, or download and apply the Mandiant-provided patch and recompile the library to eliminate the SSRF vector. Note that Apache did not release a new secure version and recommends migrating away from standalone xml-security-c.