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

Inappropriate implementation in Browser in Google Chrome prior to 149

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

This is a mislabeled exit sign in a crowded building, not a master key to the building

CVE-2026-11257 is a Chrome browser policy/trust flaw: a crafted HTML page can bypass navigation restrictions in the browser layer. Public sources tie it to Chrome versions prior to 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/macOS, with downstream distro fixes also rolling out. That puts the issue on endpoints, not servers; the attacker needs a user in the browser seat.

The vendor/NVD-style MEDIUM 4.3 baseline is already restrained, but in enterprise reality this still grades lower. There is no code execution, no sandbox escape, no credential theft primitive by itself, no KEV entry, no public exploitation signal, and the attack path starts with *user-driven browsing to attacker content*; that combination makes this a patchable browser hygiene issue, not a fire drill.

"Wide deployment doesn't rescue a browser trust-bypass bug that still needs a user to click first."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the user on attacker-controlled web content

The attacker needs the target to open a malicious page, ad, or embedded link in a vulnerable Chrome build. In practice this is a phishing or drive-by lure, not a self-starting server-side event. The 'tool' here is just attacker HTML/JavaScript delivered over the web.
Conditions required:
  • Target is running Chrome prior to 149.0.7827.53
  • User browses to attacker-controlled content
  • Normal web content execution is allowed
Where this breaks in practice:
  • Requires user interaction (UI:R)
  • Enterprise web filtering, Safe Browsing, and mail gateways can cut off the lure before render
  • Modern Chrome auto-update shrinks dwell time on managed fleets
Detection/coverage: Vulnerability scanners rarely prove exploitability here; version inventory and browser update telemetry are the primary detection methods.
STEP 02

Trigger the navigation restriction bypass

Once rendered, the crafted page abuses the browser-side implementation flaw to bypass intended navigation controls. Public reporting does not show a weaponized exploit chain or memory corruption primitive; this reads as a trust/policy break, not a full compromise bug. The attacker 'tool' is the crafted page itself.
Conditions required:
  • The vulnerable browser code path is reachable from the page
  • The specific navigation sequence used by the attacker still behaves as described
Where this breaks in practice:
  • Behavioral edge cases in browser policy bugs are often brittle across channels and minor builds
  • Many such bugs degrade into UI confusion or limited origin/trust bypass rather than durable attacker control
Detection/coverage: EDR will not reliably flag the bug itself. Browser crash telemetry is unlikely to help because this is not a classic memory-corruption signature.
STEP 03

Turn bypass into user deception or session abuse

The practical impact is that the attacker can steer or present navigation in a way Chrome should have blocked. That can enable phishing-style trust abuse, unexpected page transitions, or policy circumvention inside the browser session. The likely 'weaponized tool' is a phishing kit or login-harvest page chained behind the bypass.
Conditions required:
  • Victim continues interacting with the malicious or redirected content
  • The enterprise relies on browser trust indicators or blocked navigation behavior as a control boundary
Where this breaks in practice:
  • Impact stays bounded to what the user is willing to do next
  • MFA, IdP risk checks, passwordless auth, and user awareness blunt the follow-on payoff
Detection/coverage: Identity logs, proxy logs, and phishing detections are more useful than host telemetry for spotting the *outcome* of this step.
STEP 04

Exploit downstream trust, not the endpoint

The end state is usually a better phishing position or a browser policy bypass, not host takeover. To get real enterprise damage, the attacker still needs a second-stage objective such as credential theft or fraudulent user action. That extra dependency is why this does not deserve a high patching priority by itself.
Conditions required:
  • A follow-on business process or identity abuse path exists
  • The victim takes a second action after the browser flaw is triggered
Where this breaks in practice:
  • No evidence this CVE alone yields code execution or lateral movement
  • Blast radius is generally one browsing session at a time
