RUSTSEC-2026-0337 (GHSA-XR22-8PQP-GWFH)
Vulnerability from osv_rustsec – Published: 2026-10-09 12:00 – Updated: 2026-10-12 18:05 – Source websitePoly1305 in ic-cipher absorbs messages of 64 bytes or more four blocks at
a time, summing four products before one reduction. From 0.2.5 to 0.2.19 the
reduction kept its carries in 32-bit integers, which four summed products can
overflow when the message's bytes are large.
This affects Poly1305 and ChaCha20Poly1305, and everything built on them:
the TLS and QUIC ChaCha20-Poly1305 suites in ic-rustls, HPKE with that
cipher in ic-hpke, and the re-exports in ic-mac and ironcrypto.
What happens depends on how the crate was compiled:
- With overflow checks on (any debug build, or a release profile with
overflow-checks = true) the multiplication panics, and underpanic = "abort"the process ends. The tag is computed over the ciphertext before it is compared, so this happens before authentication and without the key: anyone who can deliver a ChaCha20-Poly1305 ciphertext to be opened can trigger it. - With overflow checks off (Cargo's default for release builds) the arithmetic wraps and the tag is computed wrong on the affected messages.
Ordinary data does not reach the defect. A message of 0xff bytes does: in
one measurement against 0.2.19, 28 of 500 ChaCha20Poly1305::open_detached
calls on 1,024 bytes of 0xff under random keys and nonces panicked in a
debug build. ChaCha20-Poly1305 derives a new Poly1305 key for every nonce, so
each message is a fresh attempt.
AES-GCM and AES-GCM-SIV are not affected, and neither are messages shorter than 64 bytes.
The flaw was corrected in 0.2.20 by carrying in 64 bits.
It was found by running Project Wycheproof's ChaCha20-Poly1305 test vectors against the library.
{
"affected": [
{
"database_specific": {
"categories": [
"denial-of-service",
"crypto-failure"
],
"cvss": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"informational": null
},
"ecosystem_specific": {
"affected_functions": null,
"affects": {
"arch": [],
"functions": [],
"os": []
}
},
"package": {
"ecosystem": "crates.io",
"name": "ic-cipher",
"purl": "pkg:cargo/ic-cipher"
},
"ranges": [
{
"events": [
{
"introduced": "0.2.5"
},
{
"fixed": "0.2.20"
}
],
"type": "SEMVER"
}
],
"versions": []
}
],
"aliases": [
"GHSA-xr22-8pqp-gwfh"
],
"database_specific": {
"license": "CC0-1.0"
},
"details": "`Poly1305` in `ic-cipher` absorbs messages of 64 bytes or more four blocks at\na time, summing four products before one reduction. From 0.2.5 to 0.2.19 the\nreduction kept its carries in 32-bit integers, which four summed products can\noverflow when the message\u0027s bytes are large.\n\nThis affects `Poly1305` and `ChaCha20Poly1305`, and everything built on them:\nthe TLS and QUIC ChaCha20-Poly1305 suites in `ic-rustls`, HPKE with that\ncipher in `ic-hpke`, and the re-exports in `ic-mac` and `ironcrypto`.\n\nWhat happens depends on how the crate was compiled:\n\n- With overflow checks on (any debug build, or a release profile with\n `overflow-checks = true`) the multiplication panics, and under\n `panic = \"abort\"` the process ends. The tag is computed over the ciphertext\n before it is compared, so this happens before authentication and without\n the key: anyone who can deliver a ChaCha20-Poly1305 ciphertext to be opened\n can trigger it.\n- With overflow checks off (Cargo\u0027s default for release builds) the\n arithmetic wraps and the tag is computed wrong on the affected messages.\n\nOrdinary data does not reach the defect. A message of `0xff` bytes does: in\none measurement against 0.2.19, 28 of 500 `ChaCha20Poly1305::open_detached`\ncalls on 1,024 bytes of `0xff` under random keys and nonces panicked in a\ndebug build. ChaCha20-Poly1305 derives a new Poly1305 key for every nonce, so\neach message is a fresh attempt.\n\nAES-GCM and AES-GCM-SIV are not affected, and neither are messages shorter\nthan 64 bytes.\n\nThe flaw was corrected in 0.2.20 by carrying in 64 bits.\n\nIt was found by running Project Wycheproof\u0027s ChaCha20-Poly1305 test vectors\nagainst the library.",
"id": "RUSTSEC-2026-0337",
"modified": "2026-10-12T18:05:20Z",
"published": "2026-10-09T12:00:00Z",
"references": [
{
"type": "PACKAGE",
"url": "https://crates.io/crates/ic-cipher"
},
{
"type": "ADVISORY",
"url": "https://rustsec.org/advisories/RUSTSEC-2026-0337.html"
},
{
"type": "WEB",
"url": "https://github.com/nervosys/IronCrypto/commit/a8160a18b5c66288f05dc62f5ea2159c687b9416"
}
],
"related": [],
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Poly1305 panics or computes a wrong tag on attacker-chosen messages of 64 bytes or more"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.