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

Inappropriate implementation in DevTools in Google Chrome prior to 149

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

Like a thief who only gets in after you hand over a staff badge and open the side door

CVE-2026-11238 is a Chrome DevTools information exposure bug. Per the CVE record, Chrome versions prior to 149.0.7827.53 are affected; Google's desktop release notes map that to Linux <149.0.7827.53 and Windows/macOS <149.0.7827.53/.54. Exploitation is not webpage-only: the attacker has to convince the user to install a *malicious Chrome extension*, which then abuses the DevTools flaw to read potentially sensitive data from Chrome process memory.

The user-supplied 5.9/MEDIUM overstates the real enterprise risk. Google's own release post classifies this one as *Low*, and the decisive friction is obvious: this is not unauthenticated remote exploitation from the internet, it is a second-stage abuse path that depends on successful extension installation first. In managed fleets with extension allowlists, install restrictions, or force-managed browsers, the reachable population collapses fast.

"This is an extension-governance problem first, a browser-patching emergency nowhere"
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land a malicious extension

The attacker needs to deliver a Chrome extension and get the user to install it. In practice the weaponized tool here is the extension itself, delivered through a lure, sideload path, or store-style social engineering. This is the hardest part of the chain because the bug is useless without code already running inside the browser's extension model.
Conditions required:
  • Target is running Chrome prior to 149.0.7827.53
  • User can install extensions or browser is weakly managed
  • Attacker can socially engineer the user into installing the extension
Where this breaks in practice:
  • Many enterprises block self-service extension installs or use allowlists
  • Security-aware users are conditioned to distrust random extension prompts
  • Managed Chrome can force-approved extensions only
Detection/coverage: Good administrative coverage in managed fleets: Chrome Enterprise policy, EDR browser telemetry, and extension inventory can usually spot unexpected installs. Network scanners will not catch this.
STEP 02

Abuse DevTools memory exposure

Once installed, the malicious extension uses the DevTools implementation flaw to obtain sensitive information from process memory. The weaponized component is Chrome DevTools itself, accessed by the extension's crafted logic. This is an in-browser post-install abuse step, not a perimeter-reachable exploit service.
Conditions required:
  • Extension has execution context on the victim browser
  • Victim browser version is vulnerable
  • Extension can reach the buggy DevTools path
Where this breaks in practice:
  • Bug details remain restricted in Chromium issue tracking
  • Extension permission model and policy controls may limit practical reach
  • Exploit reliability may vary by browser state and user workflow
Detection/coverage: Traditional vuln scanners generally only report vulnerable Chrome version. They do not validate exploitability or extension abuse of DevTools.
STEP 03

Harvest whatever secrets are in memory

The likely impact is confidentiality loss: tokens, page data, or other sensitive material resident in the Chrome process. The weaponized tool remains the malicious extension, which exfiltrates recovered data over normal browser networking. This is bad for an affected user session, but it is not the same as host-level code execution or domain-wide compromise.
Conditions required:
  • Sensitive data must actually be present in browser memory
  • Attacker needs outbound exfil path from the browser
  • Victim must be using data worth stealing during the attack window
Where this breaks in practice:
  • Blast radius is typically one user/browser profile at a time
  • Enterprise proxies, DLP, or browser monitoring may expose exfil patterns
  • No evidence yet of broad, repeatable commodity exploitation
Detection/coverage: Detection is mostly behavioral: unusual extension IDs, browser network beacons, and anomalous extension permissions. CVE-only detections miss the actual abuse.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation. CISA KEV does not list CVE-2026-11238, and the CVE JSON's SSVC block marks Exploitation: none.
Public PoC statusNo trustworthy public PoC found. The Chromium issue remains restricted, which usually means exploit details are still being withheld while the fix propagates.
EPSSVery low threat signal. User-supplied EPSS is 0.00015; percentile was not independently confirmed from FIRST during this assessment.
KEV statusNot KEV-listed as checked against CISA's catalog on 2026-06-06.
CVSS vector reality checkCVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N overstates exposure in practice because the real-world chain clearly requires user installation of a malicious extension. That's meaningful attacker-position friction even if the formal vector doesn't model it cleanly.
Affected versionsCVE record says Chrome prior to 149.0.7827.53. Google's desktop release note maps the fixed desktop rollout to Linux 149.0.7827.53 and Windows/macOS 149.0.7827.53/.54.
Fixed versionsUpgrade to Chrome 149.0.7827.53 or later on Linux and 149.0.7827.53/.54 or later on Windows/macOS.
Exposure modelNot internet-scannable. This is an endpoint/browser version plus extension-governance problem, not a Shodan/Censys perimeter exposure problem.
TimelineChrome shipped the stable desktop fix on 2026-06-02; the CVE record was published on 2026-06-04; the CISA ADP enrichment carrying the 5.9 CVSS appeared on 2026-06-05.
ReporterReported by Google on 2026-03-26, per the Chrome stable release advisory.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.8/10)

The decisive factor is that exploitation requires a malicious extension to be installed first, which makes this a *governance and user-consent problem* rather than an internet-reachable browser break. That prerequisite sharply limits exposed population in well-managed enterprises and keeps the blast radius near the individual browser profile.

HIGH Affected/fixed version mapping
HIGH No-KEV / no-known-exploitation status at assessment time
MEDIUM Practical exploitability details, because Chromium bug details remain restricted

Why this verdict

  • Requires malicious extension install first — this is not unauthenticated remote exploitation from a webpage alone; the attacker must first win an extension-install social-engineering battle.
  • Reachable population is narrower than CVSS suggests — managed Chrome fleets commonly block or tightly govern extensions, which compounds downward pressure on severity.
  • Impact is confidentiality-only and user-scoped — the record describes reading sensitive process memory, not sandbox escape, host RCE, or tenant-wide compromise.

