Skip to content

chore(renovate): Security update Update module github.com/xuri/excelize/v2 to v2.11.1 [SECURITY] - #390

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/go-github.com-xuri-excelize-v2-vulnerability
Open

chore(renovate): Security update Update module github.com/xuri/excelize/v2 to v2.11.1 [SECURITY]#390
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/go-github.com-xuri-excelize-v2-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Nov 3, 2026

Copy link
Copy Markdown
Contributor

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
github.com/xuri/excelize/v2 v2.11.0 → v2.11.1 age adoption passing confidence

Excelize: GetStyle panics on a negative fillId, borderId or fontId in styles.xml

CVE-2026-107225 / GHSA-5h23-36rv-pm65

More information

Details

Summary

File.GetStyle indexes the fill, border and font tables with values taken straight out of xl/styles.xml, and the conditions gating those lookups check only the upper bound. A workbook whose cellXfs entry carries fillId="-1", borderId="-1" or fontId="-1" reaches a negative slice index and panics. excelize has no recover(), so the panic leaves GetStyle and takes the calling process with it.

Same defect class as GHSA-48hm-4h8j-58fg, the negative shared-string index, in a different file. That one was fixed by adding the missing lower bound; these three sites still lack it.

Where it is

styles.go, in GetStyle, lines 1683, 1686 and 1689:

xf := s.CellXfs.Xf[idx]
if extractStyleCondFuncs["fill"](xf, s) {
    f.extractFills(s.Fills.Fill[*xf.FillID], s, style)
}
if extractStyleCondFuncs["border"](xf, s) {
    f.extractBorders(s.Borders.Border[*xf.BorderID], s, style)
}
if extractStyleCondFuncs["font"](xf, s) {
    style.Font = extractFont(s.Fonts.Font[*xf.FontID])
}

The conditions, at lines 1171 to 1185, bound only the top:

"fill": func(xf xlsxXf, s *xlsxStyleSheet) bool {
    return (xf.ApplyFill == nil || (xf.ApplyFill != nil && *xf.ApplyFill)) &&
        xf.FillID != nil && s.Fills != nil &&
        *xf.FillID < len(s.Fills.Fill)
},

*xf.FillID < len(...) is satisfied by any negative value. FillID, BorderID and FontID are *int unmarshalled directly from the fillId, borderId and fontId attributes, so the value is whatever the file says. The border and font conditions have the same shape.

The correct pattern is already in the same function, six lines above at 1677:

if idx < 0 || s.CellXfs == nil || len(s.CellXfs.Xf) <= idx {
    return style, newInvalidStyleID(idx)
}

and again at 1783. So the style index itself is guarded on both sides while the three ids it leads to are not.

Proof of concept

Executed against master at f98df08, which is the merge of #​2366, so this is current rather than historical. The harness builds a normal styled workbook with excelize, rewrites one attribute of the cellXfs entry inside the zip to -1, reopens it and calls GetCellStyle then GetStyle:

control (all >= 0)           ok style=true err=<nil>
fillId=-1                    PANIC: runtime error: index out of range [-1]
borderId=-1                  PANIC: runtime error: index out of range [-1]
fontId=-1                    PANIC: runtime error: index out of range [-1]

The control confirms the harness reads a valid file correctly, so the three panics are the negative ids rather than a broken fixture. Worth mentioning because my first attempt at this harness patched only fillId and appeared to show the other two were fine; they are not, the replacement had simply missed them.

Impact

Any application that opens an untrusted .xlsx and reads cell styling crashes. GetStyle is reached through GetCellStyle and from the style-copying and rendering paths, so it sits on the ordinary read path. With no recover() anywhere in excelize, a CLI or worker exits and a service returns 500 per request unless the caller installed its own recovery middleware.

No memory corruption and no information disclosure. Availability only.

Suggested fix

Add the lower bound to each of the three conditions, matching what line 1677 already does for the style index:

*xf.FillID >= 0 && *xf.FillID < len(s.Fills.Fill)

and the same for BorderID and FontID. Three one-line changes in extractStyleCondFuncs.

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Excelize: A Zip64 uncompressed-size of 2^63 panics OpenFile/OpenReader

CVE-2026-107224 / GHSA-fw94-4wwp-w8pw

More information

Details

Summary

A Zip64 uncompressed-size of 2^63 casts to a negative int64 that bypasses the unzip-size guard and reaches make([]byte, 0, negativeCap)

A Zip64 uncompressed-size in the range [2^63, 2^64) casts to a negative int64 in zip.File.FileInfo().Size(), and ReadZipReader does signed arithmetic on that value, so the total-decompression guard is bypassed and the negative size reaches make([]byte, 0, size) in readFile. A 159-byte crafted file panics OpenFile and OpenReader with runtime error: makeslice: cap out of range.

The guard, at lib.go:44-46 on HEAD ae2113b:

fileSize := v.FileInfo().Size()
unzipSize += fileSize
if unzipSize > f.options.UnzipSizeLimit {
	return fileList, worksheets, newUnzipSizeLimitError(f.options.UnzipSizeLimit)
}

FileInfo().Size() returns int64(UncompressedSize64). UncompressedSize64 is read from the Zip64 extended-information extra record in the central directory and is fully attacker controlled, so any value with the top bit set arrives as a negative int64. unzipSize then goes negative and the comparison against UnzipSizeLimit (default 1000 << 24, templates.go:193) is false no matter how many such entries the archive contains.

