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

Inappropriate implementation in ORB in Google Chrome prior to 149

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

This is a crack in Chrome’s blast door, not an open front gate

CVE-2026-11179 is an ORB (*Opaque Resource Blocking*) implementation flaw in Google Chrome that affects versions prior to 149.0.7827.53 and can let a malicious site weaken Chrome’s site-isolation protections using crafted HTML. In plain English: a hostile webpage may be able to coax Chrome into mishandling cross-origin resource protections that are supposed to keep one site from seeing another site’s data inside the browser.

Google’s HIGH 8.8 label is understandable from a generic browser-CVSS lens, but it overstates real enterprise urgency. This is not remote code execution, not a sandbox escape, and not a no-click drive-by host compromise; it is a defense-boundary bypass whose practical value depends on a victim browsing to attacker content *and* having interesting authenticated web sessions or sensitive cross-origin data in reach.

"Internet-deliverable, yes—but this is a browser boundary bypass, not a host takeover bug"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Lure the user into attacker-controlled content

The attacker needs the victim to render a crafted webpage in a vulnerable Chrome build. Delivery is straightforward—phishing, malvertising, chat links, or compromised sites—but the bug is still UI:R, so nothing happens until the page is opened.
Conditions required:
  • Victim uses Chrome older than 149.0.7827.53
  • Victim visits attacker-controlled or attacker-influenced web content
Where this breaks in practice:
  • Requires user interaction, so this is not wormable or ambient internet scanning territory
  • Enterprise URL filtering, safe browsing, email controls, and browser isolation can break delivery before exploitation
Detection/coverage: Version scanners can find outdated Chrome, but there is no reliable network signature for 'visited a page that attempted this ORB bypass'.
STEP 02

Trigger the ORB bypass with crafted HTML/JS

The malicious page uses custom HTML/JavaScript to exercise the vulnerable ORB code path and weaken the browser-side barrier that should stop unsafe cross-origin resource handling. This is a browser logic flaw, not memory corruption, so the 'weaponized tool' is effectively a bespoke web proof-of-concept rather than shellcode or a public exploit kit.
Conditions required:
  • Target page path must hit the vulnerable ORB behavior
  • The attacker must understand the browser’s cross-origin fetch and rendering edge cases well enough to build a working trigger
Where this breaks in practice:
  • Chrome security bugs often have restricted bug details during rollout, which slows casual copycat weaponization
  • No public exploit repo or off-the-shelf module was located in this assessment
Detection/coverage: Likely invisible to endpoint tools unless combined with suspicious browser telemetry or exfiltration analytics.
STEP 03

Reach sensitive cross-origin browser data

A successful bypass matters only if it lets attacker-controlled content access or infer cross-origin data that the browser should have kept compartmentalized. In practice, the highest-value cases are victims who are concurrently authenticated to SaaS, admin portals, or internal apps exposed through browser sessions.
Conditions required:
  • Victim must have relevant authenticated sessions or sensitive browser-reachable content
  • The target resource must be reachable in a way the ORB bypass can abuse
Where this breaks in practice:
  • No active SaaS/admin session means sharply lower payoff
  • Data exposure is bounded to browser/session context, not automatic host compromise
Detection/coverage: DLP, CASB, and SaaS anomaly logging may catch post-access data movement, but not the browser boundary failure itself.
STEP 04

Exfiltrate what was exposed

If the crafted page can obtain or infer protected cross-origin data, exfiltration is trivial over normal HTTPS from the page itself. The operational impact is theft of web-session data or browser-visible content, not arbitrary code execution on the workstation.
Conditions required:
  • Attacker must successfully extract useful data from the bypassed boundary
  • Outbound web traffic from the browser must be allowed
Where this breaks in practice:
  • The blast radius is narrower than RCE or sandbox escape—mostly web data tied to the browser session
  • Modern egress monitoring may still flag unusual browser-to-unknown-domain data movement
