EUVD-2026-24509
GHSA-7jrq-q4pq-rhm6
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable TLS endpoint requires no privileges to trigger; only availability impact as legitimate mTLS connections are consistently rejected.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
7DescriptionGitHub Advisory
Oxia is a metadata store and coordination system. Prior to 0.16.2, the trustedCertPool() function in the TLS configuration only parses the first PEM block from CA certificate files. When a CA bundle contains multiple certificates (e.g., intermediate + root CA), only the first certificate is loaded. This silently breaks certificate chain validation for mTLS. This vulnerability is fixed in 0.16.2.
AnalysisAI
Incomplete PEM parsing in Oxia's TLS subsystem silently drops all but the first certificate from CA bundle files, breaking mutual TLS chain validation in all Oxia deployments prior to 0.16.2 that use the trustedCaFile option with a multi-certificate bundle. Legitimate clients presenting certificates signed by an intermediate CA are rejected with x509: certificate signed by unknown authority, creating operator pressure to disable client certificate verification entirely - degrading the mTLS security posture rather than enabling direct exploitation. No active exploitation is confirmed (not in CISA KEV), and EPSS is 0.02% (6th percentile), but the indirect risk of operators weakening authentication to restore connectivity is the primary concern.
Technical ContextAI
Oxia is a Go-based metadata store and coordination system (CPE: cpe:2.3:a:oxia-db:oxia). The defect is in common/security/tls.go within the trustedCertPool() function, which calls Go's pem.Decode() only once against the CA certificate file buffer. Standard PEM bundles - which concatenate an intermediate CA certificate followed by a root CA certificate - contain multiple PEM blocks, but the single pem.Decode() call consumes only the first block and silently discards the remaining bytes. The function also ignores the error return from pem.Decode(), meaning a corrupted or empty CA file produces an empty certificate pool with no diagnostic output. This is classified under CWE-295 (Improper Certificate Validation) - specifically, incomplete certificate chain construction during TLS handshake that prevents verification of client certificates signed by intermediate authorities.
RemediationAI
Upgrade to Oxia 0.16.2, which resolves the issue by iterating over all PEM blocks in the CA file, parsing each CERTIFICATE block, and returning an error when no valid certificates are found - ensuring corrupted or empty CA files are surfaced rather than silently ignored. See the authoritative advisory at https://github.com/oxia-db/oxia/security/advisories/GHSA-7jrq-q4pq-rhm6. For environments unable to upgrade immediately, the confirmed workaround is to configure trustedCaFile with a CA file containing only a single certificate - specifically the direct issuer of client certificates rather than a full chain bundle. The trade-off is reduced PKI flexibility: client certificates must be issued directly by the configured single CA, which may require re-issuing existing certificates and limits the ability to use a standard intermediate-plus-root CA hierarchy.
Authentication bypass in Oxia (oxia-db) metadata store and coordination system prior to 0.16.2 allows an attacker holdin
Sensitive information disclosure in Oxia (a metadata store and coordination system) prior to 0.16.2 causes the full OIDC
Denial-of-service in Oxia (metadata store and coordination system) versions <= 0.16.1 allows a remote unauthenticated cl
Same weakness CWE-295 – Improper Certificate Validation
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Moderate| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today