CVE-2026-12975: Apicurio Registry XXE/SSRF via Insecure XML Parser
Apicurio Registry contains an insecure XML parser configuration that allows attackers to upload malicious XML documents. When processed, these documents can trigger outbound requests to attacker-controlled servers (SSRF), extract sensitive data from internal systems, or exhaust server resources through entity expansion attacks. The vulnerability requires write access to upload artifacts, though default configurations may not enforce authentication.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 8.5 HIGH · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:H
- Weaknesses (CWE)
- CWE-611
- Affected products
- 1 configuration(s)
- Published / Modified
- 2026-06-25 / 2026-07-15
NVD description (verbatim)
A flaw was found in Apicurio Registry. The ContentTypeUtil.isParsableXml() method creates a SAXParserFactory without enabling secure processing features or disabling external entity resolution. An attacker with artifact-write permission (or unauthenticated when the registry runs with default configuration) can upload a crafted XML document to trigger blind server-side request forgery (SSRF) via external DTD/entity fetch, or cause denial of service via entity expansion.
5 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
The ContentTypeUtil.isParsableXml() method instantiates a SAXParserFactory without disabling XXE (XML External Entity) protection or external entity resolution. This allows attackers to craft XML payloads containing external DTD declarations or entity definitions. When the registry processes uploaded artifacts to determine content type, the parser resolves these external references, enabling blind SSRF attacks against internal network resources or denial of service via billion laughs-style entity expansion. The vulnerability is classified as CWE-611 (Improper Restriction of XML External Entity Reference).
Business impact
An attacker with artifact upload permissions can exfiltrate data from internal systems, scan the registry's network segment, or crash the registry service. Organizations relying on Apicurio Registry for API schema management face potential data exposure and operational disruption. If the registry authenticates users via SSO or internal credentials, attackers may leverage SSRF to pivot to downstream systems. Denial of service attacks could disrupt artifact management workflows for teams dependent on schema lookups.
Affected systems
Red Hat Build of Apicurio Registry is affected. The vulnerability applies to any deployment where the registry processes user-supplied XML artifacts or detects content types via the vulnerable parser. Default configurations that permit unauthenticated artifact uploads face immediate risk; hardened deployments with strict write access control reduce exposure but remain vulnerable if any authenticated user is compromised.
Exploitability
Exploitability is straightforward: an attacker uploads a specially crafted XML document containing an external entity declaration pointing to an internal IP, service endpoint, or attacker infrastructure. The parser resolves the reference during content-type detection without user interaction required. No special privileges beyond artifact-write permission are necessary. The CVSS vector reflects this accessibility (CVSS:3.1/AV:N/AC:L/PR:L), though unauthenticated exploitability in default setups would elevate practical risk. No public exploit code or active KEV listing currently exists.
Remediation
Disable external entity resolution and external DTD processing in SAXParserFactory configuration. Apply the security manager attributes: XMLConstants.ACCESS_EXTERNAL_DTD set to empty string and XMLConstants.ACCESS_EXTERNAL_SCHEMA set to empty string. Additionally, disable entity expansion limits. Verify the fix by confirming that benign XML uploads still work while malicious payloads fail silently or with controlled exceptions. Consult Red Hat security advisories for specific patched versions and deployment guidance.
Patch guidance
Monitor Red Hat security advisories for patched versions of Apicurio Registry. When updates are released, test in a staging environment before production deployment to ensure artifact compatibility and parser behavior. If the registry is containerized, rebuild images with the patched version. For air-gapped environments, validate patch availability before committing to update schedules. Verify against vendor documentation that the patched version includes XXE mitigations.
Detection guidance
Monitor artifact upload requests for XML payloads containing DOCTYPE declarations, ENTITY definitions, or external schema/DTD references. Log and alert on any outbound DNS queries or HTTP requests initiated during artifact upload or content-type detection. Review registry logs for parsing errors or exceptions during file processing, which may indicate XXE attempts. Network-level detection: inspect egress traffic from the registry for unexpected connections to internal services or external domains during artifact operations. Implement content-type validation on the client side to reject suspicious payloads before upload.
Why prioritize this
This vulnerability scores CVSS 8.5 (HIGH) and poses immediate risk in multi-user or internet-facing deployments. The combination of network accessibility, low attack complexity, and high availability impact makes it a priority for patching. Organizations with default-auth Apicurio Registry instances or those managing sensitive schemas should treat this as urgent. The lack of KEV listing does not diminish risk; the vulnerability is conceptually simple and likely to attract researcher attention.
Risk score, explained
CVSS 8.5 reflects network-accessible attack surface (AV:N), minimal complexity (AC:L), and requirement for authenticated artifact-write privilege (PR:L). The scope change (S:C) indicates the attacker can affect resources beyond the registry itself via SSRF. Confidentiality impact (C:L) accounts for data exfiltration via blind SSRF; integrity is unaffected (I:N); availability impact is high (A:H) due to entity expansion denial of service. The score appropriately captures the threat: moderate authentication barrier, straightforward exploitation, and severe operational consequences.
Frequently asked questions
Can this vulnerability be exploited without uploading an artifact?
No. An attacker must have write permission to upload an artifact, or the registry must permit unauthenticated uploads (as in some default configurations). The vulnerability is triggered during content-type detection of uploaded files, not during normal artifact retrieval or query operations.
What is blind SSRF in this context, and why does it matter?
Blind SSRF means the attacker cannot directly read responses from the internal server contacted via the XML external entity. However, the attacker can still infer success or failure through timing, error messages, or side effects (e.g., internal service logs, internal DNS resolution failures). This enables port scanning, service enumeration, and potential credential theft if responses are logged or cached.
If our Apicurio Registry requires authentication, are we safe?
Not necessarily. If any legitimate user account is compromised or an insider has malicious intent, they can exploit this vulnerability to attack internal systems. Additionally, some authentication integrations may have flaws that allow bypass. Patching remains essential; authentication is a control layer, not a solution.
Does this affect schema validation or only content-type detection?
The vulnerability lies specifically in the ContentTypeUtil.isParsableXml() method used for content-type detection. However, if other parts of the codebase use similarly misconfigured parsers for schema validation or processing, those paths may be vulnerable as well. Review all XML parsing code in Apicurio Registry when patching.
This analysis is based on published vulnerability data and CVSS scoring as of the knowledge cutoff. Patch version numbers, advisory URLs, and KEV status should be verified against official Red Hat security channels and the National Vulnerability Database. No exploit code or weaponized proof-of-concept is provided. Organizations should conduct their own risk assessment based on deployment topology, authentication configuration, and network segmentation. This information is provided for educational and defensive security purposes only. Source: NVD (public-domain), retrieved 2026-08-04. Analysis generated by SEC.co (claude-haiku-4-5).
Related vulnerabilities
- CVE-2026-13449HIGHIBM Business Automation Manager XXE Vulnerability (CVSS 7.6 HIGH)
- CVE-2026-40998HIGHSpring Web Services XXE via Jaxp13XPathTemplate – Patch Guidance
- CVE-2026-44020HIGHXXE Vulnerability in Docling USPTO Patent Parser
- CVE-2026-47960HIGHColdFusion XXE Vulnerability Allows Arbitrary File Read
- CVE-2025-58175MEDIUMGeoServer SSRF Vulnerability in Proxy Configuration
- CVE-2026-12788MEDIUMXXE Vulnerability in zhilink ADP Platform 1.0.0 – Authentication Required
- CVE-2026-40991MEDIUMSpring REST Docs XXE Injection in Remote API Documentation
- CVE-2026-44018MEDIUMDocling METS-GBS XML Parsing Vulnerability (v2.45-2.90)