The same negative value also fails the two stream-to-temp checks at lib.go:53 and lib.go:64 (fileSize > f.options.UnzipXMLSizeLimit), so the entry is not diverted to a temp file and control reaches readFile:

// lib.go:150
dat := make([]byte, 0, file.FileInfo().Size())

make with a negative capacity panics. There is no recover() in any non-test file in the library, so the panic leaves the public API and takes down the calling goroutine.

The asymmetry inside this same function is the clearest way to see it: unzipToTemp (lib.go:83) handles an entry with a plain io.Copy and never pre-allocates from the declared size, so it is indifferent to whatever the header claims. Only the pre-allocating branch trusts that number, and it trusts it after a signed comparison that a wrapped value walks straight through.

Reproduction, executed against HEAD ae2113b (go1.26.5)

A 159-byte archive was built with one stored entry named xl/worksheets/sheet1.xml: truthful 1-byte local header, central-directory 32-bit uncompressed size set to the 0xFFFFFFFF Zip64 sentinel, and a Zip64 extra record (tag 0x0001, data size 8) declaring UncompressedSize64 = 0x8000000000000000.

entry "xl/worksheets/sheet1.xml" FileInfo().Size() = -9223372036854775808
excelize.OpenReader(bytes.NewReader(raw))  ->  panic: runtime error: makeslice: cap out of range

Control, the identical archive with UncompressedSize64 = 0x7FFFFFFFFFFFFFFF:

entry "xl/worksheets/sheet1.xml" FileInfo().Size() = 9223372036854775807
excelize.OpenReader(bytes.NewReader(raw))  ->  err = "unzip size exceeds the 16777216000 bytes limit"

The control isolates the defect to the sign flip rather than to size magnitude: the guard behaves correctly for any positive declared size and fails only once the value wraps. archive/zip itself accepts the archive without complaint, so nothing upstream of excelize rejects it.

What I verified and what I did not

I ran both cases above myself and confirmed each cited line at HEAD. I caught the panic with a deliberate recover in my harness so I could print it; nothing in excelize recovers it, which I checked by grepping every non-test .go file. I did not separately run the OpenFile variant, since OpenFile reaches the same ReadZipReader loop, and I did not attempt to turn the bypassed size cap into a separate decompression-bomb primitive.

Attacker model

Any service that opens a spreadsheet it did not produce. The payload is 159 bytes, needs no authentication, and is deterministic.

Suggested fix

Compare against the limit in unsigned space, and bound the allocation independently rather than trusting the header:

if v.UncompressedSize64 > uint64(f.options.UnzipSizeLimit) {
	return fileList, worksheets, newUnzipSizeLimitError(f.options.UnzipSizeLimit)
}

and in readFile, reject or clamp a declared size that is negative or larger than the limit before calling make. The same unsigned treatment applies to the two UnzipXMLSizeLimit comparisons, which currently route a wrapped size away from the safe streaming path and into the pre-allocating one.

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Excelize: Unbounded attribute is loaded with no MaxColumns check and expanded per-column by flatCols(), so any column mutator hangs or OOMs the process

CVE-2026-107223 / GHSA-fq3v-74gv-27gm

More information

Details

Summary

The max attribute of a <col> element in xl/worksheets/sheetN.xml is read verbatim on open with no check against MaxColumns, and flatCols() then walks Min..Max doing a deepcopy.Copy and append per iteration. Executed: max="300000", only about 18x past the real 16384 limit, cost 46.2 s of CPU and 122 MB on a single SetColWidth call, and the growth is linear in max up to 2^31-1.

Confirmed at ae2113b (HEAD at the time of audit).

Details

col.go:547, flatCols(), with the two loops at :549 and :564:

for i := col.Min; i <= col.Max; i++ {
...
for i := column.Min; i <= column.Max; i++ { ... fc = append(fc, deepcopy.Copy(...)) }

column.Min and column.Max are plain int attributes on xmlWorksheet.go:279-280, bound straight from the file. MaxColumns is 16384 (templates.go:176) and nothing in the parse path compares against it.

The contrast that makes this an oversight rather than a design decision is inside the callers themselves. SetColWidth validates its own column argument through parseColRange, which clamps to MaxColumns. But flatCols iterates ws.Cols.Col, the file-loaded slice, so the caller's validated argument never constrains the loop. The crafted column expands no matter which column the caller touches.

The row axis has the guard this axis is missing: GHSA-h69g-9hx6-f3v4 capped checkSheet's row allocation at TotalRows, and GHSA-q5j5-6p94-4gwc capped streaming Rows.Next. There is no column-axis equivalent.

Public entry points that flatten the existing columns: SetColWidth (col.go:498 into :534), SetColStyle (col.go:431 into :477), SetColVisible (col.go:282 into :313), SetColOutlineLevel (col.go:376 into :407).

PoC

Executed in-package: crafted a real xlsx, rezipped with an injected <cols> block before <sheetData>, opened it with OpenReader, then called SetColWidth.

<cols><col min="1" max="2147483647" width="9"/></cols>
f.SetColWidth("Sheet1", "A", "A", 12)

Measured:

  • max="300000": 46.2 s CPU, 122 MB allocated, ws.Cols.Col grew to 300000 entries, from one call.
  • max="5000000": did not complete in 110 s, killed by the test timeout.

Growth is linear in max. At max=2147483647 that is roughly two billion xlsxCol allocations, which is hundreds of gigabytes and in practice a permanent hang ending in OOM.

Impact

Any service that opens an untrusted spreadsheet and calls a column mutator. The input is a few dozen bytes of XML inside an otherwise ordinary workbook, no authentication is involved beyond whatever gates the upload, and the process is either wedged for minutes or killed by the OOM reaper. Availability only; no read or write primitive here.

Suggested fix

Validate col.Min and col.Max against MinColumns/MaxColumns when parsing the <col> element, or at the top of flatCols, returning ErrColumnNumber for out-of-range values. That mirrors what checkRowNum already does on the row axis.

Why this is not GHSA-h69g-9hx6-f3v4 or GHSA-q5j5-6p94-4gwc

Both of those are row-axis allocation bounds, and both fixes cap at TotalRows. Neither touched <col> parsing or flatCols. This is the same weakness class on the column axis, and it is arguably worse than the two that were fixed, because those had a cap that was bypassed while this one has no cap at all.

Severity

  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Excelize: GetConditionalFormats indexes conditional-formatting rule sub-elements with no length or nil check

CVE-2026-107222 / GHSA-rxcj-4pj5-74gr

More information

Details

Summary

GetConditionalFormats reads sub-elements of a <cfRule> straight out of xl/worksheets/sheetN.xml and indexes them without checking length, and in one case without checking for nil. Three rule types are affected: cellIs, dataBar and colorScale. A workbook with a rule that is missing a child a real Excel file would always have panics the call.

Where it is

All three sinks are in styles.go, at the same line numbers in v2.11.0 and on master d552a7e. All three are reached from GetConditionalFormats through styles.go:3271.

styles.go:3003, in extractCondFmtCellIs:

	format.Value = c.Formula[0]

The branch above it handles len(c.Formula) == 2; this one is the fallback and does not check that there is a formula at all, so a cellIs rule with no <formula> child indexes an empty slice.

styles.go:3132, in the colorScale extractor:

	values := len(c.ColorScale.Cfvo)

c.ColorScale is a *xlsxColorScale and is nil when the <cfRule type="colorScale"> element has no <colorScale> child. Lines 3148 and 3153 then index Cfvo[1] and Cfvo[2] in the three-colour branch with no length check either.

styles.go:3186, :3188 and :3190, in the dataBar extractor:

		format.MinType = c.DataBar.Cfvo[0].Type
		...
		format.BarColor = "#" + f.getThemeColor(c.DataBar.Color[0])

The guard here is c.DataBar != nil, which says nothing about the length of Cfvo or Color, so an empty <dataBar></dataBar> element reaches all three.

Who the attacker is

Anyone who can hand a spreadsheet to a service that opens it and calls GetConditionalFormats. No authentication, no user interaction beyond the service doing its normal job, and the file is small.

Reproduction

Three minimal .xlsx files were built, each a real zip with [Content_Types].xml, _rels/.rels, xl/workbook.xml, xl/_rels/workbook.xml.rels and one worksheet, opened each with the public excelize.OpenReader and called GetConditionalFormats("Sheet1"). Nothing internal is touched.

The worksheet fragment for the cellIs case, note there is no <formula> child:

<conditionalFormatting sqref="A1"><cfRule type="cellIs" operator="equal" priority="1" dxfId="0"/></conditionalFormatting>

for dataBar:

<conditionalFormatting sqref="A1"><cfRule type="dataBar" priority="1"><dataBar></dataBar></cfRule></conditionalFormatting>

and for colorScale:

<conditionalFormatting sqref="A1"><cfRule type="colorScale" priority="1"/></conditionalFormatting>

Observed against master d552a7e on go1.26.5:

cellIs      panic: runtime error: index out of range [0] with length 0
              styles.go:3003
              styles.go:1217
              styles.go:3271

dataBar     panic: runtime error: index out of range [0] with length 0
              styles.go:3186
              styles.go:1262
              styles.go:3271

colorScale  panic: runtime error: invalid memory address or nil pointer dereference
              styles.go:3132
              styles.go:1259
              styles.go:3271

One honesty note on impact. These are ordinary Go panics, not fatal errors, so a caller that wraps the call in recover survives them.

Suggested fix

Length-check c.Formula before line 3003 and return the rule with an empty value when there is no formula. Nil-check c.ColorScale before line 3132 and length-check ColorScale.Cfvo before indexing 1 and 2. Length-check DataBar.Cfvo and DataBar.Color alongside the existing nil check at 3186 to 3190. Skipping the malformed rule rather than erroring would keep GetConditionalFormats usable on files that are merely sloppy.

Affected versions

github.com/xuri/excelize/v2 up to and including v2.11.0, and master at d552a7e. I read the three sinks at tag v2.11.0 and at master and ran the reproducers against master.

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Excelize: a row whose earlier cell has a higher column reference than its last cell panics index out of range on almost every worksheet read API

CVE-2026-107221 / GHSA-8mcq-6wmr-jrjv

More information

Details

Affected versions and vulnerable location
  • Confirmed at ae2113b (current HEAD).
  • Sink: rows.go:967 ws.SheetData.Row[rowIdx].C[colNum-1] = *colData inside checkRow.
  • checkRow computes lastCol from the column of the last cell in document order (rows.go:940), allocates targetList of that length, then re-scatters every source cell into C[colNum-1].
Root cause

The slice is sized from the last cell's column, but cells are not required to be column-sorted in the XML. A cell that appears earlier in the row but references a higher column than the last cell has colNum-1 >= len(targetList), so the assignment writes out of range. MaxColumns/TotalRows do not help, every individual column is valid; the bug is the ordering assumption, not magnitude.

Attacker model and reachability

Any service that opens an untrusted spreadsheet and calls a worksheet API that goes through workSheetReader -> checkRow (excelize.go:332): GetCellValue, GetCellFormula, CalcCellValue, GetMergeCells, SetCellValue, and essentially every non-streaming worksheet call. (The streaming GetRows/Rows() SAX path does not trigger it.) Unauthenticated, deterministic, unrecovered panic -> process crash.

Proof of concept (executed)

Crafted xl/worksheets/sheet1.xml with a row whose cells are out of column order and whose earlier cell exceeds the last cell's column:

<row r="1"><c r="D1"><v>4</v></c><c r="C1"><v>3</v></c></row>

GetCellValue("Sheet1","A1") (via getCellStringFunc -> workSheetReader -> checkRow) panicked index out of range [3] with length 3 at rows.go:967.

Confirming grep:

rg -n "func checkRow|lastCol|Row\[rowIdx\].C\[colNum-1\]" rows.go
Suggested fix

Size targetList from the maximum cell column in the row (not the last cell in document order), or bounds-check colNum-1 against len(targetList) and grow the slice as needed before the assignment.

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Excelize: Panic in cellInRange on a worksheet with an empty mergeCell ref

CVE-2026-107220 / GHSA-g27h-8qhm-6pff

More information

Details

Summary

A worksheet containing <mergeCell ref=""/> makes mergeCellsParser leave the cached rectangle empty, and cellInRange then indexes that empty slice without a length check. Every non-streaming cell API panics with index out of range [0] with length 0 on the first cell read after opening the file.

Where it is

cell.go, cellInRange

func cellInRange(cell, ref []int) bool {
	return cell[0] >= ref[0] && cell[0] <= ref[2] && cell[1] >= ref[1] && cell[1] <= ref[3]
}

ref is indexed at four positions with no bounds check.

The caller that can hand it an empty slice, mergeCellsParser

if ref := ws.MergeCells.Cells[i].Ref; len(ws.MergeCells.Cells[i].rect) == 0 && ref != "" {
	if strings.Count(ref, ":") != 1 {
		ref += ":" + ref
	}
	rect, err := rangeRefToCoordinates(ref)
	if err != nil {
		return cell, err
	}
	_ = sortCoordinates(rect)
	ws.MergeCells.Cells[i].rect = rect
}
if cellInRange([]int{col, row}, ws.MergeCells.Cells[i].rect) {

The ref != "" condition means an empty ref skips the block that populates rect, so rect stays nil. The cellInRange call on the next line is unconditional and receives that nil slice.

Ref comes straight from xl/worksheets/sheetN.xml through encoding/xml, so an empty string is entirely attacker-controlled.

Impact

Any consumer that opens an untrusted workbook and reads a cell panics. The loop scans every merged cell, so any cell reference triggers it, not a specific one. Affected entry points include GetCellValue, GetCellType, GetCellFormula, SetCellValue and the in-cell branch of GetPictures. The streaming Rows and GetRows use the SAX path and do not go through this parser, and GetMergeCells routes through Rect() which errors cleanly, which is probably why this has not surfaced before.

There is no option or flag involved; opening the file succeeds and the panic fires on the first cell read. Unless the caller wraps the call in recover() it takes the process down.

This is a regression. Commit a34c81e (PR #​1500, 2023-03-20) replaced checkCellInRangeRef, whose len(rng) != 2 guard returned cleanly for an empty ref, with the cached-rect fast path above, and the guard did not come along. git merge-base --is-ancestor confirms that commit is an ancestor of v2.11.0, so released versions are affected as well as HEAD.

Proof of concept

Executed at HEAD.

Build a minimal xlsx whose xl/worksheets/sheet1.xml contains:

<mergeCells count="1"><mergeCell ref=""></mergeCell></mergeCells>

Then:

f, err := excelize.OpenReader(bytes.NewReader(data))
if err != nil { t.Fatal(err) }
_, _ = f.GetCellValue("Sheet1", "A1")

Observed, running against the repository at HEAD:

panic: runtime error: index out of range [0] with length 0
  excelize.cellInRange           cell.go:1691
  excelize.(*xlsxWorksheet).mergeCellsParser  cell.go:1660
  excelize.(*File).getCellStringFunc          cell.go:1512
  excelize.(*File).GetCellValue               cell.go:72

OpenReader itself returns no error; the file is 1656 bytes. A1, B1 and A2 all reproduce it.

For context on how targeted this is, I ran a battery of 38 crafted files covering data validation, conditional formatting, cell and row references, number formats, cols, hyperlinks, dimension, shared strings and tables. Only the empty-ref merge cell panicked; everything else returned a clean error. The other parsing paths look well guarded.

Suggested fix

Skip the entry when the rectangle is empty, before the range test:

if len(ws.MergeCells.Cells[i].rect) == 0 {
	continue
}

Credit goes to arpitjain099.

Severity

  • CVSS Score: 6.5 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Excelize: Unbounded spinCount in agile decryption burns CPU during OpenFile

CVE-2026-107219 / GHSA-jrfj-fhj2-jjvm

More information

Details

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.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Excelize: RIGHT() on supplementary-plane text slices with a negative index and panics

CVE-2026-107218 / GHSA-8jjq-8j9w-m2v6

More information

Details

leftRight (calc.go:14236) tests the length with countUTF16String, which counts a rune above U+FFFF as 2. The RIGHT branch on 14241 then slices []rune(text) at utf8.RuneCountInString(text)-numChars, which counts it as 1. For text with N such runes the two measures are 2N and N, so any numChars between them passes the guard and gives a negative index. The numChars < 0 check at 14216 does not help, since the value that gets through is positive.

What makes it worth reporting is AutoFitColWidth, which evaluates formulas without looking like it does, so normalising an uploaded sheet is enough to reach it. One scoping correction to my own wording there: AutoFitColWidth was added in v2.11.0 and does not exist at v2.10.1, so on v2.10.1 the only reachable path is an explicit CalcCellValue.

A 6,077-byte file containing two U+1D7D9 characters in A1 and  RIGHT(A1,3)  in B1 was created and then opened in a separate program without recovery enabled:

v2.9.1    ok
v2.10.0   ok
v2.10.1   panic: slice bounds out of range [-1:]
v2.11.0   panic: slice bounds out of range [-1:]

So it is a regression, not an old defect. Commit a880146 (2026-01-16) moved the guard to countUTF16String and left the slice on the rune index, and git tag --contains gives v2.10.1 and v2.11.0 only.

RIGHT only. RIGHTB reaches the same function but takes the byte branch at 14225, which is internally consistent, and I probed MID and MIDB from 1 to 5 with no panic. It is the same negative-index family as GHSA-fx5j-qcqg-grpf and GHSA-48hm-4h8j-58fg, though those are shared-string lookups in the reader rather than a unit mismatch in the formula library.

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Excelize ColumnNameToNumber: int64 overflow yields an out-of-domain coordinate with nil error, causing negative slice index panic on r="0" rows

CVE-2026-107217 / GHSA-c85p-xxjj-2r75

More information

Details

Summary

ColumnNameToNumber (lib.go:220-237) accumulates the bijective base-26 value of a column name in an int64 with only an upper-bound check (col > MaxColumns) applied after the loop and no overflow detection. A 14-letter column name whose true value is 3·2⁶⁴ — e.g. VGWQHXLSDVIKWV — wraps to col = 0 and passes the guard, so CellNameToCoordinates("VGWQHXLSDVIKWV1") returns (col=0, row=1, err=nil).

When normalizing a r="0" row, checkSheetR0 (excelize.go:417-443, called from checkSheet at excelize.go:405) runs its checkRow closure with col = 0: colIdx := col - 1 becomes -1, and sheetData.Row[rowIdx].C[-1] (excelize.go:424) raises an unrecovered panic: runtime error: index out of range [-1], killing the host process.

Details
  • The row side of the same coordinate gate is enforced (checkRowNum at excelize.go:342-350 bounds r before the make([]xlsxRow, row) allocation; this includes the fix for GHSA-h69g-9hx6-f3v4 / CVE-2026-54063, present in the audited commit). The column side is not: checkSheet/lastRowNum/checkSheetR0 treat err == nil from CellNameToCoordinates as proof of an in-domain coordinate (excelize.go:356, :438), which is unsound because of the wrap-around above.
  • The same unsound gate also feeds ws.SheetData.Row[rowIdx].C[colNum-1] in xlsxWorksheet.checkRow (rows.go:969): a row combining a valid large column (e.g. XFD1) with an overflowed column panics identically.
  • Reachable from any workSheetReader-based API on an attacker-supplied worksheet: GetCellValue, GetCellFormula, SetCellValue, GetMergeCells, GetSheetDimension, GetColWidth, AddTable, etc.
  • Probe on pristine master: ColumnNameToNumber("VGWQHXLSDVIKWV") returns (0, nil).
  • This is a distinct root cause from GHSA-h69g-9hx6-f3v4 (row-index allocation): different mechanism (int64 wrap-around → negative index, not oversized allocation), different sink, different fix.
PoC

A standalone program (public API only) was provided to the maintainer by email (3-column-overflow): it builds a workbook in memory whose xl/worksheets/sheet1.xml contains <sheetData><row r="0"><c r="VGWQHXLSDVIKWV1" t="inlineStr"><is><t>pwn</t></is></c></row></sheetData> (<1 KB of attacker XML), calls OpenReader, then GetCellValue("Sheet1", "A1") → PANIC_REPRODUCED: runtime error: index out of range [-1] on master ecd99d761fe0 (2026-09-08). With the proposed patch the same program prints NO_PANIC_BLOCKED.

Impact

A <1 KB crafted .xlsx crashes any service that opens a user-supplied spreadsheet and reads it — upload processing, mail-scanning pipelines, spreadsheet conversion endpoints. Remote, unauthenticated, no privileges.

Proposed fix

Bound the accumulated value inside the loop: check col > MaxColumns after each digit. Every digit is at least 1, so any name whose true value exceeds MaxColumns crosses the bound inside the loop, before the accumulation can wrap or overflow — this provably covers all cases, including wraps that would land back inside [1, MaxColumns]. A complete patch has been provided to the maintainer.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Excelize ANCHORARRAY: mutually-referencing array formulas recurse unboundedly via re-entrant CalcCellValue, causing a fatal stack overflow

CVE-2026-107216 / GHSA-wp2g-vpjj-g53r

More information

Details

Summary

ANCHORARRAY (calc.go:15137 on current master) evaluates each cell of the referenced spill range by calling the exported CalcCellValue, which unconditionally constructs a fresh calcContext — fresh entry marker, fresh iterations map, full MaxCalcIterations budget (calc.go:896-900). The circular-reference control only exists within one context: the entry-exclusion marker and per-ref iteration budget are fields of that single context, and completion-based caching (formulaArgCache/calcRawCache) only ever stores results of evaluations that finish.

During a pure cycle no nested evaluation ever finishes, so nothing is ever cached to break the recursion, and each hop re-arms the entire budget. Two ordinary, Excel-legal constructs in an attacker-supplied workbook are enough:

  • A1 (dynamic array formula, ref A1:A1): _xlfn.ANCHORARRAY($B$1)
  • B1 (dynamic array formula, ref B1:B1): _xlfn.ANCHORARRAY($A$1)

→ CalcCellValue → calcCellValue → evalInfixExp → parseReference → cellResolver → … → ANCHORARRAY → CalcCellValue → … forever, ending in a fatal, unrecoverable Go runtime error: runtime: goroutine stack exceeds …-byte limit / fatal error: stack overflow. Go stack overflows cannot be recovered — the whole process aborts.

Details
  • The terminating edge the iterations gate is supposed to provide does not exist across contexts: there is no in-flight tracking shared between nested CalcCellValue calls.
  • Both formulas are ordinary Excel-legal constructs; no exotic XML is required.
  • Excelize's own APIs reach formula evaluation on untrusted cells implicitly (e.g. pivotTable.go:538, picture.go:985/1141, col.go:892), so a service that merely adds a pivot table or a picture over such a workbook dies.
  • No option value prevents it: MaxCalcIterations is irrelevant because every hop gets a fresh budget.
  • Measured: a 64 MB stack budget is exhausted in ~0.09 s; the ~1 GB default in ~1–2 s.
PoC

A standalone program (public API only) was provided to the maintainer by email (4-anchorarray-recursion): NewFile + SetCellFormula with FormulaOpts{Type: array, Ref: A1:A1 / B1:B1}, then CalcCellValue("Sheet1","A1"). On master ecd99d761fe0 (2026-09-08) the process aborts with fatal error: stack overflow; with the proposed patch the cycle terminates normally (CYCLE_TERMINATED) and existing calc tests pass.

Impact

An attacker ships a workbook containing the two formulas; any service that evaluates a formula over those cells — directly via CalcCellValue, or implicitly via AddPivotTable / AddPicture / auto-fit — aborts. Remote, unauthenticated, process-fatal, no configuration prevents it.

Proposed fix

Evaluate spill-range cells through the current calculation context — fn.f.cellResolver(fn.ctx, …) instead of the exported CalcCellValue — so the entry check and iterations gate of the running calculation apply. cellResolver returns the typed value directly (dropping a string round-trip); an ArgEmpty → "" shim preserves the existing ToNumber behavior for empty spill cells, and a fresh-context fallback covers the legacy nil-ctx test paths. A complete patch has been provided to the maintainer.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Excelize: extractPart allocates attacker-controlled, unbounded and negative-sized buffers from CFB directory entries: remote panic / OOM DoS

CVE-2026-107215 / GHSA-x2q3-8cjh-766f

More information

Details

Summary

extractPart allocates directly from the mscfb directory-entry size with no clamping (crypt.go:198, same missing bound at crypt.go:204):

buf := make([]byte, entry.Size)

entry.Size is the raw streamSize field from the attacker-controlled CFB directory entry (mscfb v1.0.8 fixFile, file.go:109-120: full uint64 → int64 for major version 4, low uint32 for v3). mscfb only detects short sector chains later, inside File.Read (file.go:485-489 "emergency brake") — i.e. after the allocation. The zip path already enforces UnzipSizeLimit, and the KDF path bounds work with maxSpinCount; this path consults no limit at all.

Details

Two consequences, both execution-confirmed against pristine master (ecd99d761fe0, 2026-09-08):

  1. Hard crash: a version-4 CFB declaring streamSize = 0xFFFFFFFFFFFFFFFF yields entry.Size == -1 → panic: runtime error: makeslice: len out of range, which escapes Decrypt (openReaderAt converts errors, not panics, excelize.go:210-214) and kills the process.
  2. Memory exhaustion: any CFB (v3 suffices) declaring streamSize up to 0xFFFFFFFF forces up to 4 GiB of zeroed allocation from a ~12 KB file — an amplification factor of ~350,000×, trivially repeated per request in memory-limited deployments.

Call path: OpenFile/OpenReader/OpenBytes → openReaderAt (excelize.go:208-215, OLE magic sniff) → Decrypt (crypt.go:145-150) → extractPart (crypt.go:198).

PoC

A standalone program (public API only) was provided to the maintainer by email (2-extractpart-oom): it builds a valid-enough v4 (4096-byte sector) CFB — header (signature, sector shift 0x0C, DIFAT[0]=1), one directory sector with Root Entry (typeID 5, child=1) and a stream entry EncryptionInfo (objectType=2, startingSector=endOfChain, streamSize=0xFFFFFFFFFFFFFFFF). mscfb.New succeeds, doc.Next() returns the entry, and extractPart calls make([]byte, -1) before any chain validation. On master ecd99d761fe0 the program prints panic: runtime error: makeslice: len out of range; with the proposed patch it prints BLOCKED. An -oom flag demonstrates the 4 GiB allocation variant with streamSize = 0xFFFFFFFF.

Impact

An attacker uploads any file starting with the OLE signature D0 CF 11 E0 A1 B1 1A E1 (~12 KB is enough) to a service that calls excelize.OpenFile/OpenReader/OpenBytes on it (or calls Decrypt directly): remote, unauthenticated process crash (hard panic) or forced 4 GiB allocation per request (OOM) with a ~350,000× amplification factor.

Proposed fix

Bound the declared stream size before allocating in extractPart: reject negative sizes and sizes above a sane policy cap (1 GiB is far above any real encrypted-workbook part) with ErrWorkbookFileFormat, so malformed CFBs are rejected as errors instead of panicking or OOMing. A complete patch has been provided to the maintainer; verified that the patch blocks the PoC while legitimate Encrypt() output still opens.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Excelize Decrypt: unrecoverable panics on malformed OLE/CFB encrypted workbooks

CVE-2026-107214 / GHSA-2j4c-ffch-9f23

More information

Details

Summary

Any file whose first 8 bytes are the OLE compound-file signature (D0 CF 11 E0 A1 B1 1A E1) is routed by OpenFile/OpenReader/OpenBytes → openReaderAt → Decrypt. The version dispatch only guarantees len(EncryptionInfo) >= 4 before handing attacker-controlled EncryptionInfo/EncryptedPackage buffers to standardDecrypt/agileDecrypt, and no callee validates structure. Malformed but version-valid content therefore fails as an unrecovered runtime panic instead of an error, terminating the calling process.

Details

All panic classes below were execution-confirmed against pristine master (ecd99d761fe0, 2026-09-08). excelize.go:211-213 maps Decrypt errors to ErrWorkbookFileFormat, but panics bypass that path and kill the process.

# Malformed input Panic Site
1 standard, len(EncryptionInfo) 4–11 slice bounds [:12] crypt.go:238
2 standard, attacker-controlled headerSize uint32 slice bounds [12:12+headerSize] / fixed-offset header reads crypt.go:238-249
3 standard, verifier remainder < 72 (AES) / 60 (RC4) bytes slice bounds in standardEncryptionVerifier crypt.go:282-295
4 standard, header.KeySize = 0xFFFFFFFF slice bounds [:536870911] with capacity 48 crypt.go:321
5 standard, EncryptedPackage stream missing/short slice bounds [8:0] crypt.go:268
6 agile, len(EncryptionInfo) 4–7 slice bounds [8:4] crypt.go:407
7 agile, valid XML without <keyEncryptors> index out of range [0] with length 0 crypt.go:416, 433
8 agile, saltValue decoded length ≠ AES block cipher.NewCBCDecrypter: IV length must equal block size crypt.go:425 → 512
9 any, keyData blockSize="0" integer divide by zero crypt.go:539

Note the asymmetry pinpointing the missing constraint: the agile path already checks len(EncryptedPackage) >= 8 (crypt.go:520-523) but the standard path does not (#​5). Existing tests only cover the error paths (short <4 bytes → ErrUnknownEncryptMechanism, bad XML, base64 errors), never these panic paths.

PoC

Standalone programs (public API only, inputs built in memory) were provided to the maintainer by email: 1-decrypt-panic builds seven malformed CFB containers and shows each panic escaping the public Decrypt API plus one end-to-end OpenReader crash. All cases print PANIC on master and BLOCKED with the proposed patch. A regression guard proves legitimate decryption is unaffected: a workbook encrypted with the package's own Encrypt() still opens through the same code path.

(A separate advisory covers the unbounded/negative allocation in extractPart.)

Impact

Any service that calls OpenFile/OpenReader/OpenBytes on untrusted input (upload processing, mail scanning, spreadsheet conversion) can be killed remotely and without authentication by a file of ~100 bytes to ~3 KB. No password is required — panics occur during structural/parameter handling before successful decryption. Site variety means filtering one pattern does not help.

Proposed fix

A recover() boundary in Decrypt mapping any panic to ErrWorkbookFileFormat (restores the documented error-routing contract; legitimate standard/agile decryption unaffected). A complete patch has been provided to the maintainer; per-site length validation is recommended as defense in depth.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Excelize: Nil-pointer dereference in GetSlicers when a worksheet has extLst present but no drawing element

CVE-2026-107213 / GHSA-r7x5-4969-99p7

More information

Details

Summary

GetSlicers guards only if ws.ExtLst == nil { return } (slicer.go:816-818) and then immediately dereferences ws.Drawing.RID with no nil check on ws.Drawing itself. Drawing and ExtLst are two independently optional child elements of in xl/worksheets/sheetN.xml, populated separately by encoding/xml depending on whether each tag is present. I executed a PoC: took a plain NewFile() workbook (no drawing, no slicer), saved it, then injected a bare <extLst></extLst> immediately before </worksheet> in xl/worksheets/sheet1.xml (no other change, no drawing element present) and called GetSlicers. Result: runtime error: invalid memory address or nil pointer dereference, confirmed at the ws.Drawing.RID line via stack trace.

Reachability / who can trigger this

Unauthenticated: any application that opens an untrusted .xlsx and calls the public File.GetSlicers(sheet) API. The trigger is a single empty XML tag with no valid slicer or drawing content required at all, making it an even smaller/simpler payload than candidate 1.

Proof of Concept / Reproduction

Method:

  1. Reused the existing clone at C:\Users\vatsa\AppData\Local\Temp\claude\D--\59901fa2-b549-40e1-a433-30c8a3d01718\scratchpad\CVE-Hunt-10k\repos\qax-os__excelize (origin=https://github.com/qax-os/excelize.git, branch master up to date, commit e81f05008b33232151a58f06474fad5f70c4d060 dated 2026-09-27, git describe=v2.11.0-42-ge81f050, i.e. 42 commits past the v2.11.0 tag). 2) Manually re-read the cited source myself (not trusting the claim): slicer.go:805-820 (GetSlicers) and xmlWorksheet.go:21-72 (xlsxWorksheet struct + xlsxDrawing struct) -- confirmed verbatim, matches claim exactly. 3) Confirmed local toolchain: go version go1.27.0 windows/amd64 (/c/Program Files/Go/bin/go). 4) Built the whole package with go build ./... from the repo root -- succeeded with zero errors, proving the current checkout compiles cleanly. 5) Ran the pre-existing PoC test file already present in this checkout (slicer_extlst_poc_test.go, TestGetSlicersNilDrawingPanic) via go test -run TestGetSlicersNilDrawingPanic -v .: it builds a benign excelize.NewFile() workbook, saves it, reopens it, loads the raw zip entry xl/worksheets/sheet1.xml, string-replaces </worksheet> with <extLst></extLst></worksheet> (adds nothing else, no anywhere), rebuilds the zip byte-for-byte otherwise unchanged (rezipReplacing helper, plain archive/zip re-encode), reopens the crafted file with excelize.OpenReader, and calls the public GetSlicers("Sheet1") API inside a recover(). 6) For a fully independent, non-test-harness reproduction, I additionally wrote and built my own separate standalone Go module+program from scratch (excelize-nilptr-repro/{go.mod,main.go} in my scratchpad dir) that imports the real, unmodified excelize package as an external library dependency via a replace github.com/xuri/excelize/v2 => ../CVE-Hunt-10k/repos/qax-os__excelize directive (no copy-pasted/reimplemented function -- the actual library code, used through its real public API from a separate consumer program, simulating "any application that opens an untrusted .xlsx"). This program performs the identical craft-and-open sequence but calls GetSlicers with NO recover() at all. Built with go build -o repro.exe . (succeeded) and ran ./repro.exe directly, observing an unhandled process crash.

Evidence:
SOURCE VERIFICATION (current HEAD, read directly): slicer.go:816-820 is exactly as claimed -- if ws.ExtLst == nil { return slicers, err } followed immediately by target := f.getSheetRelationshipsTargetByID(sheet, ws.Drawing.RID) with no nil check on ws.Drawing. xmlWorksheet.go:54 Drawing *xlsxDrawing xml:"drawing" and xmlWorksheet.go:64 `ExtLst *xlsxExtLst `xml:"extLst" are both independently-optional pointer fields on xlsxWorksheet, populated only when their respective XML tag is present in the worksheet part -- confirming Drawing and ExtLst are unrelated/independent. getSheetRelationshipsTargetByID(sheet, rID string) string (sheet.go:721) takes a plain string, so ws.Drawing.RID is evaluated (dereferencing the nil pointer) at the call site itself.

RUN 1 -- existing repo test, go test -run TestGetSlicersNilDrawingPanic -v .:
=== RUN TestGetSlicersNilDrawingPanic
slicer_extlst_poc_test.go:38: original sheet1.xml: ...... (no drawing, no extLst)
slicer_extlst_poc_test.go:48: tampered sheet1.xml: ...<e

[!IMPORTANT]
✂ PR body was truncated to here.

@renovate
renovate Bot enabled auto-merge (squash) November 3, 2026 08:22
@renovate

renovate Bot commented Nov 3, 2026

Copy link
Copy Markdown
Contributor Author

ℹ️ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

  • 8 additional dependencies were updated

Details:

Package Change
golang.org/x/text v0.42.0 -> v0.43.0
github.com/richardlehane/mscfb v1.0.7 -> v1.0.9
github.com/xuri/efp v0.0.1 -> v0.0.3-0.20260924042702-217b81952dec
golang.org/x/crypto v0.55.0 -> v0.58.0
golang.org/x/net v0.58.0 -> v0.62.0
golang.org/x/sync v0.23.0 -> v0.24.0
golang.org/x/sys v0.48.0 -> v0.49.0
golang.org/x/term v0.46.0 -> v0.47.0

@renovate
renovate Bot force-pushed the renovate/go-github.com-xuri-excelize-v2-vulnerability branch 2 times, most recently from d653dcd to eee1bd8 Compare November 7, 2026 00:44
@renovate
renovate Bot force-pushed the renovate/go-github.com-xuri-excelize-v2-vulnerability branch from eee1bd8 to c1b018b Compare November 8, 2026 04:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

patch security version-update

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants