Every CVESearch/Get API key

ANT-2026-9AY5SJ8K

Unauthenticated TLS records can exhaust memory or CPU during a handshake

No scoreFix available

Reseau 1.1.0 through 1.3.1 contain two resource-exhaustion conditions in the native TLS 1.2 and TLS 1.3 record layers. An unauthenticated network peer can send records that consume memory without a bound or keep a handshake task processing non-progressing input.

Impact

A peer can retain approximately 16 KiB of plaintext per record until the process exhausts memory, or stream empty handshake records to keep a connection task consuming CPU. Multiple connections can amplify either condition and impair service availability.

Technical details

This advisory consolidates two handshake-time input-validation defects:

  1. After obtaining handshake traffic keys but before completing the handshake, a peer could send application-data records. The record layers appended the decrypted bytes to an unbounded plaintext buffer instead of rejecting the record. Because each record was nonempty, it also reset the useless-record counter.
  2. Zero-length handshake records produced no handshake bytes but were not rejected or charged against the useless-record limit. The handshake reader could therefore loop forever while continuing to receive non-progressing records.

Both defects were introduced with Reseau's native TLS stack in version 1.1.0. Releases 1.0.x used the previous OpenSSL TLS engine and are not affected.

Patches

Upgrade to Reseau 1.3.2 or later. The fixed record layers reject both application data received before handshake completion and empty handshake records with a fatal unexpected_message alert.

Workarounds

There is no complete in-process workaround. Set a finite handshake_timeout_ns and enforce connection rate and concurrency limits to bound each handshake's duration and reduce repeated attacks; an attacker can still consume substantial resources within that window. Terminating TLS in a patched proxy before forwarding traffic to a vulnerable Reseau service avoids the vulnerable record parser.

Reported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.

What each source reports

OSVJLSEC-2026-799No score

Unauthenticated TLS records can exhaust memory or CPU during a handshake

Reseau 1.1.0 through 1.3.1 contain two resource-exhaustion conditions in the native TLS 1.2 and TLS 1.3 record layers. An unauthenticated network peer can send records that consume memory without a bound or keep a handshake task processing non-progressing input.

Impact

A peer can retain approximately 16 KiB of plaintext per record until the process exhausts memory, or stream empty handshake records to keep a connection task consuming CPU. Multiple connections can amplify either condition and impair service availability.

Technical details

This advisory consolidates two handshake-time input-validation defects:

  1. After obtaining handshake traffic keys but before completing the handshake, a peer could send application-data records. The record layers appended the decrypted bytes to an unbounded plaintext buffer instead of rejecting the record. Because each record was nonempty, it also reset the useless-record counter.
  2. Zero-length handshake records produced no handshake bytes but were not rejected or charged against the useless-record limit. The handshake reader could therefore loop forever while continuing to receive non-progressing records.

Both defects were introduced with Reseau's native TLS stack in version 1.1.0. Releases 1.0.x used the previous OpenSSL TLS engine and are not affected.

Patches

Upgrade to Reseau 1.3.2 or later. The fixed record layers reject both application data received before handshake completion and empty handshake records with a fatal unexpected_message alert.

Workarounds

There is no complete in-process workaround. Set a finite handshake_timeout_ns and enforce connection rate and concurrency limits to bound each handshake's duration and reduce repeated attacks; an attacker can still consume substantial resources within that window. Terminating TLS in a patched proxy before forwarding traffic to a vulnerable Reseau service avoids the vulnerable record parser.

Reported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.

Record
JLSEC-2026-799
Updated
2026-11-02

Affected packages

Affected packages
PackageAffectedFixed
Reseau
Julia
1.1.0 up to 1.3.2
1.3.2

History

History
RecordedChangedSources
first indexedOSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

ANT-2026-9AY5SJ8K is a vulnerability with no CVSS score yet in Reseau, published July 28, 2026. No source lists public exploit code. Fixed in Reseau 1.3.2.

References

MoveEnter Open