Detection/coverage: Detection shifts to identity security, CASB/proxy telemetry, and browser/session logs rather than exploit signatures.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found. PCWorld's coverage of the Chrome 149 release says Google reported none of the patched flaws were known to be exploited in the wild at release time. PCWorld
PoC availabilityNo public PoC located in the sources reviewed. Public bug details also appear sparse/restricted, which is common for Chrome until update saturation improves.
EPSS0.0002 from the user-provided intel, which is effectively negligible operational pressure. FIRST documents EPSS as a probability of exploitation in the next 30 days. FIRST EPSS FIRST data stats
KEV statusNot listed in CISA KEV per user-provided intel, and no matching listing is visible from the public KEV catalog path reviewed. CISA KEV catalog
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N — remote and unauthenticated, but user interaction is mandatory and impact is limited to low integrity change rather than confidentiality loss, availability loss, or code execution.
Affected versionsChrome prior to 149.0.7827.53 per multiple public advisories; Chrome desktop release notes show 149.0.7827.53/.54 on Windows/macOS in the early stable wave. GovCERT.HK Chrome Releases
Fixed versionsUpgrade to 149.0.7827.53 or later; for Windows/macOS that maps to the desktop early stable 149.0.7827.53/.54 train. Downstream package maintainers such as openSUSE also rolled the fix in their Chromium maintenance stream. Chrome Releases openSUSE patchinfo
Exposure / scanning realityNot meaningfully internet-scannable. This is endpoint client software, so Shodan/Censys-style exposure counts do not map cleanly. Real exposure is fleet prevalence: wherever users run vulnerable Chrome builds, the reachable population is broad, but only through user browsing.
Disclosure date2026-06-05 from the provided intel; public feeds also show the CVE landing on that date. CVE Alert feed
Researcher / source attributionNot publicly attributed in the sources reviewed. The public Chrome and feed entries available here identify the bug class/component but do not expose a public researcher credit for this specific CVE.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.1/10)

The decisive factor is mandatory user interaction on a client-side trust bug with only low-integrity impact. This is a browser-session policy bypass that still needs a second-stage social-engineering payoff, and there is no current exploitation signal pushing it higher.

HIGH Attack-path friction assessment
MEDIUM Exact business-impact ceiling without public root-cause detail

Why this verdict

  • Start from 4.3, then cut for UI:R: the attacker must get a user onto malicious content first, which means phishing, malvertising, or some other lure has to work before the CVE matters.
  • This is post-lure, not initial compromise: requiring a browser session implies the attacker is operating through user browsing, not directly against an exposed enterprise service.
  • Impact is narrow: the public description is a navigation restriction bypass with I:L and no stated confidentiality or availability impact, so this is trust abuse, not endpoint takeover.
  • No active-threat pressure: user-provided intel says KEV is negative and EPSS is 0.0002; reviewed public reporting also says no known in-the-wild exploitation at release.
  • Wide deployment keeps it patch-worthy: Chrome is everywhere, so this is not IGNORE; it still deserves version hygiene and update verification across the fleet.

Why not higher?

A higher rating would need at least one of three things: active exploitation, a public weaponized chain, or materially stronger impact such as same-origin bypass with credential theft implications, sandbox escape, or code execution. None of that is in the public record reviewed here. The user-interaction requirement compounds the downgrade because it puts this behind your phishing controls and user behavior.

Why not lower?

It is not IGNORE because Chrome is high-prevalence client software and the bug is remotely reachable through normal browsing. Even low-grade browser trust breaks can be folded into phishing kits and identity attacks, so you still want the fleet updated and exceptions documented.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure enterprise policy actually forces Chrome/Chromium updates and relaunch behavior, because version churn is the cleanest control here. For a LOW verdict there is no SLA; treat as backlog hygiene, but validate policy compliance in the next routine endpoint maintenance cycle.
  2. Tighten phishing and web filtering — Because the bug starts with a user visiting attacker-controlled content, mail gateway URL rewriting, DNS/web filtering, Safe Browsing enforcement, and high-risk category blocking remove the first prerequisite. For a LOW verdict there is no SLA; treat as backlog hygiene unless your environment is under targeted phishing pressure.
  3. Instrument browser version inventory — Track Chrome versions through EDR, MDM, SCCM/Intune/Jamf, or package management so you can prove which endpoints remain below 149.0.7827.53. For a LOW verdict there is no SLA; treat as backlog hygiene, but do not rely on network scanners for browser client coverage.
  4. Harden identity follow-on controls — Since the likely real-world payoff is phishing or deceptive navigation, make sure phishing-resistant MFA, conditional access, and suspicious sign-in alerts are enforced. For a LOW verdict there is no SLA; treat as backlog hygiene, but this control meaningfully reduces the bug's downstream business impact.
What doesn't work
  • A perimeter firewall does not solve this; the vulnerable surface is ordinary outbound web browsing.
  • Server-side WAF rules do not meaningfully help unless you fully control every site the user can browse, which enterprises do not.
  • Exploit-block signatures alone are weak here; this is not a noisy memory-corruption bug with stable crash indicators.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software inventory/remote execution tooling. Invoke it with python3 check_chrome_cve_2026_11257.py on macOS/Linux or py check_chrome_cve_2026_11257.py on Windows; local user rights are usually enough, but admin rights may help if Chrome is installed system-wide in nonstandard paths.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11257.py
# Purpose: Detect whether local Google Chrome / Chromium appears vulnerable to CVE-2026-11257
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

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

THRESHOLD = (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_to_str(v):
    return '.'.join(str(x) for x in v)


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 candidate_paths():
    system = platform.system().lower()
    paths = []

    if 'windows' in system:
        envs = [
            os.environ.get('ProgramFiles'),
            os.environ.get('ProgramFiles(x86)'),
            os.environ.get('LocalAppData')
        ]
        rels = [
            r'Google\Chrome\Application\chrome.exe',
            r'Chromium\Application\chrome.exe'
        ]
        for base in envs:
            if base:
                for rel in rels:
                    paths.append(str(Path(base) / rel))
    elif 'darwin' in system:
        paths.extend([
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            '/Applications/Chromium.app/Contents/MacOS/Chromium',
            str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
            str(Path.home() / 'Applications/Chromium.app/Contents/MacOS/Chromium'),
        ])
    else:
        # Linux and other Unix-like
        binaries = [
            'google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'chrome'
        ]
        for b in binaries:
            found = shutil.which(b)
            if found:
                paths.append(found)
        paths.extend([
            '/opt/google/chrome/chrome',
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/usr/bin/chromium',
            '/usr/bin/chromium-browser'
        ])

    # Deduplicate while preserving order
    seen = set()
    uniq = []
    for p in paths:
        if p and p not in seen:
            seen.add(p)
            uniq.append(p)
    return uniq


def discover_versions():
    found = []
    for p in candidate_paths():
        if not os.path.exists(p):
            continue
        out = run_cmd([p, '--version'])
        ver = parse_version(out)
        if ver:
            found.append((p, ver, out))
    return found


def assess(ver):
    return 'PATCHED' if ver >= THRESHOLD else 'VULNERABLE'


def main():
    installs = discover_versions()

    if not installs:
        print('UNKNOWN: No Google Chrome/Chromium binary found in common locations.')
        sys.exit(2)

    # If any detected installation is vulnerable, call the host vulnerable.
    vulnerable = []
    patched = []
    for path, ver, raw in installs:
        state = assess(ver)
        record = f'{path} -> {version_to_str(ver)} ({state})'
        if state == 'VULNERABLE':
            vulnerable.append(record)
        else:
            patched.append(record)

    print(f'Threshold: {version_to_str(THRESHOLD)}')
    print('Detected installations:')
    for rec in vulnerable + patched:
        print(f'  - {rec}')

    if vulnerable:
        print('VULNERABLE')
        sys.exit(1)
    elif patched:
        print('PATCHED')
        sys.exit(0)
    else:
        print('UNKNOWN')
        sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning: do not burn an emergency change window on this one. Verify browser auto-update coverage, identify endpoints still below 149.0.7827.53, and fold the upgrade into your next routine endpoint/browser rollout; for a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA — treat as backlog hygiene. If you have high-risk user groups regularly targeted by phishing, prioritize them first, but for the broader fleet this is normal patch validation work, not an incident-response tempo task.

Sources

  1. Google Chrome Releases - Early Stable Update for Desktop
  2. Google Chrome Releases - 2026 archive
  3. GovCERT.HK alert for Chrome 149 fixes
  4. openSUSE Chromium patchinfo including CVE-2026-11257
  5. CVE Alert feed entry for CVE-2026-11257
  6. CISA Known Exploited Vulnerabilities catalog
  7. FIRST EPSS data and methodology
  8. PCWorld coverage of Chrome 149 security fixes
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.