← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-11081 · CWE-346 · Disclosed 2026-06-04

Inappropriate implementation in Canvas in Google Chrome prior to 149

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a fake backstage pass to a website session, not a master key to the building

CVE-2026-11081 is a Chrome Canvas implementation flaw that lets a remote attacker use a crafted HTML page to bypass part of the browser's same-origin policy. Affected builds are Google Chrome prior to 149.0.7827.53 on Linux and the corresponding 149.0.7827.53/54 stable desktop train called out by Google on 2026-06-02; in practice this means managed endpoints still running pre-149 stable are exposed.

Google tagged it *Medium* and that is already a little generous for enterprise patch triage. The bug matters because Chrome is everywhere, but the real attack chain still depends on user interaction, a live browser session, and a web-origin integrity impact rather than code execution or device compromise; with no KEV listing, no public PoC in primary sources, and a very low EPSS, this is better treated as backlog hygiene than an interrupt-the-week emergency.

"Ubiquitous software, but this is still a click-to-exploit browser trust break—not a host takeover fire drill"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a lure page with custom JavaScript

The attacker needs the victim to render a crafted HTML page that drives the vulnerable Canvas path in Chrome. The practical delivery mechanism is the usual browser-bug playbook: phishing link, malicious ad, compromised site, or user-generated content containing attacker-controlled script.
Conditions required:
  • Victim uses Chrome older than 149.0.7827.53
  • Victim opens attacker-controlled content in the browser
  • JavaScript execution is allowed for that page
Where this breaks in practice:
  • Requires user interaction rather than blind exploitation
  • Email security, web filtering, safe browsing, and ad blocking reduce reach
  • Many enterprises already auto-update Chrome, shrinking the vulnerable population quickly
Detection/coverage: Traditional vuln scanners have weak visibility into client-side exploit delivery. Web proxies, secure email gateways, browser telemetry, and EDR web-content ancestry are better detection points than perimeter scanning.
STEP 02

Trigger the Canvas SOP bypass primitive

The crafted page abuses the Canvas implementation bug to break same-origin assumptions inside the browser. The weaponized tool here is just attacker JavaScript plus the browser's own Canvas APIs; no separate exploit kit is required if the primitive is reliable.
Conditions required:
  • The exact vulnerable code path must still be reachable in the victim build
  • Chrome's normal same-origin enforcement is relied on by the target flow
Where this breaks in practice:
  • Bug details are still restricted in Chromium issue 500076131, which slows copycat weaponization
  • Canvas/SOP bugs are often narrower in practice than the CVE summary suggests
  • Browser-side mitigation changes can make exploit reliability fragile across platforms and point releases
Detection/coverage: Network scanners will not see this. Browser crash telemetry may be irrelevant if the bug is non-crashing; detections hinge on suspicious browsing patterns and downstream anomalous cross-origin actions.
STEP 03

Abuse the broken origin boundary inside the active session

Once the browser origin boundary is bypassed, the attacker can interfere with web application trust assumptions for the sites the user is actively interacting with. Based on the published CVSS impact (C:N/I:H/A:N), the more credible outcome is cross-origin integrity abuse—unauthorized actions, forged state, or manipulated web content—rather than data theft or endpoint takeover.
Conditions required:
  • Victim is authenticated to a target web application or otherwise has meaningful browser state
  • The targeted application trusts browser-origin separation as a control
Where this breaks in practice:
  • Modern apps often stack defenses like CSRF tokens, same-site cookies, re-auth flows, transaction signing, and step-up MFA
  • Blast radius is usually limited to the current browser session, not the underlying host
  • No evidence yet of broad in-the-wild tradecraft using this CVE
Detection/coverage: Application logs may show anomalous user actions from normal user IPs and devices. Detection is more likely at the app and identity layer than at the browser binary layer.
STEP 04

Monetize session-level abuse

The attacker converts the browser trust bypass into account changes, transaction tampering, workflow abuse, or follow-on phishing. This is where business impact can exist, but it is downstream and highly dependent on the design of the target web app rather than guaranteed by the Chrome bug alone.
Conditions required:
  • A valuable target app is in-session
  • That app lacks compensating controls for browser-origin abuse
Where this breaks in practice:
  • Requires a second layer of weakness in the target application's security model
  • Impact varies wildly by app, tenant, and user role
  • Enterprise SSO, strong session protection, and approval workflows often blunt the payoff
