Vulnerability-Lookup

GHSA-MX22-3794-2VPV

Vulnerability from github – Published: 2026-10-08 17:52 – Updated: 2026-10-08 17:52

Summary

Excelize: Unchecked pivot-cache field index in extractPivotTableFields causes unrecoverable panic

Details

Summary

extractPivotTableFields builds order := pc.getPivotCacheFieldsName() from xl/pivotCache/pivotCacheDefinitionN.xml's list, then indexes it with values taken from a separately parsed xl/pivotTables/pivotTableN.xml part with zero cross-validation: order[field.Fld] where field.Fld is a raw attacker-controlled int from the <dataField fld="N"> attribute, and order[fieldIdx] where fieldIdx is a loop index over pt.PivotFields.PivotField that need not match the cache's field count. I executed two independent PoCs against the current HEAD: (1) trimmed the pivot cache's to count=0 while leaving the pivot table's 2 pivotFields untouched -> runtime error: index out of range [0] with length 0 at pivotTable.go:1431; (2) left the 2 cache fields completely intact and only changed one attribute, fld="1" -> fld="99999", in xl/pivotTables/pivotTable1.xml -> runtime error: index out of range [99999] with length 2 at pivotTable.go:1443. Both stack traces confirmed via non-recovered go test runs: extractPivotTableFields -> getPivotTable -> GetPivotTables.

Reachability / who can trigger this

Unauthenticated: any application that opens an untrusted .xlsx containing a pivot table and calls the public File.GetPivotTables(sheet) API. excelize has no recover() anywhere, so this crashes the host process (CLI/worker) or surfaces as an unhandled 500 in a request-scoped-recover HTTP service. Deterministic, single small crafted file, no user interaction beyond the service's normal open-and-read flow.

Proof of Concept / Reproduction

Method: 1) Verified source at HEAD (commit e81f0500, 2026-09-27, freshly cloned/up to date; git status clean except the new PoC files I added): read pivotTable.go:1425-1454 and confirmed verbatim: order := pc.getPivotCacheFieldsName() (1428), loop for fieldIdx, field := range pt.PivotFields.PivotField indexing order[fieldIdx] at axisRow/axisCol/axisPage (1431/1434/1437), and Data: order[field.Fld] (1443) inside the pt.DataFields.DataField loop -- zero bounds checks anywhere. Confirmed xmlPivotTable.go:271 Fld intxml:"fld,attr"` on xlsxDataField (raw attacker-controlled int, no validation) and the sibling Fld field at line 252. Rango build ./...-- compiles clean. Both citations are accurate. 2) Found the repo already contained an untracked PoC test file from earlier work (pivot_fld_poc_test.go) implementing this exact finding via a byte-level zip-tamper technique (build a legitimate workbook with excelize's own public AddPivotTable API, then hex-edit one raw XML part inside the saved .xlsx's zip bytes -- not a hypothetical reimplementation, uses the real unmodified excelize package). Did not just trust it: ran it myself withgo test -run 'TestPivotTableDataFieldFldIndexPanic|TestPivotTableDataFieldFldAttributeOutOfRangePanic' -v .and observed real PASS output with exact matching panic strings. 3) For stronger, independent evidence beyond a recover-wrapped test, I wrote my own standalone non-test Go program from scratch, cmd/pivotcrash/main.go (module github.com/xuri/excelize/v2, go1.27.0 toolchain), that imports the real compiled excelize package (no reimplementation) with two subcommands:gen/gen-trim(attacker: build a legit pivot-table workbook via the public API, then rezip with one XML part tampered -- either dataField fld="1"->fld="99999", or the pivot cache's <cacheFields count="2"> collapsed to count="0" -- writing the crafted .xlsx to disk) andrun(victim: a fresh OS process that does exactly what any consumer service does --excelize.OpenFile(path)thenf.GetPivotTables("Sheet1")-- with zero recover() anywhere in the file or the call chain). Executed as four separatego run` process invocations: gen, run, gen-trim, run.

Evidence: Test run (pre-existing PoC file, re-executed by me, both PASS): --- PASS: TestPivotTableDataFieldFldIndexPanic (0.00s) logging CONFIRMED: GetPivotTables panicked ... runtime error: index out of range [0] with length 0 --- PASS: TestPivotTableDataFieldFldAttributeOutOfRangePanic (0.00s) logging CONFIRMED: GetPivotTables panicked ... runtime error: index out of range [99999] with length 2 ok github.com/xuri/excelize/v2 0.114s

