Automated Threat Modeling

Overview of CVE-2026-119261: Improper Input Validation in Google Chrome Skia With Potential Sandbox Escape

A brief summary of CVE-2026-119261, an improper input validation flaw in Chrome's Skia graphics library that could allow code execution outside the sandbox through a crafted HTML page. Covers the fixed builds, distribution packaging status, and the version-based detection options available today.

CVE Analysis

9 min read

Gaurav Sarraf
Gaurav Sarraf

2026-11-02

Overview of CVE-2026-119261: Improper Input Validation in Google Chrome Skia With Potential Sandbox Escape
Experimental AI-Generated Content

This CVE analysis is an experimental publication that is completely AI-generated. The content may contain errors or inaccuracies and is subject to change as more information becomes available. We are continuously refining our process.

If you have feedback, questions, or notice any errors, please reach out to us.

[email protected]

Introduction

A validation flaw in Skia, the 2D graphics library that draws web content in Google Chrome, could let a remote attacker execute code outside the browser sandbox after convincing a user to open a crafted HTML page. Statcounter puts Chrome at 68.79% of worldwide browser share for October 2026, so the practical question for most organizations is whether every running copy of Chrome has restarted on the fixed build.

CVE-2026-119261 carries a CVSS 3.1 score of 9.6 (Critical), supplied by CISA ADP, while Chromium rates it High under its own severity framework. Google shipped the fix in Chrome 156.0.8078.79 on October 29, 2026. As of the dated assessments we reviewed, there is no confirmed exploitation, no public exploit, and no named threat actor. The Chromium bug itself remains restricted, so this post sticks to what the public record supports.

Technical information

Root cause

Skia is an open-source 2D graphics library that provides common APIs across hardware and software platforms, and it is the graphics engine for Chrome, ChromeOS, Android, Flutter, and other products. The CVE is classified as CWE-20, improper input validation.

Based on the advisory, the fix adds input validation to a Skia code path that previously trusted data an attacker could shape with a crafted HTML page. What the public record does not tell us:

  • The vulnerable Skia function
  • The exact malformed input structure
  • Which kind of check was missing (bounds, sizes, or parameter values)
  • Whether the bug yields a specific memory corruption primitive (CWE-20 alone does not identify one)

Chromium issue 574213633 is marked Permissions Required, and Chrome typically keeps a security bug's details and fixing change private until most users have updated. Skia also lives in its own repository and reaches Chromium through automated Roll Skia commits. The fix most likely arrived through one of those rolls, but no public source identifies which one, so there is no diff or vulnerable code we can show.

Scoring

The published vector, attributed by NVD to CISA ADP (NVD has not yet provided its own assessment):

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
  • AV:N: network attack vector
  • AC:L: low attack complexity
  • PR:N: no privileges required
  • UI:R: user interaction required
  • S:C: scope changed, consistent with impact beyond the sandbox
  • C:H/I:H/A:H: high confidentiality, integrity, and availability impact

Keep the UI:R component in mind when communicating this issue. The disclosed scenario is browser exposure through visited content, and it does not involve unattended exploitation of a server.

Why Chromium says High and CVSS says Critical

These are separate assessments and should not be used interchangeably. Chromium's severity guidelines classify some sandbox escapes as High when they require an already compromised renderer. That explains how the two frameworks can diverge, but it does not prove that this specific CVE requires a compromised renderer. The public description does not say whether additional vulnerabilities, process compromise, or platform conditions are necessary.

Attack flow

Based on the NVD description and Snyk's summary, the disclosed scenario is:

  1. The attacker prepares a crafted HTML page containing content that reaches the vulnerable Skia code path.
  2. The attacker entices a user to visit the page (user interaction is required).
  3. Chrome processes the page, and Skia handles attacker-shaped data without adequate validation.
  4. Successful exploitation could result in arbitrary code execution outside the sandbox.

Any steps between 3 and 4 are not public. We are not filling them in.

Patch information

Where the fix shipped

Google fixed CVE-2026-119261 in the Stable and Extended Stable channel update of October 29, 2026:

  • Linux: 156.0.8078.79
  • Windows and macOS: 156.0.8078.79/.80

