GHSA-rxcj-4pj5-74gr: Out-of-bounds Read
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:
go 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:
go 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:
go 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 [ContentTypes].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:
xml <conditionalFormatting sqref="A1"><cfRule type="cellIs" operator="equal" priority="1" dxfId="0"/></conditionalFormatting>
for dataBar:
xml <conditionalFormatting sqref="A1"><cfRule type="dataBar" priority="1"><dataBar></dataBar></cfRule></conditionalFormatting>
and for colorScale:
xml <conditionalFormatting sqref="A1"><cfRule type="colorScale" priority="1"/></conditionalFormatting>
Observed against master d552a7e on go1.26.5:
text 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/xuri/excelize/v2to a version that resolves this vulnerability.Fixed in 2.11.1-0.20260812075026-be7a16390fa6 - Compensating control
Harden conditional-format extraction by validating malformed rules before indexing: length-check c.Formula before styles.go:3003 and return the rule with an empty value when absent; nil-check c.ColorScale before styles.go:3132 and length-check ColorScale.Cfvo before indexing; and alongside the existing nil check at styles.go:3186-3190, length-check DataBar.Cfvo and DataBar.Color before indexing. Skip malformed rules rather than allowing GetConditionalFormats to panic.
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using excelize/v2 are exposed when they process a workbook and call GetConditionalFormats on worksheet XML containing malformed conditional-formatting rules. The affected rule types are cellIs, dataBar, and colorScale.
What does an attacker need to cause the failure?
An attacker needs to supply a crafted workbook with conditional-formatting elements missing children that the parser assumes are present. Processing that workbook through GetConditionalFormats can trigger an out-of-bounds access or nil-pointer dereference and panic the application.
How can I tell whether this has affected my application?
Look for panics while calling GetConditionalFormats on workbooks containing conditional-formatting rules. Relevant malformed inputs include a cellIs rule without a formula child and a colorScale rule without a colorScale child or with insufficient Cfvo entries.
What can be done before a fix is applied?
Avoid calling GetConditionalFormats on untrusted workbooks, or reject workbooks with malformed conditional-formatting XML before they reach that function. The provided data does not identify a fixed release version.