Chrome 156 Stable Fixes 52 Security Bugs, 4 Critical

Google has promoted Chrome 156 to the stable desktop channel, and it's a far bigger security update than the one that preceded it. The new build — 156.0.8078.73/.74 for Windows and Mac, and 156.0.8078.73 for Linux — started rolling out on Tuesday, October 27, 2026, and according to Google's own release notes it closes 52 security vulnerabilities, four of them rated Critical. That's more than five times the fix count in Chrome 155, which shipped just 12 days earlier. Google's advisory does not flag any of the 52 bugs as being exploited in the wild.

What's actually new in Chrome 156

Chrome's release channels move in overlapping stages, so it's worth being precise about what changed this week. As Pandromeda reported when Chrome 155 closed its own critical Prerender flaw on October 15, Chrome 156 was at that point still a staged "Early Stable" build reaching a small slice of users. That staged rollout is now over: as of October 27, 2026, Chrome 156 is the full desktop Stable release, per the Chrome Releases blog.

The version strings are specific and worth noting if you're checking your own install: 156.0.8078.73 and .74 for Windows and Mac (the two numbers reflect minor build variations across machines), and 156.0.8078.73 for Linux. Google says the rollout will continue "over the coming days/weeks," which is standard language meaning not every desktop will see the update on day one — Chrome's auto-update mechanism pushes it out gradually rather than all at once.

A companion post from Google the same day confirms Chrome 156 (156.0.8078.73) is also rolling out to Android via Google Play, carrying the same security fixes as the desktop build. Google says that release includes general stability and performance improvements on top of the security patches.

The four Critical-severity bugs, explained

Google rates each fixed vulnerability by severity, and "Critical" is reserved for bugs that could let an attacker execute arbitrary code outside Chrome's sandbox with little or no user interaction. Chrome 156 closes four of them, all credited to the same external researcher working independently of Google:

• CVE-2026-118306 — memory corruption in FileSystem, reported October 7, 2026.
• CVE-2026-118331 — improper input validation in FileAPI, reported October 11, 2026.
• CVE-2026-118348 — improper input validation in Skia (Chrome's graphics rendering library), reported October 17, 2026.
• CVE-2026-118344 — a use-after-free bug in Layout, also reported October 17, 2026.

Google's advisory lists the researcher as Xinyang Ge, with two of the four Critical reports — the FileSystem and FileAPI bugs — specifically credited as "assisted by Claude." As is standard Chrome practice, Google is withholding most bug-tracker details until a majority of users have updated, so independent technical write-ups of these specific flaws aren't yet public — the fixed code itself is visible in the public Chromium source git log for this build range. None of the four is marked in Google's release notes as having a known public exploit or active attack.

The other 48: High and Medium severity fixes

Beyond the four Critical bugs, Chrome 156 fixes 46 High-severity issues and 2 rated Medium. The High-severity list is long and touches a wide swath of the browser's codebase — V8 (Chrome's JavaScript engine), Skia (its 2D graphics rendering library), PDFium, ANGLE (the layer that translates Chrome's graphics calls to the underlying GPU driver), SVG handling, WebAudio, Compositing, and more. That spread is fairly typical for Chrome: the browser's attack surface is enormous, since it has to parse untrusted HTML, CSS, JavaScript, images, fonts, PDFs, and media from essentially any website on the internet, which is why Skia and V8 in particular show up repeatedly release after release. A few of the 46 are worth flagging specifically:

• CVE-2026-118328 — improper input validation in WebRTC, reported by Mozilla on October 7, 2026. WebRTC handles real-time audio/video (think video calls inside a browser tab), and cross-browser vendors reporting bugs in each other's implementations isn't unusual, since much of the underlying code is shared or standardized.
• CVE-2026-118307 and CVE-2026-118353 — two separate use-after-free bugs in Paint, Chrome's rendering pipeline for drawing pixels to the screen.
• CVE-2026-118345 and CVE-2026-118313 — use-after-free bugs in PDFium (Chrome's built-in PDF viewer) and Video, both reported by OpenAI's Codex Security team.
• CVE-2026-118318 — improper access control in V8, reported by a research intern at Seoul National University's Compsec Lab.
• CVE-2026-118304 and CVE-2026-118315 — two separate improper-input-validation bugs in SVG handling, both reported by the same independent researcher, Arni Hardarson of Neonix Security.

The two Medium-severity fixes are a memory-corruption bug in Paint (CVE-2026-118312, reported back on July 28) and a use-after-free in Animation (CVE-2026-118338). As described in Chromium's own severity guidelines, Google's scale runs Critical, High, Medium, and Low, based on what an attacker could do with the bug and how much user interaction it requires — a Critical bug typically allows code execution outside Chrome's sandbox with little to no interaction, while High-severity bugs usually still require some form of user action or additional chained flaw to be dangerous on their own.

A notable pattern: AI-assisted bug hunting shows up repeatedly

One detail stands out across Google's advisory for this release: eight of the 52 credited reports explicitly note AI involvement in finding the bug. Six are attributed to Xinyang Ge "assisted by Claude," including both FileSystem- and FileAPI-related Critical bugs plus several High-severity reports in Animation, Video, WebAudio, and Payments. Two more High-severity Paint and Media bugs are credited jointly to "Anthropic and Ada Logics." Separately, OpenAI's internal "Codex Security" team is credited with four more High-severity finds, in Turbolev, ImageCapture, Video, and PDFium.

Google doesn't editorialize on this in the post itself — it's simply how the credit lines read — but it's a useful real-world data point on how AI-assisted vulnerability research is now showing up in mainstream browser security disclosures, alongside traditional human researchers and Google's own internal team (credited simply as "Google" on more than half the High-severity entries).

It's also consistent with a broader industry pattern this year: both Anthropic and OpenAI have been publicly building out internal security-research efforts that pair their own models with human researchers to find memory-safety bugs in widely used open-source and commercial codebases, and large browsers — with their huge, memory-unsafe C++ codebases — are an obvious target. Chrome 156's credit lines are simply one dated, verifiable snapshot of that work landing in a real shipped product.

Is anything in Chrome 156 being actively exploited?

No. Google's standard practice is to flag, right in the bug list, any vulnerability it knows is being exploited in the wild — language it has used for past zero-days. No such flag appears anywhere in the Chrome 156 stable release notes, for any of the 52 fixes, Critical or otherwise, and the Chromium Security team's own page carries no separate advisory for this release either. That's a meaningful difference from some other recent software patches: for comparison, a critical Brotli decoder flaw patched in Node.js drew attention specifically because of its remote-code-execution potential, and Google itself has pushed emergency fixes for actively-exploited Chrome bugs within the same year. Chrome 156, by contrast, reads as a large but routine security update — unusually large in fix count, not unusual in urgency.

Chrome 155 vs. Chrome 156: how the two releases compare

Chrome 155 and Chrome 156 landed less than two weeks apart, but they're very different in scale. Here's how Google's own release notes for each compare:

In short: Chrome 155 was a smaller, single-headline-bug release built around one critical Prerender flaw. Chrome 156 is a much broader patch batch — more Critical bugs, far more total fixes, and a wider spread across the browser's rendering and graphics stack.

Where this fits in Google's release channels

Chrome ships on several overlapping tracks at once — Stable, Early Stable, Beta, Dev, and Extended Stable for enterprise — and it's easy to end up looking at the wrong number. As of October 27, 2026, 156.0.8078.73/.74 is the one that matters for almost everyone: the full desktop Stable build. It supersedes the staged Early Stable rollout of the same version number that had only reached a limited share of Windows and Mac users in the preceding week. You can check exactly what you're running by typing chrome://settings/help into Chrome's address bar.

This kind of staged, multi-track rollout isn't unique to Chrome. Operating system vendors follow similar patterns — Microsoft, for instance, has been pushing its own staged cumulative fixes through builds like the Windows 11 KB5127648 update, which bundled its own set of fixes and known-issue notes. The common thread: large platforms increasingly patch in waves rather than single big-bang releases, and checking your specific build number is the only reliable way to know where you actually stand.

For enterprise IT teams, there's an added wrinkle: Chrome also maintains a separate Extended Stable channel, aimed at organizations that want security fixes without the full pace of feature changes in the regular Stable channel. Extended Stable periodically catches up to the regular Stable branch in a single jump, which is why fix counts quoted for an Extended Stable update can look much larger than a single Stable release — they're bundling several releases' worth of patches at once. That's a different number from, and shouldn't be confused with, the 52-fix count Google attributes specifically to this one Stable channel update for desktop.

What's next: how to make sure you're protected

Chrome normally updates itself automatically in the background, applying the new version the next time you close and reopen the browser. If you want to confirm you're on 156.0.8078.73 (or .74) right now rather than waiting for the automatic rollout to reach your machine, do this:

1. Open Chrome and click the three-dot menu in the top-right corner.
2. Go to Help > About Google Chrome (or type chrome://settings/help directly into the address bar).
3. Chrome will check for an update automatically; if 156 is available for your platform, it will download and prompt you to relaunch.
4. Click Relaunch to finish applying the update — none of the fixes take effect until the browser restarts.

Because none of the 52 fixed bugs in this release are flagged as under active attack, there's no emergency timeline here — but given that four are Critical-severity and the fix count is unusually large for a single release, updating sooner rather than later is still the sensible move. Google's own help page for updating Chrome covers the update process in more detail, and the Google Chrome homepage has fresh installers for anyone who needs them.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage