Summary
CVE-2026-57826 is a critical improper certificate validation flaw (CWE-295) in openHiTLS, an open-source cryptographic library. During X.509 certificate chain verification, the library only enforces the basicConstraints extension and CA flag check on intermediate CA certificates that use the X.509 v3 format — v1 and v2 intermediate certificates are silently skipped, allowing them to be treated as valid CAs regardless of their actual constraints. With a CVSS v3.1 score of 9.8 (Critical) and no authentication or user interaction required, this flaw can enable full compromise of TLS/PKI trust decisions in any application relying on openHiTLS for certificate chain validation.
Technical details
- Root cause: In
X509_CheckExt()(pki/x509_verify/src/hitls_x509_verify.c), the code path that validates whether an intermediate certificate in the chain is properly marked as a CA (via thebasicConstraintsextension andcAboolean) was only executed when the certificate’s version field equaled X.509 v3. Certificates encoded as v1 or v2 bypassed this check entirely, per RFC 5280 §6.1.4(k), which requires implementations to either verify v1/v2 CA status via out-of-band means or reject such certificates outright — openHiTLS did neither. - Related root cause: A companion check in
HITLS_X509_CheckCertExt()also skipped extension processing for any certificate whose version was not v3 (cert->tbs.version != 2), rather than rejecting non-v3 certificates that improperly carry extensions. - Trigger conditions: An attacker who can supply or influence a certificate chain presented during TLS handshake or other X.509-based verification (e.g., a malicious or crafted intermediate certificate encoded as v1/v2) can have that certificate accepted as a valid intermediate CA without a
basicConstraints/cA=TRUEassertion. - Attack vector: Network (AV:N) — exploitable remotely wherever openHiTLS performs certificate chain validation, such as during TLS client/server authentication.
- Impact: An attacker can forge or leverage a non-v3 certificate to impersonate a trusted intermediate CA, enabling issuance of fraudulent leaf certificates that openHiTLS will treat as validly chained to a trusted root. This can lead to man-in-the-middle attacks, spoofing of trusted endpoints, and complete compromise of confidentiality, integrity, and availability for any system relying on openHiTLS’s X.509 verification for trust decisions.
Affected software
- openHiTLS versions 0.2.0 through 0.3.2 (inclusive)
Severity
- CVSS v3.1 Base Score: 9.8 (Critical)
- Vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Mitigation and recommended actions
- Immediate: Upgrade to openHiTLS 0.3.3 or later, which fixes this issue by enforcing that intermediate CA certificates must be X.509 v3 with a valid
basicConstraintsextension assertingcA=TRUE, and rejects v1/v2 certificates as intermediate CAs (per RFC 5280 §6.1.4(k)). The fix also rejects v1/v2 certificates that improperly carry X.509 extensions. - If immediate patching is not possible:
- Restrict trusted CA stores to well-formed v3 certificate chains and avoid accepting v1/v2 certificates as intermediate CAs from untrusted or external sources.
- Where feasible, enforce out-of-band verification of CA status for any v1/v2 certificates that must be accepted, as recommended by RFC 5280.
- Audit systems and applications embedding openHiTLS for TLS/X.509 verification to confirm patched versions are deployed, prioritizing internet-facing services performing peer certificate validation.