CVE-2026-8532

Overview

High

Severity

8.8

CVSS

No

Exploited ITW

Fixed

Fix Status

ImpactInteger overflow in XML

DescriptionInteger overflow in XML

ComponentXML

Bug ClassInteger Overflow

Action tierwatch — corruption primitive but gated (uncommon) — not default-reachable — factors set by independent review by AI
Computed by PatchGap's deterministic exploitability ruler from the fixing commit. patch-now = RCE-class & attacker-reachable in a default config, or exploited in the wild; watch = real security signal below that bar; noise = no security relevance.

Independent review by AIConfirmed
Reviewer notes: none false. After the wrapped REALLOC (:3507-3512) the loop re-enters XmlConvert (:3497) rather than reaching :3517 directly, so the :3517 OOB terminator write is conditional. Chrome consumer/process not shown. Needs a >SIZE_MAX/2 buffer.
A second, independent AI reviewer (not a human) re-derived this analysis from the fixing commit and the vendor advisory, looking for errors.

Tracker492812194

Fix commit9c2d990389e6 (libexpat (upstream, via Chromium mirror)) +2/-0

CWECWE-472

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

CISA KEVNot listed

CreditedGoogle

Reported2026-03-14 (per vendor advisory)

Fix landed2025-10-03 (public git)

Disclosed2026-05-12

Patch gap221 days — fix public in source before the advisory

Background

libexpat: The streaming XML parser vendored in Chromium as third_party/expat, whose README/METADATA version 2.7.1 the scanner report flags as affected by CVE-2026-25210.
`TAG` buffer: Every open start tag has a TAG record whose buf / bufEnd hold the converted element name, starting at INIT_TAG_BUF_SIZE bytes (expat/lib/xmlparse.c:3475-3480).
`XmlConvert`: Converts the raw tag name from the input encoding into XML_Char, writing through toPtr up to the limit (ICHAR *)tag->bufEnd - 1 (:3497-3498).
`SIZE_MAX`: The largest size_t value, so multiplying any size above SIZE_MAX / 2 by 2 wraps around.

Root Cause Analysis

Re-analyzed on 2026-10-03 against the actual fix commit 9c2d990389e6. An earlier analysis was withdrawn because it had been written against a dependency roll (6154446fccef).

For XML_TOK_START_TAG_NO_ATTS / XML_TOK_START_TAG_WITH_ATTS tokens, the parser converts the raw tag name into tag->buf in a loop (expat/lib/xmlparse.c:3490-3515). The enclosing function is doContent, which is not shown in the excerpt but is named in libexpat’s changelog for CVE-2026-25210 (inferred). When the converted name does not fit, the loop doubles the buffer size with const size_t bufSize = (size_t)(tag->bufEnd - tag->buf) * 2; (:3505) and has no overflow check. If the current size is above SIZE_MAX / 2, bufSize wraps to a smaller value, possibly zero, and REALLOC (:3507) can succeed with a block smaller than the data already converted. The code then sets tag->bufEnd = temp + bufSize (:3511) and toPtr = (XML_Char *)temp + convLen (:3512), so toPtr can point past the new allocation. The later write *toPtr = XML_T('\0') (:3517) and any further XmlConvert output would then land out of bounds (inferred for the converter’s internal limit handling).

The fix adds if (SIZE_MAX / 2 < (size_t)(tag->bufEnd - tag->buf)) return XML_ERROR_NO_MEMORY; just before the multiplication. This only makes the code stricter: a doubling that would wrap is rejected with an error, and nothing else is accepted that was not accepted before.

Key insight

The tag-name buffer was grown by doubling its size without checking that the doubled size_t fits, so a wrapped, smaller size could be passed to REALLOC while the code went on assuming the buffer had grown. The fix rejects the doubling when it would exceed SIZE_MAX.

Attack Path

Supply XML to a libexpat consumer The attacker gets XML parsed by a component that uses Chromium’s bundled expat. Which Chrome component parses untrusted XML with expat is not shown in the material (inferred).
Use an extremely long element name A start tag whose converted name keeps doubling tag->buf (:3505-3511) until its size passes SIZE_MAX / 2. That needs more than half the address space, so in practice only 32-bit builds come into question (inferred).
Wrapped reallocation bufSize wraps, REALLOC returns a block that is too small, and toPtr is placed beyond it (:3512).
Out-of-bounds write Further conversion output or the terminator write at :3517 lands outside the allocation (inferred).

