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

Insufficient policy enforcement in Web Bluetooth in Google Chrome prior to 149

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

This is the loose hinge on the safe door, not the crowbar that gets the thief into the building

CVE-2026-11236 is an *insufficient policy enforcement* bug in Chrome's Web Bluetooth component affecting desktop Chrome before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows and macOS. The described impact is not initial code execution from the web by itself; it is a *post-renderer-compromise* weakness where a malicious page could potentially help an attacker escape Chrome's sandbox after they already burned a separate renderer bug.

That is why the raw 8.3 / HIGH framing overstates enterprise urgency for standalone patch triage. Google's own June 2, 2026 stable-channel advisory lists CVE-2026-11236 as Low, and that matches operational reality: the attacker needs user interaction, a prior renderer compromise, and then a usable Web Bluetooth path, which sharply narrows real-world reach.

"Not a drive-by Chrome zero-day; this only matters after the renderer is already compromised."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land a renderer compromise first

The attacker needs a separate bug to get code execution or equivalent control inside Chrome's renderer process. In practice that means chaining this with another browser memory-corruption or logic flaw delivered by malicious HTML/JS, not exploiting CVE-2026-11236 alone. *Weaponized tool:* crafted exploit page using a distinct renderer bug.
Conditions required:
  • Victim must browse attacker-controlled content
  • A separate exploitable renderer vulnerability must exist and be successfully exploited first
  • Chrome desktop must be running a vulnerable pre-149.0.7827.53 build
Where this breaks in practice:
  • This CVE is useless without a prior browser compromise stage
  • Modern browsers, site isolation, and exploit mitigations make renderer-to-host chains materially harder than simple one-bug web exploits
  • No public evidence this CVE is being paired in active chains
Detection/coverage: Detection is mostly indirect: EDR/browser telemetry may catch the precursor renderer exploit, but scanners cannot validate this step beyond version inventory.
STEP 02

Reach the Web Bluetooth code path

After renderer control, the attacker still has to drive Chrome into the affected Web Bluetooth logic. That usually means invoking Web Bluetooth APIs from attacker-controlled web content and reaching the specific policy enforcement edge case behind this CVE. *Weaponized tool:* malicious JavaScript calling Web Bluetooth APIs.
Conditions required:
  • Web Bluetooth must be available on the endpoint and build
  • The exploit chain must successfully invoke the affected API path
  • Enterprise policy or platform restrictions must not have disabled the feature
Where this breaks in practice:
  • Web Bluetooth is a niche browser feature compared with baseline HTML/JS attack surface
  • Many enterprises do not depend on Web Bluetooth at scale
  • Feature availability can vary by platform, hardware, and policy
Detection/coverage: Browser telemetry or DLP-style extension logging may show Web Bluetooth API use, but most enterprise scanners have no content-level signature for the vulnerable policy path.
STEP 03

Convert policy bypass into sandbox escape

The claimed impact is a *potential* sandbox escape, not guaranteed code execution on the host. The attacker must turn the policy enforcement failure into a reliable escape primitive from the compromised renderer into a more privileged browser or OS context. *Weaponized tool:* exploit chain logic specific to the restricted Chromium bug 496427030.
Conditions required:
  • The renderer compromise must be stable enough to continue execution
  • The policy flaw must expose a usable privileged action or boundary crossing
  • The chain must survive platform sandbox differences
Where this breaks in practice:
  • Official wording says *potentially* perform a sandbox escape, which signals exploit engineering uncertainty
  • Sandbox-escape reliability is usually lower than initial renderer compromise reliability
  • Chromium bug details remain restricted
Detection/coverage: EDR may detect suspicious child-process, handle, or token behavior after escape, but there is little preventive signature coverage specific to this CVE.
STEP 04

Act on the host after escape

If the attacker actually gets out of the sandbox, this becomes a normal post-browser-compromise host intrusion problem: credential theft, loader drop, lateral movement, or persistence. That blast radius can be serious, but only *after* every prior prerequisite succeeds. *Weaponized tool:* standard post-exploitation kit under the attacker's control.
Conditions required:
  • Successful sandbox escape
  • Host controls fail to contain follow-on actions
  • Attacker objectives justify spending a multi-stage browser chain
Where this breaks in practice:
  • EDR, application control, and user rights management often still interrupt this phase
  • The attacker has already invested a high-cost chain for one endpoint
  • This does not create broad unauthenticated exposure across the fleet
