Summary
Oxia's TLS CA certificate chain validation fails with multi-certificate PEM bundles
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.
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.
Workarounds
Use CA files containing only a single certificate (the direct issuer of client certificates, not a chain).
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.
All versions using TLS with trustedCaFile configuration are affected.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed by iterating over all PEM blocks in the file, parsing each CERTIFICATE block, and returning an error if no valid certificates are found.
Frequently Asked Questions
- What is CVE-2026-40944? CVE-2026-40944 is a high-severity security vulnerability in github.com/oxia-db/oxia (go), affecting versions <= 0.16.1. It is fixed in 0.16.2.
- Which versions of github.com/oxia-db/oxia are affected by CVE-2026-40944? github.com/oxia-db/oxia (go) versions <= 0.16.1 is affected.
- Is there a fix for CVE-2026-40944? Yes. CVE-2026-40944 is fixed in 0.16.2. Upgrade to this version or later.
- Is CVE-2026-40944 exploitable, and should I be worried? Whether CVE-2026-40944 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-40944 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-40944? Upgrade
github.com/oxia-db/oxiato 0.16.2 or later.