Why not higher?

There is no evidence of active exploitation, no KEV listing, no public PoC of note, and no direct remote drive-by path from the public internet. The chain starts with a prerequisite many enterprises already control: unauthorized extension installation.

Why not lower?

It still exposes potentially sensitive browser-resident data, which can include sessions and business information for the affected user. In loosely managed environments where users freely install extensions, the practical risk is real enough that this should stay above IGNORE.

05 · Compensating Control

What to do — in priority order.

  1. Tighten extension policy — Use Chrome Enterprise allowlists/blocklists and approved-extension-only policy so arbitrary extensions cannot be installed. For a LOW verdict there is no fixed mitigation deadline, but this is worth folding into normal browser hardening because it cuts off the exploit prerequisite entirely.
  2. Inventory installed extensions — Pull extension inventories from managed browsers and hunt for unknown IDs, sideloaded packages, and extensions with risky permissions. For LOW, treat this as backlog hygiene and complete it during the next routine browser governance review.
  3. Alert on unexpected extension installs — If you have browser telemetry, EDR, or admin-console reporting, generate alerts for installs outside your approved catalog. This catches the prerequisite abuse step faster than waiting on version-only vulnerability scans.
  4. Roll the fixed Chrome build — Update browsers to 149.0.7827.53/.54 or later through your regular browser maintenance channel. Because this scored LOW, do it as normal patch hygiene rather than an emergency campaign.
What doesn't work
  • A perimeter scanner won't help; this is a client-side browser flaw with no exposed listening service.
  • A generic WAF doesn't meaningfully reduce risk because the exploit path is a malicious extension, not a malicious inbound web request to your infrastructure.
  • MFA does not stop the initial bug trigger; it may reduce value of stolen sessions, but it does not prevent extension installation or in-browser memory reads.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your fleet agent on Windows, macOS, or Linux. Invoke it with python3 check_cve_2026_11238.py; no admin rights are usually required, but reading some install paths on locked-down systems may work better with local admin.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# CVE-2026-11238 Chrome version check
# 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)

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 version_lt(a, b):
    return a < b


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return p.returncode, out.strip()
    except Exception:
        return 1, ''


def candidate_commands():
    system = platform.system().lower()
    cmds = []

    if system == 'windows':
        local = os.environ.get('LOCALAPPDATA', '')
        pf = os.environ.get('PROGRAMFILES', '')
        pf86 = os.environ.get('PROGRAMFILES(X86)', '')
        paths = [
            Path(local) / 'Google/Chrome/Application/chrome.exe',
            Path(pf) / 'Google/Chrome/Application/chrome.exe',
            Path(pf86) / 'Google/Chrome/Application/chrome.exe',
        ]
        for p in paths:
            cmds.append([str(p), '--version'])
        cmds.append(['reg', 'query', r'HKLM\Software\Google\Chrome\BLBeacon', '/v', 'version'])
        cmds.append(['reg', 'query', r'HKCU\Software\Google\Chrome\BLBeacon', '/v', 'version'])

    elif system == 'darwin':
        paths = [
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome')
        ]
        for p in paths:
            cmds.append([p, '--version'])
        cmds.append(['mdfind', 'kMDItemCFBundleIdentifier == "com.google.Chrome"'])

    else:
        for name in ['google-chrome', 'google-chrome-stable', '/opt/google/chrome/chrome', '/usr/bin/google-chrome', '/usr/bin/google-chrome-stable']:
            cmds.append([name, '--version'])

    return cmds


def extract_version_from_output(output):
    return parse_version(output)


def main():
    found_versions = []

    for cmd in candidate_commands():
        rc, out = run_cmd(cmd)
        if not out:
            continue

        # macOS mdfind fallback: if Chrome app exists, try running it
        if cmd[0] == 'mdfind':
            for line in out.splitlines():
                app = line.strip()
                if app.endswith('Google Chrome.app'):
                    binpath = app + '/Contents/MacOS/Google Chrome'
                    rc2, out2 = run_cmd([binpath, '--version'])
                    ver = extract_version_from_output(out2)
                    if ver:
                        found_versions.append((binpath, ver))
            continue

        ver = extract_version_from_output(out)
        if ver:
            found_versions.append((' '.join(cmd), ver))

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

    # Prefer highest discovered version in case multiple installs exist
    best_path, best_ver = sorted(found_versions, key=lambda x: x[1], reverse=True)[0]

    if version_lt(best_ver, FIXED):
        print(f'VULNERABLE - Google Chrome {best_ver[0]}.{best_ver[1]}.{best_ver[2]}.{best_ver[3]} found via {best_path}; fixed version is 149.0.7827.53+')
        sys.exit(1)
    else:
        print(f'PATCHED - Google Chrome {best_ver[0]}.{best_ver[1]}.{best_ver[2]}.{best_ver[3]} found via {best_path}')
        sys.exit(0)

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

If you remember one thing.

TL;DR
Monday morning, do two things: validate which Chrome users can still self-install extensions, and roll vulnerable browsers to 149.0.7827.53/.54 or later through normal browser maintenance. For a LOW reassessment there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene, so this is not an emergency patch push; document the rationale, fix it in routine browser servicing, and prioritize extension-governance cleanup where users still have broad install freedom.

Sources

  1. Chrome Releases: Stable Channel Update for Desktop (2026-06-02)
  2. Official CVE JSON record for CVE-2026-11238
  3. CISA Known Exploited Vulnerabilities Catalog
  4. FIRST EPSS overview
  5. FIRST EPSS API documentation
  6. Chrome Enterprise app and extension policies
  7. Managing Extensions in Your Enterprise
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.