Chrome Fixed 11 Critical Flaws Before the CVE Databases Could Catch Up

Update, 30 September 2026

The current desktop deployment targets are 154.0.8037.92 on Linux and 154.0.8037.92 or .93 on Windows and macOS. Google also released Android build 154.0.8037.92. Deploy the applicable build or a later supported release, then verify the running version. Google’s desktop notice does not report active exploitation of the new flaw; critical severity is not evidence of an active campaign.

On 22 September, Google shipped Chrome 154 with 108 security fixes, including 11 vulnerabilities it classified as critical. When BlackTree published this analysis on 24 September, some identifiers were still missing from, or incompletely represented in, the public CVE services that many vulnerability scanners and security teams treat as their starting point.

That did not make the flaws theoretical or the update optional. The patch had arrived before every downstream catalogue, severity feed and asset-management workflow had caught up.

For defenders, the reliable control remains version-based. Use the updated deployment targets below and verify that browsers have actually relaunched into the fixed build. The earlier .57/.58 builds are not the target for the 29 September follow-up.

Seven of the critical flaws sit in the graphics path

The concentration in the original 22 September release was difficult to ignore. Seven of its 11 critical vulnerabilities affect ANGLE, WebGL or GPU processing. Those components handle complex, attacker-influenced content close to memory-management boundaries, making them important patching priorities even while detailed bug records remain restricted.

Google did not publish exploit-chain details in the original release notice. Its normal policy is to restrict bug information until most users have received the fix, or longer when another project depends on the same vulnerable third-party library.

The absence of technical detail should therefore be treated as a deliberate protection measure, not evidence that the vulnerabilities are unimportant.

Four more critical flaws affect browser state and interface components

The remaining critical entries from the 22 September release span service workers and browser interface behaviour:

All four are use-after-free vulnerabilities. That class of memory-safety error can create serious security consequences, but BlackTree found no active-exploitation statement for these bugs in Google’s 22 September release notice.

That boundary matters. Eleven critical ratings justify urgent deployment. They do not justify claiming an active attack campaign without evidence.

The database delay exposed a real operational blind spot

Many patching and exposure-management systems are organised around CVE ingestion. They wait for a record, match it to software inventory, attach a severity score and then open a remediation task.

The original release illustrates the weakness in that sequence. A browser can already be vulnerable, a fixed version can already be available, and the vendor can already have named the flaws while the canonical records and NVD enrichment remain unavailable or incomplete.

During that gap:

• a CVE-based scanner may report nothing;
• an asset dashboard may not raise Chrome’s priority;
• an SLA clock may not start;
• a security team may mistake missing metadata for missing risk; and
• a managed browser may remain open for days because installation occurred without a relaunch.

The remedy is not to abandon CVE data. It is to stop treating it as the only trigger. Vendor release monitoring and minimum-version enforcement need to operate alongside vulnerability-database ingestion.

What organisations should do now

1. Set the minimum desktop version. For the 29 September Stable release, deploy Chrome 154.0.8037.92 on Linux and 154.0.8037.92 or .93 on Windows and macOS, or a later vendor-supported release.
2. Verify the running version, not merely the installed package. Chrome commonly completes an update only after the browser restarts. Measure active versions and stale sessions.
3. Prioritise privileged browsing environments. Update administrative workstations, jump systems, developer endpoints and devices used for cloud or identity administration first.
4. Use version-based detection during the CVE gap. Query browser inventory directly and open remediation work from the vendor’s fixed-build boundary.
5. Check other Chromium-based products separately. A Chrome fix does not prove that Edge, Brave, Electron applications or embedded Chromium runtimes have shipped and activated the same remediation.
6. Do not wait for a CVSS score. Google’s critical classification and the affected memory-safety components provide enough information to justify accelerated deployment.
7. Record the evidence source. Link remediation tickets to Google’s release notice and issue references so the decision remains auditable when the CVE records later populate.

Google announced Chrome for Android 154.0.8037.92 on 29 September, with distribution through Google Play over the following days. Verify that build or a later supported release. Google says Android releases contain the same security fixes as their corresponding desktop release unless otherwise noted. Mobile-device teams should verify deployment rather than assuming automatic updates have completed.

The useful signal arrived before the database entry

The striking part of the original release was not only the number of fixes. It was the order in which defenders received the information.

Google supplied the affected product, fixed versions, severity, flaw type, component and internal issue reference. That was enough to act. Canonical CVE and NVD records can improve correlation, but they should not delay a decision already supported by vendor evidence.

A mature vulnerability programme should be able to patch from vendor evidence first and reconcile the identifiers afterwards. Otherwise, the organisation is not managing vulnerabilities. It is waiting for a database to give it permission.

Sources

• Google Chrome Releases, Stable Channel Update for Desktop, published 29 September 2026.
• Google Chrome Releases, Chrome for Android Update, published 29 September 2026.
• Google Chrome Releases, Stable Channel Update for Desktop, published 22 September 2026.
• Google Chrome Releases, Chrome for Android Update, published 22 September 2026.
• CERT-FR, Multiple vulnerabilities in Google Chrome, published 23 September 2026.