--- id: "CVE-2026-107219" page: "https://infrastack.ai/live/CVE-2026-107219" kind: "vulnerability" aliases: ["CVE-2026-107219", "GHSA-jrfj-fhj2-jjvm", "GO-2026-6681"] title: "Excelize: Unbounded spinCount in agile decryption burns CPU during OpenFile" severity: "high" cvss: 7.5 epss: 0.00363 exploited: false status: "open" category: "package" products: [{"name": "github.com/360EntSecGroup-Skylar/excelize/v2", "fixed": [], "affected": ">= 2.3.1", "ecosystem": "go"}, {"name": "github.com/xuri/excelize/v2", "fixed": ["2.11.1-0.20260906004932-2badfcd5841d"], "affected": "< 2.11.1-0.20260906004932-2badfcd5841d", "ecosystem": "go"}, {"name": "excelize", "fixed": [], "affected": ">= 2.3.1, <= 2.11.0", "ecosystem": "vendor"}, {"name": "github.com/xuri/excelize/v2", "fixed": ["2.11.1-0.20260906004932-2badfcd5841d"], "affected": ">= 2.3.1, < 2.11.1-0.20260906004932-2badfcd5841d", "ecosystem": "go"}] ecosystems: ["go", "vendor"] tags: ["cwe-400", "excel", "file-upload", "go", "package"] not_affected_if: ["no-encrypted-workbooks", "no-untrusted-files"] published_at: "2026-10-07T19:17:34+00:00" first_seen_at: "2026-11-06T00:09:03+00:00" updated_at: "2026-11-06T00:19:08+00:00" sources: [{"source": "govuln", "url": "https://pkg.go.dev/vuln/GO-2026-6681", "first_seen_at": "2026-11-06T00:09:03+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-107219", "first_seen_at": "2026-11-06T00:19:01+00:00"}, {"source": "ghsa", "url": "https://github.com/advisories/GHSA-jrfj-fhj2-jjvm", "first_seen_at": "2026-11-06T00:19:08+00:00"}] exploit_sources: [{"type": "epss", "score": 0.00363, "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-107219"}] --- # Excelize: Unbounded spinCount in agile decryption burns CPU during OpenFile Link for people: https://infrastack.ai/live/CVE-2026-107219 (this .md is for agents) Excelize, a Go library for reading and writing Excel files, does not cap the spinCount value when decrypting password-protected agile-encrypted workbooks. A crafted encrypted file can make OpenFile consume large amounts of CPU. _Summary, check and fix written by a model from the sources; labelled as such._ ## Affected - go:github.com/360EntSecGroup-Skylar/excelize/v2 affected >= 2.3.1 fixed no fixed version listed - go:github.com/xuri/excelize/v2 affected < 2.11.1-0.20260906004932-2badfcd5841d fixed 2.11.1-0.20260906004932-2badfcd5841d - vendor:excelize affected >= 2.3.1, <= 2.11.0 fixed no fixed version listed - go:github.com/xuri/excelize/v2 affected >= 2.3.1, < 2.11.1-0.20260906004932-2badfcd5841d fixed 2.11.1-0.20260906004932-2badfcd5841d ## How to check - Check the Go module version in `go.mod` for `github.com/xuri/excelize/v2` - Check whether the application calls OpenFile on user-supplied or uploaded .xlsx files - Check whether the old module path `github.com/360EntSecGroup-Skylar/excelize/v2` appears in `go.mod` ## Fix - `github.com/xuri/excelize/v2`: move to `2.11.1-0.20260906004932-2badfcd5841d` or later - `github.com/360EntSecGroup-Skylar/excelize/v2`: no fixed version is listed in the sources ## Timeline - 2026-11-06T00:09:03+00:00 govuln https://pkg.go.dev/vuln/GO-2026-6681 - 2026-11-06T00:19:01+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-107219 - 2026-11-06T00:19:08+00:00 ghsa https://github.com/advisories/GHSA-jrfj-fhj2-jjvm ## Documents - [advisory] Vendor advisory: github.com https://github.com/qax-os/excelize/security/advisories/GHSA-jrfj-fhj2-jjvm - [advisory] Maintainer's advisory: api.github.com https://api.github.com/repos/qax-os/excelize/security-advisories/GHSA-jrfj-fhj2-jjvm - [fix] Patch: github.com https://github.com/qax-os/excelize/commit/2badfcd5841d0d88b0ffea119f5a2f3c53b4910b - [fix] Patch: github.com https://github.com/qax-os/excelize/pull/2389 ## From the sources 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.go` in v2.3.1 and is unchanged through v2.11.0. Excel and LibreOffice write spinCount 100000, which costs 61ms here, so a ceiling well above the legitimate value would cost real files nothing. This is availability only, and it is not a vulnerability for a program that only opens files its own operator produced. --- _Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_