Detection/coverage: Best detected indirectly via proxy logs, CASB alerts, unusual browser egress, or suspicious access patterns in the affected SaaS application.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo CISA KEV listing was found, and no Google statement of active exploitation was located in the reviewed sources.
Proof-of-concept availabilityNo public exploit repo or named researcher write-up was located during this assessment; Chrome also notes bug details may remain restricted until users are updated.
EPSS0.00028 (~0.028% 30-day exploitation probability). Percentile was not authoritatively verified in the sources reviewed, but the raw score is *extremely low*.
KEV statusNot KEV-listed as of this assessment. No CISA due date applies.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H — the vendor vector treats this like a high-impact client-side browser bug, but the key real-world brake is UI:R plus the fact that impact is a *site-isolation bypass*, not direct code execution.
Affected versionsGoogle Chrome prior to 149.0.7827.53. On desktop, Google’s early stable release moved Windows/macOS to 149.0.7827.53/.54; Linux to 149.0.7827.53.
Fixed versionsUpgrade to 149.0.7827.53+ on Linux and 149.0.7827.53/.54+ on Windows/macOS. Chromium downstreams need their own vendor rebuild/backport timing.
Exposure / scanning realityThis is a client-side browser flaw, so Shodan/Censys/FOFA-style internet census data is largely *not applicable*. Exposure is your managed endpoint population, not an internet-facing service count.
Disclosure date2026-06-04
Researcher / reportingPublic credit was not visible in the release material reviewed.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (6.4/10)

The decisive downgrade factor is that exploitation still starts with a user browsing to attacker content, and the payoff is a browser isolation failure rather than endpoint takeover. That combination makes this materially less urgent than Chrome RCEs, sandbox escapes, or KEV-listed browser bugs, even though Chrome itself is massively deployed.

HIGH Affected version cutoff and vendor baseline
MEDIUM Real-world exploitability assessment without public bug details
MEDIUM Impact scoping as cross-origin/session data exposure rather than system compromise

Why this verdict

  • User interaction drags it down — the attacker needs the victim to open malicious web content, so this is not a server-side internet smash-and-grab.
  • This is a boundary bypass, not code execution — ORB/site-isolation failures can be serious, but they usually monetize as cross-origin data access in the browser context, not arbitrary code on the endpoint.
  • Low threat telemetry matters — no KEV listing, no public exploitation statement found, and an EPSS of 0.00028 all argue against emergency-tier patching.
  • Blast radius depends on session context — the bug pays off mainly when the victim already has valuable authenticated SaaS or admin sessions open.
  • Chrome ubiquity keeps it above LOW — almost every enterprise has a huge Chrome footprint, so even a non-RCE browser bypass deserves scheduled attention.

Why not higher?

There is no verified active exploitation signal here, and the attack path does not end in native code execution, sandbox escape, or direct host compromise. The required conditions compound: vulnerable browser build, user visit, a working ORB trigger, and valuable browser-session data to steal.

Why not lower?

A malicious webpage can still reach this bug remotely with no credentials, and Chrome is one of the largest endpoint attack surfaces in any enterprise. If abused against users with active SaaS or privileged web sessions, the business impact can still be meaningful even without full machine compromise.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update and relaunch — Make sure Chrome is centrally pinned to auto-update and that users are forced to relaunch stale instances so the fixed build actually lands. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but browser channels should normally close this far sooner than that.
  2. Isolate high-risk browsing — Route admins, finance, help desk, and other session-rich users through remote browser isolation or hardened browsing profiles where possible. This reduces the value of the bug while you complete patch rollout; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window.
  3. Separate privileged web activity — Keep administrative SaaS and cloud consoles in dedicated browser profiles or separate managed browsers to reduce session cross-contamination. That limits the blast radius if an employee lands on hostile content before patch completion; for MEDIUM, there is no mitigation SLA — go straight to the 365-day remediation window.
  4. Watch for unusual browser egress — Tune proxy, CASB, and SaaS detections for odd browser-to-unknown-domain transfers or sudden access bursts after ad clicks, email-link opens, or uncategorized browsing. This will not prevent exploitation, but it gives you a realistic chance to catch the data-movement phase during the remediation window.
