docs/advisories/2026-08-13.md - boringssl - Git at Google

 # OpenSSL Advisory: August 13th, 2026 (BoringSSL Not Affected)

 OpenSSL have published a [security advisory](https://openssl-library.org/news/secadv/20260813.txt). 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

 [Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity

 Separate from the advisory, OpenSSL [published a discussion](https://openssl-library.org/post/2026-07-21-hollowbyte/) in July on a DoS report named "HollowByte". This is discussed below.

 ## HollowByte

 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:

 1. allocate the buffer for the whole message as soon as it is known, or
 2. allocate the buffer incrementally as data is received

 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](https://en.wikipedia.org/wiki/Slowloris_%28cyber_attack%29) 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](https://boringssl.googlesource.com/boringssl/+/40e94701dcbb37fb83f7368d9964f1ebdae7ffce) that switched to the second strategy in our TLS implementation.

 DTLS has a [similar issue](https://github.com/openssl/openssl/issues/32078), not yet addressed upstream. On August 12th, we implemented a new strategy to [defer allocating the full-sized DTLS message](https://boringssl.googlesource.com/boringssl/+/7017746ef9f887c9005f035d9bd88974d53fd48f) to align with our TLS behavior.
	# OpenSSL Advisory: August 13th, 2026 (BoringSSL Not Affected)

	OpenSSL have published a [security advisory](https://openssl-library.org/news/secadv/20260813.txt). 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

	[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity

	Separate from the advisory, OpenSSL [published a discussion](https://openssl-library.org/post/2026-07-21-hollowbyte/) in July on a DoS report named "HollowByte". This is discussed below.

	## HollowByte

	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:

	1. allocate the buffer for the whole message as soon as it is known, or
	2. allocate the buffer incrementally as data is received

	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](https://en.wikipedia.org/wiki/Slowloris_%28cyber_attack%29) 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](https://boringssl.googlesource.com/boringssl/+/40e94701dcbb37fb83f7368d9964f1ebdae7ffce) that switched to the second strategy in our TLS implementation.

	DTLS has a [similar issue](https://github.com/openssl/openssl/issues/32078), not yet addressed upstream. On August 12th, we implemented a new strategy to [defer allocating the full-sized DTLS message](https://boringssl.googlesource.com/boringssl/+/7017746ef9f887c9005f035d9bd88974d53fd48f) to align with our TLS behavior.