---
id: RUSTSEC-2026-0337
aliases:
  - GHSA-xr22-8pqp-gwfh
title: >-
  Poly1305 panics or computes a wrong tag on attacker-chosen messages of 64
  bytes or more
summary: >-
  Poly1305 panics or computes a wrong tag on attacker-chosen messages of 64
  bytes or more
severity: high
cvss: 7.5
cvssVector: 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'
vendor: ic-cipher
product: ic-cipher
ecosystem: rust
affected:
  - 'ic-cipher >= 0.2.5, < 0.2.20'
patched:
  - ic-cipher 0.2.20
published: '2026-10-09'
updated: '2026-10-12'
sourceUpdated: '2026-10-12T18:15:01.974078373Z'
source: OSV
sourceUrl: 'https://osv.dev/vulnerability/RUSTSEC-2026-0337'
references:
  - url: 'https://crates.io/crates/ic-cipher'
  - url: 'https://rustsec.org/advisories/RUSTSEC-2026-0337.html'
  - url: >-
      https://github.com/nervosys/IronCrypto/commit/a8160a18b5c66288f05dc62f5ea2159c687b9416
tags:
  - osv
  - rust
ingestedAt: '2026-10-13T11:45:30.199Z'
---

## Overview

`Poly1305` 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 under
  `panic = "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 packages

- `ic-cipher >= 0.2.5, < 0.2.20`

## Remediation

Upgrade to a patched release:

- `ic-cipher 0.2.20`