Standalone process-crash run #1 (go run ./cmd/pivotcrash run pivotcrash_malicious.xlsx, fld="99999" tamper, cache untouched with 2 fields): [victim] file opened successfully, workbook parsed with no errors [victim] now calling f.GetPivotTables("Sheet1") on the untrusted workbook... panic: runtime error: index out of range [99999] with length 2 goroutine 1 [running]: github.com/xuri/excelize/v2.(File).extractPivotTableFields(...) .../pivotTable.go:1443 +0xb9b github.com/xuri/excelize/v2.(File).getPivotTable(...) .../pivotTable.go:1379 +0x7f6 github.com/xuri/excelize/v2.(*File).GetPivotTables(...) .../pivotTable.go:1278 +0x2f7 main.runVictim(...) / main.main() -> exit status 2

Standalone process-crash run #2 (go run ./cmd/pivotcrash run pivotcrash_malicious_trim.xlsx, cacheFields trimmed to count=0, pivot table's 2 pivotFields untouched): panic: runtime error: index out of range [0] with length 0 goroutine 1 [running]: github.com/xuri/excelize/v2.(File).extractPivotTableFields(...) .../pivotTable.go:1431 +0xc15 github.com/xuri/excelize/v2.(File).getPivotTable(...) .../pivotTable.go:1379 +0x7f6 github.com/xuri/excelize/v2.(*File).GetPivotTables(...) .../pivotTable.go:1278 +0x2f7 main.runVictim(...) / main.main() -> exit status 2

In both standalone runs the "GetPivotTables RETURNED NORMALLY" print statement that follows the call was never reached -- the OS process itself terminated via an unrecovered Go panic (exit status 2), for a crafted .xlsx that excelize.OpenFile accepted without any error. Both stack traces terminate at the exact claimed sink lines (pivotTable.go:1443 and :1431) via the exact claimed call chain (extractPivotTableFields -> getPivotTable -> GetPivotTables). This is a real, unhandled crash of a real process running unmodified excelize code -- not a mock, not a simulated/hypothetical trace.

Novelty