Detection/coverage: Best covered by IAM telemetry, impossible-travel/session analytics, sensitive-action alerts, and web app audit logs rather than pure vulnerability tooling.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found in primary sources reviewed as of 2026-06-05. The flaw is not listed in CISA KEV. Sources: CISA KEV, NVD
Public PoC availabilityNo public proof-of-concept was found in the vendor advisory, NVD references, or Chromium issue metadata reviewed. The Chromium bug remains detail-restricted, which is meaningful friction for immediate copycat exploitation. Sources: Chrome release advisory, Chromium issue 500076131
EPSSUser-supplied EPSS is 0.00016 (0.016%), which is very low for near-term exploitation probability. The exact percentile was not independently verified from an API response during this assessment. Sources: FIRST EPSS overview, FIRST EPSS API docs
KEV statusNot KEV-listed as of 2026-06-05; therefore there is no CISA due date pressure and no confirmed federal active-exploitation signal. Source: CISA KEV catalog
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N scored 6.5 MEDIUM by CISA ADP. Translation: reachable over the network, but it needs a user to browse attacker content and the published impact is integrity-only, not confidentiality theft or availability loss. Source: NVD
Affected versionsChrome prior to 149.0.7827.53 is affected; Google's stable desktop bulletin on 2026-06-02 shipped 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows/Mac. Source: Chrome Stable Channel Update for Desktop
Fixed versionsUpgrade to the 149 stable train or later. For enterprise channels, the relevant floor is 149.0.7827.53 across desktop, with Windows/Mac receiving 149.0.7827.54 in the same bulletin. Source: Chrome Stable Channel Update for Desktop
Scanning and exposure dataThis is a client-side browser flaw, so Shodan/Censys/FOFA-style internet scanning is a poor exposure proxy. Your real population is whatever managed endpoints still pin or lag Chrome updates; asset inventory and endpoint telemetry matter more than external scanning.
Disclosure timelineCVE published by Chrome on 2026-06-04; NVD shows the record last modified on 2026-06-05 and still undergoing enrichment. Source: NVD
Weakness / researcherMapped to CWE-346 Origin Validation Error. Public credit to an external researcher was not visible in the release bulletin excerpt reviewed. Sources: CWE-346, Chrome release advisory
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (4.2/10)

The decisive downgrade factor is that this is a user-driven browser-session integrity bug, not a pre-auth server-side compromise or endpoint code execution path. Chrome is ubiquitous, but the exploit chain only matters when a victim loads attacker content and is simultaneously in a valuable authenticated web session, which sharply narrows real enterprise blast radius.

HIGH Vendor metadata and fixed-version floor
MEDIUM Real-world exploitability assessment from limited public technical detail
HIGH No active-exploitation / no-KEV weighting

Why this verdict

  • User interaction required: the UI:R prerequisite means this is not wormable, not drive-by on closed fleets, and not directly reachable like a server bug.
  • Session-scoped impact: the published impact is I:H with C:N/A:N, which points to browser trust abuse inside a web session rather than host takeover or broad data loss.
  • No current threat signal: no KEV listing, no public PoC in primary sources reviewed, and a user-supplied EPSS of 0.00016 all push downward from the vendor baseline.
  • Exposure is broad but shallow: Chrome is everywhere, which keeps this from being IGNORE, but automatic updates and endpoint management usually collapse the vulnerable window fast.
  • Post-initial-app-context dependency: the attacker still needs a victim to be browsing and, for meaningful business impact, to be authenticated into a target application that lacks stronger app-layer controls.

Why not higher?

This is not unauthenticated server-side RCE, not sandbox escape, and not a host-compromise primitive. The chain requires a human to browse attacker content and then still depends on a second context—an active, valuable web session—to produce real business impact.

Why not lower?

A same-origin-policy bypass in Chrome is still a browser trust-boundary failure in one of the most deployed applications in the enterprise. Even without code execution, a workable cross-origin integrity primitive can be abused against SaaS workflows and admin consoles, so it deserves tracking and version enforcement rather than dismissal.

05 · Compensating Control

