Disclosure summary
Opening a file whose first eight bytes are the OLE magic number sends excelize down the decryption path whether or not the caller set a password, or supports encrypted workbooks at all. `openReaderAt` (excelize.go:198-215) branches on the header alone, and `agileDecrypt` calls `convertPasswdToKey` before the verifier hash is checked, so the key-derivation loop runs `spinCount` times regardless. `spinCount` (crypt.go:98) is a plain `int` filled by a bare `xml.Unmarshal` of the file's own EncryptionInfo stream. Nothing bounds it. A 3072-byte file with spinCount 100000000 makes `OpenFile` take 58.65s on v2.11.0 with default options, then return `zip: not a valid zip file`. It is linear at about 0.6 microseconds per iteration and the attacker picks the number, so 1e9 is roughly ten minutes. Nothing on the path takes a `context.Context`, so the caller cannot cancel it; in an HTTP handler the write timeout returns a response while the goroutine keeps spinning. Memory stays flat at 24 MB, so nothing reclaims it either. ``` v2.5.0 spinCount=10000000 5.307s v2.9.1 spinCount=10000000 5.444s v2.11.0 spinCount=10000000 7.529s v2.11.0 spinCount=100000000 58.654s ``` The loop arrived with `crypt
Source-specific records & product guidance
Sources retain their own attribution and scoring. Follow the original record to confirm affected versions, fixed releases, and configuration conditions.
GitHub Reviewed Security Advisories · GHSA-jrfj-fhj2-jjvm
Open original source · Updated Oct 07, 2026
Excelize: Unbounded spinCount in agile decryption burns CPU during OpenFile
Source severity: HIGH / 0
| Ecosystem | Package | Affected range | First patched |
|---|---|---|---|
| go | github.com/xuri/excelize/v2 | >= 2.3.1, < 2.11.1-0.20260906004932-2badfcd5841d | 2.11.1-0.20260906004932-2badfcd5841d |
Original records & references
- NIST NVD record
- CVE Program record
- github.com — Reviewed advisory
PUBLISHED 2026-10-07T16:23:22-04:00
MODIFIED 2026-10-07T16:23:23-04:00
INGESTED 2026-10-08T12:30:38-04:00