Ran all 5 requested checks in full, plus extra verification. (1) Pulled the complete, paginated GHSA list via gh api (16 advisories, all state=published, no hidden drafts) and grepped full descriptions, not just summaries, for "pivot" -- only one incidental, non-overlapping hit (GHSA-wp2g-vpjj-g53r cites pivotTable.go:538 as an AddPivotTable call site for an unrelated formula-recursion stack-overflow bug). (2) Ran ~15 targeted GitHub issue searches (extractPivotTableFields, getPivotCacheFieldsName, GetPivotTables panic, dataField fld, BaseField, ShowValuesAs, "index out of range", cacheFields count mismatch, PivotFields panic, DataField, plus a broad "pivot" query returning 30 issues/PRs all individually triaged by title) and full-text-read the 5 most plausible (#2161, #1937, #2183, #1954, #1945) -- none match; the closest (#2161) is a nil-pointer bug in a different function/field, detailed above. (3) Checked PRs both by keyword (is:pr pivot = 10, is:pr "pivotTable.go" fld = 0, all reviewed; read PR #2168's full diff) and exhaustively (pulled all 31 currently-open PRs on the repo and reviewed every title) -- none touch pivot field indexing. (4) Ran 5 WebSearch queries combining the mechanism with "excelize"/"pivot table"/"CVE", and independently cross-checked OSV.dev's API (which mirrors NVD/GHSA/GO vuln DB) -- turned up only the already-ruled-out GHSA-fx5j (shared-string) and GHSA-h69g (row allocation) advisories, and a non-upstream automated "task"-tracking repo (windyswe/q ...[truncated for brevity]

Closest prior art considered: qax-os/excelize issue #2161 + merged PR #2168 ("This closes #2161, fix panic on read unsupported pivot table cache source types", merged 2025-07-05). That bug: pivotCacheDefinition.xml's has no child, so pc.CacheSource.WorksheetSource is a nil pointer, and getPivotTable() (then pivotTable.go:875) dereferenced .Sheet/.Ref on it -> nil-pointer-dereference panic, reached via GetPivotTables (then line 803). Fix was an early type-validation error return in getPivotTable, not any bounds check. SAME-FIX TEST: would that fix also close the candidate bug? No. The candidate's panic is index-out-of-range (not nil-deref) inside a different function, extractPivotTableFields, on a different data structure: order := pc.getPivotCacheFieldsName() (length = count of ) indexed by (a) a loop counter over pt.PivotFields.PivotField (a separate, unrelated count from pivotTableN.xml) at lines 1431/1434/1437, and (b) the raw unvalidated int field. ...[truncated for brevity]

Independent skeptical review

Tried hard to kill this and it holds. Independently re-read current HEAD (e81f05008b3, fetched and diffed against origin/master to confirm it's current) rather than trusting the report: pivotTable.go:1427-1454 (extractPivotTableFields) has zero bounds checks on order[fieldIdx] (axisRow/Col/Page branches, lines 1431/1434/1437) or order[field.Fld] (line 1443) — confirmed by direct Read, matching the claim's line citations exactly. This is a genuine oversight, not a designed invariant: the very next function in the same file, extractPivotTableShowValuesAs (lines 1476, 1486) and extractPivotTableField (line 1508), DO bounds-check structurally identical order/slice indices before using them — the developers clearly know this pattern needs guarding and simply missed it in extractPivotTableFields. Confirmed xmlPivotTable.go:271 Fld is a bare unchecked int XML attribute, and confirmed getPivotTable/pivotCacheReader/pivotTableReader perform no count-vs-actual-length cross-validation between the independently-parsed pivotTable and pivotCache XML parts. Grepped the entire repo for recover() — zero hits outside the researcher's own test file, confirming "no recover anywhere" is accurate. Re-ran both provided PoCs myself in a throwaway test file against this exact HEAD (go test -run TestPoC_PivotCache -v): both panic exactly as claimed, with byte-identical messages — "index out of range [0] with length 0" (truncated-cache-fields PoC, line 1431) and "index out of range [99999] with lengt ...[truncated for brevity]

Severity

8.7 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/xuri/excelize/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.1"
            },
            {
              "fixed": "2.11.1-0.20261003002531-6258dcebc4e2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107211"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-129"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T17:52:17Z",
    "nvd_published_at": "2026-10-07T18:17:18Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nextractPivotTableFields builds `order := pc.getPivotCacheFieldsName()` from xl/pivotCache/pivotCacheDefinitionN.xml\u0027s \u003ccacheFields\u003e list, then indexes it with values taken from a *separately parsed* xl/pivotTables/pivotTableN.xml part with zero cross-validation: `order[field.Fld]` where `field.Fld` is a raw attacker-controlled `int` from the `\u003cdataField fld=\"N\"\u003e` attribute, and `order[fieldIdx]` where fieldIdx is a loop index over `pt.PivotFields.PivotField` that need not match the cache\u0027s field count. I executed two independent PoCs against the current HEAD: (1) trimmed the pivot cache\u0027s \u003ccacheFields\u003e to count=0 while leaving the pivot table\u0027s 2 pivotFields untouched -\u003e `runtime error: index out of range [0] with length 0` at pivotTable.go:1431; (2) left the 2 cache fields completely intact and only changed one attribute, `fld=\"1\"` -\u003e `fld=\"99999\"`, in xl/pivotTables/pivotTable1.xml -\u003e `runtime error: index out of range [99999] with length 2` at pivotTable.go:1443. Both stack traces confirmed via non-recovered `go test` runs: extractPivotTableFields -\u003e getPivotTable -\u003e GetPivotTables.\n\n### Reachability / who can trigger this\n\nUnauthenticated: any application that opens an untrusted .xlsx containing a pivot table and calls the public `File.GetPivotTables(sheet)` API. excelize has no recover() anywhere, so this crashes the host process (CLI/worker) or surfaces as an unhandled 500 in a request-scoped-recover HTTP service. Deterministic, single small crafted file, no user interaction beyond the service\u0027s normal open-and-read flow.\n\n### Proof of Concept / Reproduction\n\n**Method:**\n1) Verified source at HEAD (commit e81f0500, 2026-09-27, freshly cloned/up to date; `git status` clean except the new PoC files I added): read pivotTable.go:1425-1454 and confirmed verbatim: `order := pc.getPivotCacheFieldsName()` (1428), loop `for fieldIdx, field := range pt.PivotFields.PivotField` indexing `order[fieldIdx]` at axisRow/axisCol/axisPage (1431/1434/1437), and `Data: order[field.Fld]` (1443) inside the `pt.DataFields.DataField` loop -- zero bounds checks anywhere. Confirmed xmlPivotTable.go:271 `Fld int `xml:\"fld,attr\"`` on xlsxDataField (raw attacker-controlled int, no validation) and the sibling Fld field at line 252. Ran `go build ./...` -- compiles clean. Both citations are accurate.\n2) Found the repo already contained an untracked PoC test file from earlier work (pivot_fld_poc_test.go) implementing this exact finding via a byte-level zip-tamper technique (build a legitimate workbook with excelize\u0027s own public AddPivotTable API, then hex-edit one raw XML part inside the saved .xlsx\u0027s zip bytes -- not a hypothetical reimplementation, uses the real unmodified excelize package). Did not just trust it: ran it myself with `go test -run \u0027TestPivotTableDataFieldFldIndexPanic|TestPivotTableDataFieldFldAttributeOutOfRangePanic\u0027 -v .` and observed real PASS output with exact matching panic strings.\n3) For stronger, independent evidence beyond a recover-wrapped test, I wrote my own standalone non-test Go program from scratch, cmd/pivotcrash/main.go (module github.com/xuri/excelize/v2, go1.27.0 toolchain), that imports the real compiled excelize package (no reimplementation) with two subcommands: `gen`/`gen-trim` (attacker: build a legit pivot-table workbook via the public API, then rezip with one XML part tampered -- either dataField fld=\"1\"-\u003efld=\"99999\", or the pivot cache\u0027s \u003ccacheFields count=\"2\"\u003e collapsed to count=\"0\" -- writing the crafted .xlsx to disk) and `run` (victim: a fresh OS process that does exactly what any consumer service does -- `excelize.OpenFile(path)` then `f.GetPivotTables(\"Sheet1\")` -- with zero recover() anywhere in the file or the call chain). Executed as four separate `go run` process invocations: gen, run, gen-trim, run.\n\n**Evidence:**\nTest run (pre-existing PoC file, re-executed by me, both PASS):\n`--- PASS: TestPivotTableDataFieldFldIndexPanic (0.00s)` logging `CONFIRMED: GetPivotTables panicked ... runtime error: index out of range [0] with length 0`\n`--- PASS: TestPivotTableDataFieldFldAttributeOutOfRangePanic (0.00s)` logging `CONFIRMED: GetPivotTables panicked ... runtime error: index out of range [99999] with length 2`\n`ok  github.com/xuri/excelize/v2  0.114s`\n\nStandalone process-crash run #1 (`go run ./cmd/pivotcrash run pivotcrash_malicious.xlsx`, fld=\"99999\" tamper, cache untouched with 2 fields):\n[victim] file opened successfully, workbook parsed with no errors\n[victim] now calling f.GetPivotTables(\"Sheet1\") on the untrusted workbook...\npanic: runtime error: index out of range [99999] with length 2\ngoroutine 1 [running]:\ngithub.com/xuri/excelize/v2.(*File).extractPivotTableFields(...)\n\t.../pivotTable.go:1443 +0xb9b\ngithub.com/xuri/excelize/v2.(*File).getPivotTable(...)\n\t.../pivotTable.go:1379 +0x7f6\ngithub.com/xuri/excelize/v2.(*File).GetPivotTables(...)\n\t.../pivotTable.go:1278 +0x2f7\nmain.runVictim(...) / main.main() -\u003e exit status 2\n\nStandalone process-crash run #2 (`go run ./cmd/pivotcrash run pivotcrash_malicious_trim.xlsx`, cacheFields trimmed to count=0, pivot table\u0027s 2 pivotFields untouched):\npanic: runtime error: index out of range [0] with length 0\ngoroutine 1 [running]:\ngithub.com/xuri/excelize/v2.(*File).extractPivotTableFields(...)\n\t.../pivotTable.go:1431 +0xc15\ngithub.com/xuri/excelize/v2.(*File).getPivotTable(...)\n\t.../pivotTable.go:1379 +0x7f6\ngithub.com/xuri/excelize/v2.(*File).GetPivotTables(...)\n\t.../pivotTable.go:1278 +0x2f7\nmain.runVictim(...) / main.main() -\u003e exit status 2\n\nIn both standalone runs the \"GetPivotTables RETURNED NORMALLY\" print statement that follows the call was never reached -- the OS process itself terminated via an unrecovered Go panic (exit status 2), for a crafted .xlsx that `excelize.OpenFile` accepted without any error. Both stack traces terminate at the exact claimed sink lines (pivotTable.go:1443 and :1431) via the exact claimed call chain (extractPivotTableFields -\u003e getPivotTable -\u003e GetPivotTables). This is a real, unhandled crash of a real process running unmodified excelize code -- not a mock, not a simulated/hypothetical trace.\n\n### Novelty\n\nRan all 5 requested checks in full, plus extra verification. (1) Pulled the complete, paginated GHSA list via gh api (16 advisories, all state=published, no hidden drafts) and grepped full descriptions, not just summaries, for \"pivot\" -- only one incidental, non-overlapping hit (GHSA-wp2g-vpjj-g53r cites pivotTable.go:538 as an AddPivotTable call site for an unrelated formula-recursion stack-overflow bug). (2) Ran ~15 targeted GitHub issue searches (extractPivotTableFields, getPivotCacheFieldsName, GetPivotTables panic, dataField fld, BaseField, ShowValuesAs, \"index out of range\", cacheFields count mismatch, PivotFields panic, DataField, plus a broad \"pivot\" query returning 30 issues/PRs all individually triaged by title) and full-text-read the 5 most plausible (#2161, #1937, #2183, #1954, #1945) -- none match; the closest (#2161) is a nil-pointer bug in a different function/field, detailed above. (3) Checked PRs both by keyword (is:pr pivot = 10, is:pr \"pivotTable.go\" fld = 0, all reviewed; read PR #2168\u0027s full diff) and exhaustively (pulled all 31 currently-open PRs on the repo and reviewed every title) -- none touch pivot field indexing. (4) Ran 5 WebSearch queries combining the mechanism with \"excelize\"/\"pivot table\"/\"CVE\", and independently cross-checked OSV.dev\u0027s API (which mirrors NVD/GHSA/GO vuln DB) -- turned up only the already-ruled-out GHSA-fx5j (shared-string) and GHSA-h69g (row allocation) advisories, and a non-upstream automated \"task\"-tracking repo (windyswe/q\n...[truncated for brevity]\n\nClosest prior art considered: qax-os/excelize issue #2161 + merged PR #2168 (\"This closes #2161, fix panic on read unsupported pivot table cache source types\", merged 2025-07-05). That bug: pivotCacheDefinition.xml\u0027s \u003ccacheSource type=\"external\"/\u003e has no \u003cworksheetSource\u003e child, so pc.CacheSource.WorksheetSource is a nil pointer, and getPivotTable() (then pivotTable.go:875) dereferenced .Sheet/.Ref on it -\u003e nil-pointer-dereference panic, reached via GetPivotTables (then line 803). Fix was an early type-validation error return in getPivotTable, not any bounds check. SAME-FIX TEST: would that fix also close the candidate bug? No. The candidate\u0027s panic is index-out-of-range (not nil-deref) inside a different function, extractPivotTableFields, on a different data structure: `order := pc.getPivotCacheFieldsName()` (length = count of \u003ccacheFields\u003e) indexed by (a) a loop counter over pt.PivotFields.PivotField (a separate, unrelated count from pivotTableN.xml) at lines 1431/1434/1437, and (b) the raw unvalidated int field.\n...[truncated for brevity]\n\n### Independent skeptical review\n\nTried hard to kill this and it holds. Independently re-read current HEAD (e81f05008b3, fetched and diffed against origin/master to confirm it\u0027s current) rather than trusting the report: pivotTable.go:1427-1454 (extractPivotTableFields) has zero bounds checks on order[fieldIdx] (axisRow/Col/Page branches, lines 1431/1434/1437) or order[field.Fld] (line 1443) \u2014 confirmed by direct Read, matching the claim\u0027s line citations exactly. This is a genuine oversight, not a designed invariant: the very next function in the same file, extractPivotTableShowValuesAs (lines 1476, 1486) and extractPivotTableField (line 1508), DO bounds-check structurally identical order/slice indices before using them \u2014 the developers clearly know this pattern needs guarding and simply missed it in extractPivotTableFields. Confirmed xmlPivotTable.go:271 Fld is a bare unchecked `int` XML attribute, and confirmed getPivotTable/pivotCacheReader/pivotTableReader perform no count-vs-actual-length cross-validation between the independently-parsed pivotTable and pivotCache XML parts. Grepped the entire repo for recover() \u2014 zero hits outside the researcher\u0027s own test file, confirming \"no recover anywhere\" is accurate. Re-ran both provided PoCs myself in a throwaway test file against this exact HEAD (go test -run TestPoC_PivotCache -v): both panic exactly as claimed, with byte-identical messages \u2014 \"index out of range [0] with length 0\" (truncated-cache-fields PoC, line 1431) and \"index out of range [99999] with lengt\n...[truncated for brevity]",
  "id": "GHSA-mx22-3794-2vpv",
  "modified": "2026-10-08T17:52:17Z",
  "published": "2026-10-08T17:52:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/security/advisories/GHSA-mx22-3794-2vpv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-107211"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/pull/2435"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/commit/6258dcebc4e2a2aed985c38a08098dfd908521d1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/qax-os/excelize"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Excelize: Unchecked pivot-cache field index in extractPivotTableFields causes unrecoverable panic"
}

CVE-2026-107211 (GCVE-0-2026-107211)

Vulnerability from cvelistv5 – Published: 2026-10-07 17:11 – Updated: 2026-10-07 19:03

Title

Excelize: Unchecked pivot-cache field index in extractPivotTableFields causes unrecoverable panic

Summary

Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.8.1 to 2.11.0, separately parsed pivot-table field indices are used to index the pivot-cache field-name slice without bounds checks. extractPivotTableFields uses getPivotCacheFieldsName output while processing GetPivotTables and trusts the dataField fld attribute as an index. When a crafted workbook supplies a pivot-field count mismatch or an out-of-range dataField fld value before GetPivotTables is called, the unchecked index causes a Go slice-bounds panic that escapes the library, allowing an attacker to crash the process or request worker. No fixed version is available as of this review.

Severity

8.7 (High)


                        
                          CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

SSVC

Exploitation: none Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-07 19:03 UTC

CWE

CWE-129 - Improper Validation of Array Index

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7592 records in the last 180 days details

References

3 references

URL	Tags
https://github.com/qax-os/excelize/security/advis…	x_refsource_CONFIRM
https://github.com/qax-os/excelize/pull/2435	x_refsource_MISC
https://github.com/qax-os/excelize/commit/6258dce…	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
qax-os	excelize	Affected: >= 2.8.1, <= 2.11.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-107211",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-07T19:03:04.540488Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-07T19:03:18.640Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "excelize",
          "vendor": "qax-os",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 2.8.1, \u003c= 2.11.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.8.1 to 2.11.0, separately parsed pivot-table field indices are used to index the pivot-cache field-name slice without bounds checks. extractPivotTableFields uses getPivotCacheFieldsName output while processing GetPivotTables and trusts the dataField fld attribute as an index. When a crafted workbook supplies a pivot-field count mismatch or an out-of-range dataField fld value before GetPivotTables is called, the unchecked index causes a Go slice-bounds panic that escapes the library, allowing an attacker to crash the process or request worker. No fixed version is available as of this review."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 8.7,
            "baseSeverity": "HIGH",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "NONE"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-129",
              "description": "CWE-129: Improper Validation of Array Index",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-07T17:11:17.902Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/qax-os/excelize/security/advisories/GHSA-mx22-3794-2vpv",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/qax-os/excelize/security/advisories/GHSA-mx22-3794-2vpv"
        },
        {
          "name": "https://github.com/qax-os/excelize/pull/2435",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/qax-os/excelize/pull/2435"
        },
        {
          "name": "https://github.com/qax-os/excelize/commit/6258dcebc4e2a2aed985c38a08098dfd908521d1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/qax-os/excelize/commit/6258dcebc4e2a2aed985c38a08098dfd908521d1"
        }
      ],
      "source": {
        "advisory": "GHSA-mx22-3794-2vpv",
        "discovery": "UNKNOWN"
      },
      "title": "Excelize: Unchecked pivot-cache field index in extractPivotTableFields causes unrecoverable panic"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-107211",
    "datePublished": "2026-10-07T17:11:17.902Z",
    "dateReserved": "2026-10-07T14:34:14.815Z",
    "dateUpdated": "2026-10-07T19:03:18.640Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
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.

Action not permitted

GHSA-MX22-3794-2VPV

Summary

Reachability / who can trigger this

Proof of Concept / Reproduction

Novelty

Independent skeptical review

CVE-2026-107211 (GCVE-0-2026-107211)

Tags

Sightings

Nomenclature

Related by attack behaviour