CVE-2026-113008 is filed against Google Chrome, but the vulnerable code sits in Chromium's Autofill path. Distributors, browser forks, and Electron-like products can share source ancestry without sharing a release number. A fixed desktop Chrome build is therefore a strong signal, not proof that every downstream product is patched.

The CNA lists Google Chrome before 156.0.8078.47 as affected. Google's stable update supplied 156.0.8078.47 for Linux and 156.0.8078.47/.48 for Windows and macOS. The Chromium issue describes stale AutofillExternalDelegate::last_query_ state and a race in Transactions Platform. The fix replaces the mutable destination with FormGlobalId and FieldGlobalId values bound to the suggestion callback.

Why a fork can diverge

A downstream project may merge Chromium security patches on a different schedule, backport the source change without adopting the same version string, or disable the affected feature entirely. It may also maintain a separate UI or embed Chromium in an application where Autofill behaves differently.

The CVE's product field names Google Chrome. A responsible downstream vendor must publish its own applicability statement. An administrator should not infer that every product with a Chromium version number is fixed because the upstream commit exists.

Verification points

Check the browser vendor or operating-system vendor's security notice for CVE-2026-113008. Confirm the fixed package or application build, the affected platforms, and whether the vendor carried the Autofill behavior change. For Linux distributions, preserve the distribution package version and advisory mapping; do not compare it as if it were the upstream Chrome build number.

For embedded Chromium components, identify whether the application exposes Autofill Transactions Platform to untrusted content. The renderer-compromise and user-interaction prerequisites still matter, but application architecture determines whether those conditions are plausible.

The upstream fix commit 0025db05ef5dca3336d9821e6eb7944ef7e5e49d is useful evidence for vendor tracking. It removes reliance on the stale last_query_ member and places the final behavior behind a kill switch. Distributors should know when that change, or an equivalent fix, reaches their build.

Update and inventory tasks

  • Verify managed Google Chrome builds on every desktop platform.

  • Ask secondary browser vendors for their CVE application status.

  • Track Linux distribution or application packages by their own advisory IDs.

  • Preserve the difference between upstream Chromium and branded release versions.

  • Check whether embedded browser components expose the affected Autofill behavior.

External product counts do not solve this problem. A query for Chrome can provide broad context, but it cannot establish that a downstream application contains the vulnerable callback path. The official vendor record remains the authoritative source for each product.

Remediation context

The upstream code change binds form and field identity to the accepted suggestion. If the same suggestion is selected, the browser should not use a later request's destination. A downstream build can be considered fixed only when its vendor confirms that semantic change or an equivalent mitigation.

Where a product cannot update immediately, disabling payment Autofill on high-risk deployments can reduce the available data. The renderer-compromise prerequisite should also be addressed through browser isolation, endpoint monitoring, and reduction of untrusted frames.

Reporting discipline

A fleet report should name the product and exact build, cite the vendor advisory, and separate confirmed fixed devices from unverified ones. It should not merge Chrome, Chromium, and embedded applications into a single patch count. That aggregation can create false assurance even when every underlying record is accurate.

CVE-2026-113008 is fixed in a specific Chrome branch, and the source change is identifiable. The downstream question remains separate: which products actually adopted the fix, and which still expose an Autofill path with stale callback state?

References