Impact Assessment

If reached, this can cause heap memory corruption in whichever Chrome process runs libexpat on attacker-supplied XML. The material does not identify that process (inferred). The precondition is a single tag name large enough that its buffer passes SIZE_MAX / 2 bytes, which is unrealistic on 64-bit and very hard on 32-bit (inferred). The vendor rates it high severity, and the advisory does not report in-the-wild exploitation.

Files Changed

expat/lib/xmlparse.c

Audit Directions

Geometric buffer growth
Look for other size * 2 / size << 1 growth patterns in expat/lib/xmlparse.c (attribute arrays, string pools, namespace bindings), and make sure each one has a SIZE_MAX-based guard before the multiplication.
`int` length truncation next to `size_t` growth
convLen = (int)(toPtr - (XML_Char *)tag->buf) (:3499) narrows a pointer difference to int. Check whether lengths above INT_MAX can produce a negative or truncated strLen or offset.
Vendored-library version drift
Track third_party/expat against upstream security releases. This issue was found by version matching, not by a Chromium-side report.

Patch

view commit

diff --git a/expat/lib/xmlparse.c b/expat/lib/xmlparse.c
index ee18a87..d8c54c3 100644
--- a/expat/lib/xmlparse.c
+++ b/expat/lib/xmlparse.c
@@ -3502,6 +3502,8 @@
             tag->name.strLen = convLen;
             break;
           }
+          if (SIZE_MAX / 2 < (size_t)(tag->bufEnd - tag->buf))
+            return XML_ERROR_NO_MEMORY;
           const size_t bufSize = (size_t)(tag->bufEnd - tag->buf) * 2;
           {
             char *temp = REALLOC(parser, tag->buf, bufSize);

Loading diff…

Original Bug Report

reported by au...@google.com

Vulnerability: CVE-2026-25210 affecting GitOnBorg::chromium::chromium::src

Hello,

This is a vulnerability bug regarding packages in:

Git-on-Borg: - https://chromium.git.corp.google.com/chromium/src

A security vulnerability in one of your packages has been detected by our automated security scanner using information in your package’s metadata file. See go/vuln-monitoring for more details.

Software name and version number matching can be imprecise, i.e. this vulnerability might not apply to your package - see Remediation Requirements for how to proceed.

Vulnerabilities

Vulnerabilities were detected by matching your package version against vulnerability feeds.

Your package version was sourced from Ecosystem Specific Identifier (ESI) or Common Platform Enumeration (CPE) identifiers in the following files:

README.* or METADATA file in this directory

As of now, the following advisories were detected in your package:

Identifier	Advisory	Current Version	Recommended Action
`cpe:2.3:a:libexpat_project:libexpat:2.7.1:::::::*`	CVE-2026-25210	2.7.1	Upgrade to version 2.7.4 or later

Remediation Requirements

Update the package past the vulnerable version(s) listed above.
If the vulnerability is a true positive but a fix cannot be implemented within the SLO, file an exception request at: go/vuln-slo-exceptions.
If you cannot update due to technical blockers, AND the package is not affected by the vulnerability, follow the steps in: go/third-party-package-remediation-playbook#not-affected.
Update the CPE and/or Ecosystem Specific Identifiers (ESI) versions to reflect the updated version.
Mark the bug as Fixed once remediation is complete. Ensure remediation is complete within the SLO specified at go/vuln-slo. It is expected that this P1 vulnerability is mitigated within 2 weeks.

If you cannot update past the vulnerable versions, see go/third-party-package-remediation-playbook for instructions on how to handle back-ported patches, false positives, and other special cases.

Support & Feedback

See go/third-party-package-vuln-support for FAQ and support paths.

Please use this Vulnstore link to see the latest detection times of the vulnerabilities associated with this bug and if vulnerabilities are still being detected. We aim to scan daily, however the frequency may differ from scanner to scanner (in Vulnstore, click on the title and switch to the Tracking tab to see all detection timestamps).

<summary>Template Debug Information</summary>

Template identifier: tpp

</details>

Reported for SCARAB Remediation ID: 21354f76-4d31-4e8e-9410-781637a918ad

View on issue tracker

Links in the report

References

Vendor advisory Fix commit Bug tracker NVD