What to do — in priority order.

  1. Enforce auto-update policy — Make sure Chrome stable updates are not deferred or pinned below 149.0.7827.53/54. For a LOW verdict there is no SLA-backed mitigation deadline, but this is the cleanest way to shrink exposure without relying on user behavior.
  2. Tighten browser access controls — Use secure web gateway filtering, DNS filtering, and category-based blocking to cut off newly registered domains, ad-tech abuse, and other common lure paths. For LOW, treat this as backlog hardening rather than an emergency control.
  3. Harden high-risk web apps — Prioritize CSRF protection, same-site cookie settings, transaction confirmation, and step-up MFA on finance, admin, and identity workflows. Those controls reduce the payoff of a browser-origin integrity break even if a user lands on a malicious page.
  4. Watch for vulnerable stragglers — Query endpoint telemetry for Chrome versions below 149.0.7827.53 and focus on unmanaged laptops, VDI gold images, kiosk systems, and exception-based update rings. These are the places browser-version drift survives longest.
What doesn't work
  • Perimeter vulnerability scanning doesn't meaningfully help; this is a client-side browser bug, not an internet-facing service fingerprint.
  • Relying on MFA alone is not enough; if the victim is already in-session, MFA may not block same-session integrity abuse.
  • Generic EDR prevention is not a great primary control here because there may be no malware dropper, exploit binary, or process tree anomaly to catch.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your fleet automation tooling. Invoke it as python3 check_cve_2026_11081.py on Linux/macOS or py check_cve_2026_11081.py on Windows; standard user rights are usually enough because it only reads local application metadata and common install paths.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_cve_2026_11081.py
# Determine whether local Chrome/Chromium installs are below the fixed version for CVE-2026-11081.
# Outputs exactly one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys
from pathlib import Path

FIXED = (149, 0, 7827, 53)
VERSION_RE = re.compile(r"(\d+)\.(\d+)\.(\d+)\.(\d+)")


def parse_version(text):
    if not text:
        return None
    m = VERSION_RE.search(text)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def cmp_version(a, b):
    return (a > b) - (a < b)


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        out = (p.stdout or "") + "\n" + (p.stderr or "")
        return parse_version(out)
    except Exception:
        return None


def windows_candidates():
    roots = [
        os.environ.get("ProgramFiles", r"C:\Program Files"),
        os.environ.get("ProgramFiles(x86)", r"C:\Program Files (x86)"),
        os.environ.get("LocalAppData", ""),
    ]
    rels = [
        r"Google\Chrome\Application\chrome.exe",
        r"Chromium\Application\chrome.exe",
    ]
    paths = []
    for root in roots:
        if root:
            for rel in rels:
                paths.append(str(Path(root) / rel))
    return paths


def mac_candidates():
    return [
        "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",
        "/Applications/Chromium.app/Contents/MacOS/Chromium",
    ]


def linux_commands():
    return [
        ["google-chrome", "--version"],
        ["google-chrome-stable", "--version"],
        ["chromium-browser", "--version"],
        ["chromium", "--version"],
    ]


def collect_versions():
    found = []
    system = platform.system().lower()

    if "windows" in system:
        for exe in windows_candidates():
            if os.path.exists(exe):
                v = run_cmd([exe, "--version"])
                if v:
                    found.append((exe, v))
    elif "darwin" in system:
        for exe in mac_candidates():
            if os.path.exists(exe):
                v = run_cmd([exe, "--version"])
                if v:
                    found.append((exe, v))
    else:
        for cmd in linux_commands():
            v = run_cmd(cmd)
            if v:
                found.append((cmd[0], v))

    return found


def main():
    found = collect_versions()
    if not found:
        print("UNKNOWN")
        sys.exit(2)

    vulnerable = []
    patched = []
    for name, version in found:
        if cmp_version(version, FIXED) < 0:
            vulnerable.append((name, version))
        else:
            patched.append((name, version))

    if vulnerable:
        print("VULNERABLE")
        sys.exit(1)

    if patched:
        print("PATCHED")
        sys.exit(0)

    print("UNKNOWN")
    sys.exit(2)


if __name__ == "__main__":
    main()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: do not treat CVE-2026-11081 like an emergency zero-day, but do verify your Chrome fleet is not pinned below 149.0.7827.53/54, especially unmanaged laptops, VDI images, and exception rings. Because the reassessed verdict is LOW, there is no noisgate mitigation SLA and noisgate remediation SLA is no SLA (treat as backlog hygiene); in practice, fold this into the next normal browser update cycle, document any legacy holdouts, and only escalate faster if public exploitation or KEV status changes.

Sources

  1. NVD CVE-2026-11081
  2. Chrome Releases - Stable Channel Update for Desktop
  3. Chromium issue 500076131
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS overview
  6. FIRST EPSS API documentation
  7. MITRE CWE-346 Origin Validation Error
  8. Chromium Security
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.