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.

References

• GHSA-rxcj-4pj5-74gr
• qax-os/excelize#2375
• qax-os/excelize@be7a163