Severity by source
AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:H
Default config permits anonymous artifact upload so PR:N; low-complexity remote XXE with scope change to other systems via blind SSRF (C:L) and high-impact entity-expansion DoS (A:H).
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
Lifecycle Timeline
1DescriptionCVE.org
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.
AnalysisAI
Server-side request forgery and denial of service in Red Hat Build of Apicurio Registry 3 stem from unsafe XML parsing in the ContentTypeUtil.isParsableXml() method, which builds a SAXParserFactory without secure processing or external-entity restrictions (CWE-611, XXE). An attacker with artifact-write permission - or any unauthenticated client when the registry runs in its default configuration - can upload a crafted XML artifact whose external DTD/entity references force the server to fetch attacker-chosen URLs (blind SSRF into internal networks) or expand nested entities for resource-exhaustion DoS. CVSS is 8.5 (scope-changed, high availability impact); no public exploit identified at time of analysis.
Technical ContextAI
Apicurio Registry is a schema/API artifact registry (Avro, Protobuf, JSON Schema, OpenAPI, WSDL/XML) widely used to govern Kafka and event-driven pipelines. The flaw is a classic XML External Entity (XXE) issue, CWE-611: when content arrives, isParsableXml() instantiates a JAXP SAXParserFactory to test whether the payload is XML, but never sets FEATURE_SECURE_PROCESSING, disallow-doctype-decl, or the external-general-entities / external-parameter-entities features to false. As a result the underlying SAX parser resolves DOCTYPE declarations and external DTD/entity references during the parse, so a document containing a SYSTEM identifier (an external DTD or parameter entity pointing at http://internal-host/, file:///, or ftp/gopher URLs) causes the JVM to perform an outbound fetch on the server's behalf - the SSRF primitive - while deeply nested or recursive entity definitions drive CPU/memory exhaustion (entity-expansion / billion-laughs style) for the DoS primitive.
RemediationAI
No vendor-released patch version is identified in the provided data; monitor the Red Hat advisory (https://access.redhat.com/security/cve/CVE-2026-12975) and Bugzilla 2491688 (https://bugzilla.redhat.com/show_bug.cgi?id=2491688) for the fixed Apicurio Registry 3 build and apply it as the primary remediation once published. Until then, apply concrete compensating controls: enable authentication and require artifact-write authorization rather than running the registry in its default anonymous-write configuration - this removes the unauthenticated exploitation path at the cost of needing identity/RBAC setup for clients; apply network egress filtering so the registry host cannot make arbitrary outbound connections (block outbound HTTP/FTP/gopher and restrict DNS), which neutralizes the SSRF fetch but may break legitimate remote schema-reference resolution; and put the registry behind a reverse proxy or WAF that rejects XML payloads containing DOCTYPE/ENTITY declarations to blunt both XXE-SSRF and entity-expansion DoS, accepting that strict XML filtering can reject otherwise-valid XSD/WSDL artifacts. Network-segment the registry so SSRF cannot reach sensitive internal endpoints such as cloud metadata services or internal admin APIs.
Vendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-39574
GHSA-7g64-f2hm-vjxp