Detection/coverage: Good EDR should see this stage far better than the underlying policy bug; treat detections here as generic browser-origin post-exploitation.
03 · Intelligence Metadata

The supporting signals.

Vendor severity mismatchYour intel block says HIGH 8.3, but Google's June 2, 2026 Chrome stable advisory lists CVE-2026-11236 as Low. For triage, I trust the vendor's release note plus the exploit-chain prerequisites more than an inflated score label.
In-the-wild statusNo public evidence of active exploitation found in reviewed sources as of 2026-06-06; this Chrome release was broadly reported as a large patch set, not an emergency zero-day bulletin.
KEV statusNot KEV-listed. This is an inference from CISA's catalog and no matching public listing for CVE-2026-11236 in the reviewed CISA results.
EPSS0.00111 from your intel block, which is consistent with a low-probability near-term exploitation signal rather than a hot enterprise patching fire.
PoC availabilityNo credible public PoC or GitHub exploit chain surfaced in primary-source search. Chromium issue 496427030 is access-restricted, which also limits opportunistic copycat exploitation.
CVSS vectorCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H describes a high-impact *chainable* bug, but the important real-world drag is AC:H + UI:R + prior renderer compromise. That is not internet-scale, one-shot abuse.
Affected versionsChrome desktop before 149.0.7827.53 on Linux and before 149.0.7827.53/54 on Windows/macOS.
Fixed versionsUpgrade to 149.0.7827.53 or later on Linux, and 149.0.7827.53/54 or later on Windows/macOS. Chrome's stable rollout began on 2026-06-02; early stable started 2026-05-29.
Scanning / exposure realityShodan/Censys/FOFA-style exposure data is basically not the right lens here because this is endpoint browser client software, not a network-listening service. Reachability depends on users browsing malicious content and the exploit chain landing in-browser.
Disclosure / reporterDisclosed 2026-06-04 in CVE records; Chrome's stable advisory shipped 2026-06-02 and credits the bug as reported by Google on 2026-03-26.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.1/10)

The decisive factor is the prior renderer-compromise requirement: this is not initial access, it is a late-stage chain component. That prerequisite collapses the exposed population from 'every Chrome user who can browse the web' to 'victims already hit by a separate browser exploit,' which is exactly the kind of compounding friction that should crush the score.

HIGH Downgrade from the provided HIGH label to LOW
MEDIUM Exact exploit mechanics, because the Chromium issue remains restricted

Why this verdict

  • Baseline correction: Google's own June 2, 2026 release notes classify CVE-2026-11236 as Low, not High, so the starting point in your intel block is already overstated.
  • Prior-compromise prerequisite: the attacker must already control the renderer process, which implies a separate successful exploit stage first. That is heavy downward pressure because it is *post-initial-access inside the browser*, not a standalone web-to-host break.
  • Reachability is narrow: exploitation still needs user interaction plus a workable Web Bluetooth path. Enterprise policy, platform differences, and limited real-world Web Bluetooth usage reduce the fraction of endpoints where this chain is even relevant.
  • Threat intel is cold: no KEV listing, no public exploitation evidence in reviewed sources, no visible public PoC, and a very low EPSS all argue against rush-priority treatment.

Why not higher?

It is not higher because this CVE does not hand an unauthenticated remote attacker host compromise on its own. The attack starts from a compromised renderer, which means the attacker has already solved the hardest part with another bug. That makes this a chain amplifier, not a primary entry bug.

Why not lower?

It is not IGNORE because sandbox-escape helpers still matter in real intrusion chains, especially in a browser deployed across nearly every endpoint. If you are already tracking a renderer exploit or suspicious browser-origin activity, this bug can raise the consequences of that separate event.

05 · Compensating Control

What to do — in priority order.

  1. Enforce Chrome auto-update health — Make sure managed desktops are actually receiving Chrome stable updates and not stranded on pinned or broken updater states. For a LOW verdict there is no SLA beyond backlog hygiene, so validate compliance in normal browser governance rather than spinning an emergency campaign.
  2. Disable Web Bluetooth where unused — If your business does not need Web Bluetooth, disable or restrict it through enterprise browser policy to remove this niche attack path entirely. For LOW, do this as configuration hygiene during the normal maintenance cycle, not as a break-fix emergency.
  3. Watch for browser-origin post-exploitation — Tune EDR and browser telemetry around suspicious child processes, token/handle abuse, or odd browser-to-system pivots. This matters because the practical danger is the *chain*, not this CVE in isolation, and for LOW it belongs in routine detection engineering.
