This release fixes ANT-2026-88EWBS43, a security vulnerability.
Submissions were deduplicated by looking them up in a SQLite database using a 128-bit key. If a match is found in the deduplication cache, Sunlight signs an SCT over the stored (old) timestamp and index, and the submitted (pre-)certificate.
With 128-bit keys, an attacker could compute a collision offline in 2⁶⁴ work (costing in the order of tens of thousands of dollars), submit a honest certificate, and then obtain an SCT for the colliding certificate, without the latter making it into the log.
In the WebPKI, this would require a colluding, compromised, or separately vulnerable CA, because the TLS BRs require unpredictable entropy in the serial number, making it impossible to compute the collision offline.
Starting in Sunlight v0.8.1 (this release), entries are added to the cache using a 256-bit key.
Existing 128-bit keys are still queried, to avoid a wave of cache misses when upgrading from v0.8.0 (or earlier) to v0.8.1 (or later). This is relatively safe because a collision attack requires control over both entries. Either the attack was executed in the past, in which case the attacker already obtained a forged SCT, or the existing 128-bit keys are honest. With approximately 2³² entries in the cache, a multi-target second preimage attack would require 2⁹⁶ work (taking in the order of a couple years with the same energy consumption as the whole Bitcoin network).
For extra safety, operators can optionally run the new recompute-cache command to rebuild the cache from the backend storage. Once recompute-cache has completed, run
sqlite3 cache.db "ALTER TABLE cache RENAME TO cache_legacy;"
to disable the fallback. This is safe to run concurrently with the log. (Do not use DROP as that would be a long write transaction, blocking the sequencer.)
This vulnerability was discovered by Claude, Anthropic's AI assistant, and triaged by the Anthropic security team in collaboration with Anthropic Research.