| # OpenSSL Advisory: September 29, 2026 | |
| OpenSSL have published a [security advisory](https://openssl-library.org/news/secadv/20260929.txt). 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](https://boringssl-review.googlesource.com/c/boringssl/+/8433) 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](https://boringssl-review.googlesource.com/c/boringssl/+/23075) | |
| 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 | |
| [Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity | |
| ## CVE-2026-35189 | |
| BoringSSL is impacted by this issue. Impacted callers should update to [9b639f5b3b086508c03f6a4a1792e4a6043777ac](https://boringssl.googlesource.com/boringssl/+/9b639f5b3b086508c03f6a4a1792e4a6043777ac) or later. This change is included in release [0.20260929.0](https://boringssl.googlesource.com/boringssl/+/refs/tags/0.20260929.0) ([BCR](https://registry.bazel.build/modules/boringssl/0.20260929.0)) 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](https://en.wikipedia.org/wiki/X.500) and supports a wide range of now unused CRL distribution point formats. This particular one was discouraged by [RFC 5280](https://www.rfc-editor.org/info/rfc5280/) 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"](https://crbug.com/443261873). A single certificate can have multiple distribution points, so this can can trigger quadratically-scaled memory allocation when [cached extensions](https://crbug.com/443261873) 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](https://crbug.com/42290571), 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: | |
| * Verify server certificates as a TLS client. | |
| * Request and verify client certificates as a TLS server. | |
| * Use `X509_verify_cert`. | |
| Callers are also impacted if they use any of the following symbols: | |
| * `X509_get_extension_flags` | |
| * `X509_get_key_usage` | |
| * `X509_get_extended_key_usage` | |
| * `X509_get0_subject_key_id` | |
| * `X509_get0_authority_key_id` | |
| * `X509_get0_authority_issuer` | |
| * `X509_get0_authority_serial` | |
| * `X509_get_pathlen` | |
| * `X509_cmp` | |
| * `CMS_USE_KEYID` | |
| * `PKCS7_sign` | |
| * `X509_check_purpose` | |
| * `X509_check_ca` | |
| * `X509_check_issued` | |
| * `X509_check_trust` | |
| Callers that meet the above criteria and who are sensitive to DoS should update to a fixed version of BoringSSL. |