GHSA-8cwp-4826-jg9f json
Streaming AEAD does not authenticate stream structure
published 3mo ago modified 30d ago also RUSTSEC-2026-0239
- 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
In all published versions of `dcrypt-symmetric` before 2.0.0, version-1 GCM and ChaCha20-Poly1305 streams used unauthenticated terminator, counter, and length fields. Decryptors trusted transmitted counters, allocated from unbounded lengths, and discarded plaintext that did not fit a caller's single read buffer. An attacker could obtain successful truncated EOF, omit, replay, or reorder frames within a stream, or request an allocation approaching 4 GiB.
Version 2.0.0 introduces the `DCRSTRM2` format, which authenticates its version, algorithm, random stream identifier, base nonce, strict sequence, bounded lengths, final flag, and caller AAD. It enforces authenticated finality and physical EOF, bounds frames to 16 KiB before allocation, retains partial-read plaintext, and rejects legacy version-1 input. Existing version-1 ciphertext cannot retrospectively prove completeness or ordering and must be migrated only through an application-specific, explicitly trusted process.
Patch / fix
- crates.io dcrypt-symmetric 2.0.0
Is GHSA-8cwp-4826-jg9f 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 FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | dcrypt-symmetric | >=0.0.0-0, <2.0.0 |
2.0.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.