The release post's metadata confirms these build numbers. NVD's CPE data matches: every Chrome version up to, but not including, 156.0.8078.79 is vulnerable. The CNA record shows an odd range, 156.0.8078.79 < 156.0.8078.79, which is a formatting quirk. The first fixed build is .79.

This CVE was one of 21 fixed in the same release, including CVE-2026-119271, a separate use-after-free in Skia. The patch is bundled into the browser build and cannot be applied on its own. Red Hat lists issue 574213633 as the upstream bug, and Gentoo's tracker links it next to the 156.0.8078.79 release.

Distribution packages

Distributions shipped the fix by moving to the new upstream version rather than backporting a single patch:

  • Debian trixie (security): chromium fixed in 156.0.8078.79-1~deb13u1, shipped as DSA-6605-1
  • Debian sid (unstable): chromium fixed in 156.0.8078.79-1
  • Gentoo: www-client/google-chrome fixed in 156.0.8078.79 via commit 0c32af148e5b23e0fe0214639a47b9b554cffc98 (automated version bump)

Two cautions from the tracker data:

  • Debian bookworm: bookworm security already carries 156.0.8078.79-1~deb12u1, but Debian's tracker still marks bookworm as vulnerable. The fixed-version data lists only trixie and unstable so far, so do not treat bookworm as patched until the tracker changes.
  • Debian forky: still on 156.0.8078.47-1, which predates the fix.

Other software that ships Skia

The fix lives in Chromium's copy of Skia, so other products that ship Skia need their own updates. Red Hat currently lists webkit2gtk3 (RHEL 8 and 9) and webkitgtk4 (RHEL 7) as Affected, with no errata released yet. A Chrome update does not cover those packages. Skia's broad adoption does not by itself establish that every Skia consumer is affected.

Applying the update

Google's desktop procedure:

  1. Open Chrome and select More > Help > About Google Chrome.
  2. Let Chrome check for updates.
  3. Select Relaunch to apply the update.
  4. Read the current version beneath the Google Chrome heading.

Choosing Not now defers the update until the next restart. Normal windows and tabs reopen after relaunch; Incognito windows do not. On Windows, Google instructs users to close all Chrome windows and tabs, then relaunch. On Linux, update through the package manager.

For managed fleets on Windows, Mac, and Linux, Google's enterprise documentation distinguishes Relaunch recommended, where users can dismiss the notice and keep running the old version, from Relaunch required, which produces recurring notices that the browser must relaunch within a set period. Administrators can confirm the policy at chrome://policy by selecting Reload policies and checking that the status is OK and the values match the intended configuration.

No CVE-specific workaround has been published, and the evidence does not support disabling features or setting browser flags as a substitute for the update.

Detection methods

You can find hosts exposed to CVE-2026-119261, but nothing public detects exploitation. Every public check compares version numbers or package lists, and none sends a crafted page. As of October 31, 2026, CVETodo lists no published Sigma, Suricata, YARA, or Nuclei rules, and no public exploit in Exploit-DB, Metasploit, GitHub PoC repositories, or Nuclei templates. Because the Chromium bug is restricted, nobody outside Google can yet write a content signature for the crafted page.

Version-based detection

NVD's affected software entry:

cpe:2.3:a:google:chrome:*:*:*:*:*:*:*:* up to (excluding) 156.0.8078.79

Any Chrome install reporting a version below 156.0.8078.79 is in scope. When building your own inventory query:

  • Compare all four parts of the version number as integers, not as text.
  • Include per-user installs as well as system-wide ones.
  • Account for relaunch. A host can have the fixed binary on disk while still running the vulnerable version in memory, and a browser is only patched after it restarts on the new build.

Tenable Nessus

  • Plugin 373883 (google_chrome_156_0_8078_79.nasl, Windows family): authenticated local check requiring the KB item installed_sw/Google Chrome. Flags builds earlier than 156.0.8078.79 and lists CVE-2026-119261 among covered CVEs.
  • Plugin 373884 (macosx_google_chrome_156_0_8078_79.nasl): the same check for macOS.
  • Both rely only on the version number the application reports about itself and cover the whole bundle of CVEs from the release. A finding means the host missed the update, not that this Skia bug was reached.
  • Plugin 374244 (unpatched_CVE_2026_119261.nasl, Misc. family, Unix agent): checks only this CVE on Linux, requires local checks plus the global_settings/vendor_unpatched setting, and relies on vendor-reported package presence. Its CPE list includes Debian 12, 13, and 14 chromium and WebKitGTK packages on RHEL and CentOS 7, 8, and 9. If vendor-unpatched reporting is off, this plugin does not fire.