What doesn't work
  • A perimeter firewall does not solve this; the attack path rides normal outbound web browsing and happens inside the browser process.
  • Network vulnerability scanners are weak here; they can inventory version drift, but they cannot prove exploitability of a client-side Web Bluetooth policy bug.
  • MFA is irrelevant to the exploit chain itself; this is a browser-to-host boundary problem, not an identity-control failure.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software-distribution/EDR script runner. Invoke with python3 check_chrome_cve_2026_11236.py on macOS/Linux or py check_chrome_cve_2026_11236.py on Windows; no admin rights are required if Chrome is installed in standard locations.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# Check for CVE-2026-11236 exposure by local Google Chrome version
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

FIXED = (149, 0, 7827, 53)


def parse_version(text):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text)
    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_version(cmd):
    try:
        p = subprocess.run([cmd, '--version'], capture_output=True, text=True, timeout=10)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return parse_version(out)
    except Exception:
        return None


def run_file_version(path):
    try:
        p = subprocess.run([str(path), '--version'], capture_output=True, text=True, timeout=10)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return parse_version(out)
    except Exception:
        return None


def candidate_paths():
    system = platform.system().lower()
    cands = []

    if system == 'windows':
        envs = [
            os.environ.get('ProgramFiles'),
            os.environ.get('ProgramFiles(x86)'),
            os.environ.get('LocalAppData'),
        ]
        suffixes = [
            r'Google\Chrome\Application\chrome.exe',
        ]
        for base in envs:
            if not base:
                continue
            for suf in suffixes:
                cands.append(Path(base) / suf)
    elif system == 'darwin':
        cands.extend([
            Path('/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
            Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        ])
    else:
        for bin_name in ['google-chrome', 'google-chrome-stable', 'chrome']:
            resolved = shutil.which(bin_name)
            if resolved:
                cands.append(Path(resolved))
        cands.extend([
            Path('/opt/google/chrome/google-chrome'),
            Path('/usr/bin/google-chrome'),
            Path('/usr/bin/google-chrome-stable'),
        ])

    # preserve order, remove duplicates
    seen = set()
    uniq = []
    for p in cands:
        s = str(p)
        if s not in seen:
            seen.add(s)
            uniq.append(p)
    return uniq


def main():
    found = []

    # PATH-based check first for Unix-like systems
    for bin_name in ['google-chrome', 'google-chrome-stable', 'chrome']:
        resolved = shutil.which(bin_name)
        if resolved:
            ver = run_version(resolved)
            if ver:
                found.append((resolved, ver))

    # Common install paths
    for path in candidate_paths():
        if path.exists() and os.access(path, os.X_OK):
            ver = run_file_version(path)
            if ver:
                found.append((str(path), ver))

    # De-duplicate by path/version
    dedup = []
    seen = set()
    for item in found:
        if item not in seen:
            seen.add(item)
            dedup.append(item)
    found = dedup

    if not found:
        print('UNKNOWN - Google Chrome not found or version unreadable')
        sys.exit(2)

    # If any installed Chrome is below fixed version, flag vulnerable.
    vulnerable = []
    patched = []
    for path, ver in found:
        if cmp_ver(ver, FIXED) < 0:
            vulnerable.append((path, ver))
        else:
            patched.append((path, ver))

    if vulnerable:
        details = ', '.join([f'{p}={".".join(map(str, v))}' for p, v in vulnerable])
        print(f'VULNERABLE - Chrome build below 149.0.7827.53 detected: {details}')
        sys.exit(1)

    details = ', '.join([f'{p}={".".join(map(str, v))}' for p, v in patched])
    print(f'PATCHED - Chrome build is at or above 149.0.7827.53: {details}')
    sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: do not treat this like a stand-alone browser fire drill. Validate that managed endpoints are naturally rolling to 149.0.7827.53/54 through normal Chrome update governance, and optionally disable Web Bluetooth where the business does not need it. Because this lands at LOW, there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene; document the downgrade rationale and reserve urgent effort for Chrome bugs that deliver initial renderer compromise or show active exploitation.

Sources

  1. Google Chrome Releases - Stable Channel Update for Desktop (June 2, 2026)
  2. Google Chrome Releases - Early Stable Update for Desktop (May 29, 2026)
  3. Canadian Centre for Cyber Security - Google Chrome security advisory AV26-544
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS data and statistics
  6. Chromium issue 496427030
  7. SecurityWeek - Chrome 149 Patches 429 Vulnerabilities
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.