What doesn't work
  • A WAF does not help; the vulnerable logic is in the client browser, not your web server.
  • EDR alone is weak here; browser-origin data theft can look like ordinary browser traffic unless exfiltration is noisy.
  • Turning on Site Isolation is not a fix for a *site-isolation bypass* flaw; the protection being bypassed is already present.
  • Network vuln scanning will not prove exploitability; at best it can inventory outdated Chrome versions on managed endpoints.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory/remote execution tooling. Invoke it as python3 check_chrome_cve_2026_11179.py; it needs only normal user read access to local app metadata/registry, not admin, and prints VULNERABLE, PATCHED, or UNKNOWN based on whether the installed Chrome version is older than 149.0.7827.53.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11179.py
# Determine whether locally installed Google Chrome is vulnerable to CVE-2026-11179
# Fixed version threshold: 149.0.7827.53
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import subprocess
import sys

FIXED = (149, 0, 7827, 53)


def parse_version(s):
    if not s:
        return None
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', s)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def cmp_ver(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 out.strip()
    except Exception:
        return ''


def get_windows_version():
    candidates = [
        ["reg", "query", r"HKLM\Software\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKCU\Software\Google\Chrome\BLBeacon", "/v", "version"],
    ]
    for cmd in candidates:
        out = run_cmd(cmd)
        v = parse_version(out)
        if v:
            return v

    exe_candidates = [
        os.path.expandvars(r"%ProgramFiles%\Google\Chrome\Application\chrome.exe"),
        os.path.expandvars(r"%ProgramFiles(x86)%\Google\Chrome\Application\chrome.exe"),
        os.path.expandvars(r"%LocalAppData%\Google\Chrome\Application\chrome.exe"),
    ]
    for exe in exe_candidates:
        if os.path.exists(exe):
            out = run_cmd([exe, "--version"])
            v = parse_version(out)
            if v:
                return v
    return None


def get_macos_version():
    app = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
    if os.path.exists(app):
        out = run_cmd([app, "--version"])
        v = parse_version(out)
        if v:
            return v
    plist = "/Applications/Google Chrome.app/Contents/Info.plist"
    if os.path.exists(plist):
        out = run_cmd(["/usr/bin/defaults", "read", plist, "CFBundleShortVersionString"])
        v = parse_version(out)
        if v:
            return v
    return None


def get_linux_version():
    bins = [
        "google-chrome",
        "google-chrome-stable",
        "chromium-browser",
        "chromium",
    ]
    for b in bins:
        out = run_cmd(["/usr/bin/env", b, "--version"])
        v = parse_version(out)
        if v:
            return v
    return None


def main():
    system = platform.system().lower()
    version = None

    if "windows" in system:
        version = get_windows_version()
    elif "darwin" in system:
        version = get_macos_version()
    elif "linux" in system:
        version = get_linux_version()

    if not version:
        print("UNKNOWN - could not determine installed Chrome version")
        sys.exit(2)

    if cmp_ver(version, FIXED) < 0:
        print("VULNERABLE - installed Chrome version {} is older than {}.{}.{}.{}".format(
            ".".join(map(str, version)), *FIXED
        ))
        sys.exit(1)
    else:
        print("PATCHED - installed Chrome version {} meets or exceeds {}.{}.{}.{}".format(
            ".".join(map(str, version)), *FIXED
        ))
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: treat this as a browser fleet hygiene issue, not a stop-the-world incident. For a MEDIUM verdict, the noisgate mitigation SLA says no mitigation SLA — go straight to the 365-day remediation window; in practice, verify Chrome auto-update and relaunch compliance now, prioritize privileged-user browsing populations first, and make sure all managed endpoints converge on 149.0.7827.53+ under the noisgate remediation SLA of ≤365 days.

Sources

  1. Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Chrome Releases - Chrome Beta for Desktop Update (149.0.7827.53)
  3. Chromium - Site Isolation overview
  4. Chromium source - ORB/CORB README
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS API documentation
  7. SecurityWeek - Chrome 149 patches 429 vulnerabilities
  8. GovCERT.HK alert - Multiple Vulnerabilities in Google Chrome
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.