https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 10 Oct 2026 12:03:41 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-292393 EUVD-2026-292393 https://cve.radiocsirt.org/vuln/euvd-2026-292393 https://cve.radiocsirt.org/vuln/fkie_cve-2026-40944 <p>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.</p> <p>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.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-40944 https://cve.radiocsirt.org/vuln/ghsa-7jrq-q4pq-rhm6 <p><strong>Affected:</strong> Go: github.com/oxia-db/oxia</p> <p>### Summary 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.</p> <p>### Impact In deployments using mTLS with certificate chains (intermediate CA + root CA bundles), legitimate clients with properly chained certificates are rejected with `x509: certificate signed by unknown authority`. This degrades the security posture by making mTLS unusable with standard CA chain configurations, potentially forcing operators to disable client certificate verification.</p> <p>All versions using TLS with `trustedCaFile` configuration are affected.</p> <p>### Details In `common/security/tls.go`, the `trustedCertPool()` method calls `pem.Decode()` only once, processing a single PEM block. The remaining bytes (containing additional certificates) are silently discarded. Additionally, the error return from `pem.Decode` is ignored, so a corrupted CA file results in an empty certificate pool without any error.</p> <p>### Patches Fixed by iterating over all PEM blocks in the file, parsing each CERTIFICATE block, and returning an error if no valid certificates are found.</p> <p>### Workarounds Use CA files containing only a single certificate (the direct issuer of client certificates, not a chain).</p> <p><strong>Affected:</strong> Go: github.com/oxia-db/oxia</p> <p>### Summary 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.</p> <p>### Impact In deployments using mTLS with certificate chains (intermediate CA + root CA bundles), legitimate clients with properly chained certificates are rejected with `x509: certificate signed by unknown authority`. This degrades the security posture by making mTLS unusable with standard CA chain configurations, potentially forcing operators to disable client certificate verification.</p> <p>All versions using TLS with `trustedCaFile` configuration are affected.</p> <p>### Details In `common/security/tls.go`, the `trustedCertPool()` method calls `pem.Decode()` only once, processing a single PEM block. The remaining bytes (containing additional certificates) are silently discarded. Additionally, the error return from `pem.Decode` is ignored, so a corrupted CA file results in an empty certificate pool without any error.</p> <p>### Patches Fixed by iterating over all PEM blocks in the file, parsing each CERTIFICATE block, and returning an error if no valid certificates are found.</p> <p>### Workarounds Use CA files containing only a single certificate (the direct issuer of client certificates, not a chain).</p> https://cve.radiocsirt.org/vuln/ghsa-7jrq-q4pq-rhm6