Skip to content
Fencer Intel
no cvss —

JLSEC-2026-622 json

Predictable WebSocket masking key and handshake nonce in HTTP.jl client

published 4mo ago modified 3mo ago

cvss
—
not scored
cisa kev
Not listed
not in CISA's catalog
epss
—
no score, EPSS covers CVEs only
public exploits
0
none known

Summary

### Description

The WebSocket client masking key (`ws_send_frame!`) and the `Sec-WebSocket-Key` handshake nonce (`ws_random_handshake_key`) were generated with `rand(UInt8, n)`, which draws from the task-local Xoshiro256++ PRNG. Xoshiro is not cryptographically secure: its internal state can be recovered from a short run of observed outputs, and every outbound client frame exposes 4 mask bytes on the wire. An on-path observer could therefore recover the RNG state and predict all future masking keys, defeating the RFC 6455 §5.3 anti-cache-poisoning purpose of masking.

### Impact

Predictable masking keys could let an on-path attacker who also supplies payload craft wire bytes that a non-conformant transparent proxy parses and caches (request/response smuggling and cache poisoning).

### Patches

Fixed in HTTP.jl v2.4.0. A module-level CSPRNG (`const WS_CSPRNG = Random.RandomDevice()`) now generates both the 4-byte masking key and the 16-byte handshake nonce. The wire format and public API are unchanged.

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

Patch / fix

  • julia HTTP 2.4.0

Is JLSEC-2026-622 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

Affected packages

ecosystem package affected fixed in
julia HTTP
<2.4.0
2.4.0

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.