Rapid7

Rapid7's vulnerability database added coverage for Google Chrome on October 30, 2026, with the solution "Upgrade to the latest version of Google Chrome". InsightVM and Nexpose pick it up through normal authenticated scans.

Distribution packages and container images

Distro-packaged Chromium has its own version numbers, so compare against your distribution's fixed version. The Debian tracker shows trixie security fixed in 156.0.8078.79-1~deb13u1, sid fixed in 156.0.8078.79-1, and the following still listed as vulnerable: bookworm (including the bookworm security build 156.0.8078.79-1~deb12u1), base trixie (150.0.7871.181-1~deb13u1), and forky (156.0.8078.47-1).

The bookworm entry is easy to misread. Its upstream version matches the fix, yet the tracker lists it as vulnerable, so a naive "156.0.8078.79 or later" check would wrongly pass it. Follow the distribution status, not the upstream number.

The same applies to images that bundle headless Chromium, such as scrapers, PDF renderers, and CI sandboxes. Scanners reading OSV/Debian data report the finding as DEBIAN-CVE-2026-119261. In one real case, the Onyx project's CVE alert workflow automatically opened a GitHub issue flagging chromium (Debian 13) version 156.0.8078.73-1~deb13u1 in its onyx-sandbox-os image as a blocking critical finding. Search pipeline results for that advisory ID, and remember that images built before the fix stay vulnerable until rebuilt.

Exploitation-stage detection

There are no published IoCs, network signatures, or log patterns for this CVE. Any behavioral catch would come from general EDR coverage of browser process abuse, not a rule written for CVE-2026-119261. CISA's SSVC entry records no evidence of exploitation, and EPSS was about 0.28% as of November 2, 2026. OpenCVE and NotCVE show KEV: No. Until Google opens the bug or researchers publish trigger details, reliable detection means finding every Chrome and Chromium build below the fixed version, including embedded and containerized copies.

Affected systems and versions

  • Google Chrome desktop: all versions before 156.0.8078.79
  • Fixed builds: 156.0.8078.79 (Linux); 156.0.8078.79/.80 (Windows and macOS)
  • Debian chromium: fixed in trixie security (156.0.8078.79-1~deb13u1) and sid (156.0.8078.79-1); still listed vulnerable in bookworm (including 156.0.8078.79-1~deb12u1), base trixie (150.0.7871.181-1~deb13u1), and forky (156.0.8078.47-1)
  • Gentoo www-client/google-chrome: fixed in 156.0.8078.79
  • Red Hat: webkit2gtk3 (RHEL 8 and 9) and webkitgtk4 (RHEL 7) listed as Affected, no errata yet
  • Container images bundling vulnerable Chromium builds remain affected until rebuilt

The vulnerable configuration is any of the above rendering attacker-supplied HTML after user interaction.

Vendor security history

Chromium describes its architecture as defense in depth, with the sandbox as an important but not exclusive protection, backed by automatic updates, auditing, regression testing, fuzzing, and external security research. The Chrome Vulnerability Reward Program accepts reports through Google Bughunters, where they enter security triage immediately, and accepts proven external fuzzers for operation on ClusterFuzz.

Most Chromium security bugs become public 30 days after they are closed as Fixed, which is why an affected version range can be published while the underlying issue stays restricted. This release alone fixed 21 CVEs, including a second Skia bug (CVE-2026-119271). A mature security program is no substitute for verifying the running browser version, and this CVE's stated impact sits outside the sandbox layer.

References

Detect & fix
what others miss

Works with
  • GitHub
  • GitLab
  • Bitbucket
  • Azure DevOps Services
  • Gerrit
  • CVS
  • Jira
  • Linear
  • Slack
  • Security Compass
Explore integrations
Security magnifying glass visualization