OpenSSL have published a security advisory. Here's how it affects BoringSSL:
| CVE | Summary | Severity in OpenSSL | Impact to BoringSSL |
|---|---|---|---|
| CVE-2026-14456 | Unbounded Memory Growth in QUIC Server Incoming Channel Queue | Low | Not affected, issue was introduced after fork |
Separate from the advisory, OpenSSL published a discussion in July on a DoS report named “HollowByte”. This is discussed below.
TLS handshake messages may be split across multiple records, and a receiver cannot process the message until the whole message is received. This means a TLS connection must buffer the current partial message. A TLS implementation could either:
In both cases, the memory use is bounded. TLS stacks are already expected to enforce a maximum message size as a DoS mitigation. However, the first strategy allows a small initial fragment to trigger a proportionally larger allocation on the server. This could be used as part of a Slowloris-style DoS attack where the attacker opens many connections on the target server.
This attack strategy is possible in either case. An open connection unavoidably requires some resources, and an attacker can always try to open many connections. Mitigation must ultimately happen a layer above, in connection management. For example, a serving frontend might bound the total number of connections it is willing to maintain, preferentially shed unused connections under load, or rate limit connections by client.
Still, a proportionally larger allocation can accelerate the attack. OpenSSL switched to the second strategy to mitigate this but classified it as a hardening fix.
BoringSSL is not impacted by this report. In 2017, as part of other work, we independently made a change that switched to the second strategy in our TLS implementation.
DTLS has a similar issue, not yet addressed upstream. On August 12th, we implemented a new strategy to defer allocating the full-sized DTLS message to align with our TLS behavior.