OpenSSL have published a security advisory. Here's how it affects BoringSSL:
| CVE | Summary | Severity in OpenSSL | Impact to BoringSSL |
|---|---|---|---|
| CVE-2026-84782 | DTLS Retransmits Handshake Messages From a Stale Buffer Offset | High | Not affected, BoringSSL fixed this in 2016 as part of independent cleanup |
| CVE-2026-84783 | Use-After-Free in X.509 Extension Cache Under Concurrent Use | Moderate | Not affected, issue was introduced after fork |
| CVE-2026-35189 | Excessive Memory Allocation in Relative CRLDP Processing | Low | Affected, see discussion below |
| CVE-2026-35191 | QUIC Unvalidated Amplification Credit may be Over Accounted | Low | Not affected, issue was introduced after fork |
| CVE-2026-42772 | Potential CPU DoS via O(n^2) Fragment Reassembly in QUIC | Low | Not affected, issue was introduced after fork |
| CVE-2026-54872 | Timing Side-Channel in Scalar Multiplication for Non-NIST EC Curves | Low | Not affected, BoringSSL independently fixed this in 2017 |
| CVE-2026-54873 | QUIC STREAM Fragment Metadata DoS | Low | Not affected, issue was introduced after fork |
| CVE-2026-54875 | Non-Constant-Time SM2 Scalar Multiplication on ARM64 and RISC-V | Low | Not affected, issue was introduced after fork |
| CVE-2026-72897 | Out-of-Bounds Access After SSL_set_SSL_CTX() During a Handshake | Low | Not affected, issue was introduced after fork |
| CVE-2026-75804 | QUIC Connection-Level Flow Control is Not Enforced for Streams | Low | Not affected, issue was introduced after fork |
| CVE-2026-75805 | NULL Pointer Dereference in CMP Client Revocation Response Handling | Low | Not affected, issue was introduced after fork |
| CVE-2026-75806 | Unauthenticated and Undersized DTLS 1.2 AEAD Record Causes DoS | Low | Not affected, issue was introduced after fork |
| CVE-2026-77696 | Timing Side-Channel in SM2 Signature Generation | Low | Not affected, issue was introduced after fork |
| CVE-2026-84784 | QUIC: Unbounded RETIRE_CONNECTION_ID Backlog | Low | Not affected, issue was introduced after fork |
BoringSSL is impacted by this issue. Impacted callers should update to 9b639f5b3b086508c03f6a4a1792e4a6043777ac or later. This change is included in release 0.20260929.0 (BCR) or later.
The bug is triggered by the obscure nameRelativeToCRLIssuer feature in X.509 CRL distribution points. While CRL distribution points are typically URLs, X.509 was originally designed to provide a directory service and supports a wide range of now unused CRL distribution point formats. This particular one was discouraged by RFC 5280 in 2008:
Conforming CAs SHOULD NOT use nameRelativeToCRLIssuer to specify distribution point names.
OpenSSL's nameRelativeToCRLIssuer eagerly computed the absolute distribution point name when the implementation computes “cached extensions”. A single certificate can have multiple distribution points, so this can can trigger quadratically-scaled memory allocation when cached extensions are filled in. This can result in a denial of service.
The fix in BoringSSL removes nameRelativeToCRLIssuer support altogether. We had independently planned to remove this feature, but had not yet done so. Distribution points that use nameRelativeToCRLIssuer will be ignored.
The issue only triggers when cached extensions are computed, so not all callers that construct X509 objects are impacted. Cached extensions are primarily computed during certificate verification. This impacts callers that:
X509_verify_cert.Callers are also impacted if they use any of the following symbols:
X509_get_extension_flagsX509_get_key_usageX509_get_extended_key_usageX509_get0_subject_key_idX509_get0_authority_key_idX509_get0_authority_issuerX509_get0_authority_serialX509_get_pathlenX509_cmpCMS_USE_KEYIDPKCS7_signX509_check_purposeX509_check_caX509_check_issuedX509_check_trustCallers that meet the above criteria and who are sensitive to DoS should update to a fixed version of BoringSSL.