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

Insufficient validation of untrusted input in Omnibox in Google Chrome prior to 149

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

This is a fake street sign at the edge of the browser, not a bulldozer through your front door

CVE-2026-11273 is an *improper input validation* bug in Chrome's Omnibox security/UI surface. A remote attacker can reach it only by getting a user onto a crafted page or flow, and the impact described so far points to *security UI spoofing / misleading address-bar state* rather than code execution. The affected range is Google Chrome for desktop *before* 149.0.7827.53 on Linux and before 149.0.7827.53/.54 on Windows/macOS, with downstream browser packages inheriting the fix through vendor backports.

Google labeled it MEDIUM at 6.1, which is fair in a vacuum because browsers are ubiquitous and Omnibox trust cues matter. In enterprise reality, though, this chain is heavily gated by *user interaction*, the likely need for a carefully crafted phishing page, and the absence of evidence for in-the-wild weaponization or a public exploit. That makes it a *real but bounded* user-deception issue, not a Monday-morning emergency.

"This is a phishing amplifier in a browser UI edge case, not a clean remote compromise path"
02 · The Attack Path

3 steps from start to impact.

STEP 01

Stage a lure page

The attacker needs a malicious website or phishing page that exercises the Omnibox validation flaw. In practice this is a social-engineering delivery problem first, typically via email, chat, ads, or SEO poisoning; common phishing infrastructure such as Evilginx-style kits can be used downstream, but the CVE itself does not provide initial delivery.
Conditions required:
  • Unauthenticated remote reach to a target user
  • User runs a vulnerable Chrome build
  • Attacker can get the user to open attacker-controlled content
Where this breaks in practice:
  • Email gateways, browser filtering, and user skepticism kill a lot of lures before render
  • Enterprise Chrome auto-update shrinks the reachable window quickly
  • This is not wormable and cannot self-propagate across hosts
Detection/coverage: Traditional vuln scanners can identify vulnerable Chrome versions, but they generally cannot validate exploitability of the specific Omnibox rendering path.
STEP 02

Trigger misleading browser chrome

Once the page loads, the attacker attempts to abuse the insufficient validation condition in Omnibox to create a misleading trust signal, such as confusing origin display or related security UI behavior. This is a browser-bound deception primitive, not direct memory corruption with immediate code execution.
Conditions required:
  • The specific vulnerable UI state must be reachable from web content
  • User interaction is required per the published CVSS vector
Where this breaks in practice:
  • Browser UI bugs are brittle across versions, screen sizes, and platform builds
  • A lot of users will not proceed unless the spoof looks convincing
  • Modern anti-phishing controls may still flag the destination or page content
Detection/coverage: EDR rarely has a signature for an Omnibox spoof itself; browser telemetry and phishing detections are more useful than exploit telemetry here.
STEP 03

Convert spoofing into credential theft or click-through

The realistic impact is that the attacker leverages the misleading UI to raise success rates for credential capture, consent phishing, or trusted-brand impersonation. Tools like reverse-proxy phishing kits benefit from the extra trust signal, but the CVE alone still does not bypass MFA universally or grant host execution.
Conditions required:
  • Victim must trust the spoof enough to enter data or approve a flow
  • Targeted application must be susceptible to phishing or consent abuse
Where this breaks in practice:
  • MFA, FIDO2/passkeys, conditional access, and IdP risk checks reduce payoff
  • Blast radius is generally limited to the fooled user session, not the endpoint fleet
  • No published evidence shows this CVE reliably chaining to device compromise
Detection/coverage: Identity telemetry, impossible travel, abnormal consent grants, and reverse-proxy phishing detections are better indicators than host exploit alerts.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation evidence found in reviewed sources, and not listed in CISA KEV as of the catalog state reviewed. That is a major downward pressure on urgency for a browser UI bug.
Proof-of-concept availabilityNo public PoC or exploit repo was found in reviewed sources. Chrome bug details are commonly restricted until most users are patched, so absence of a PoC is *helpful but not definitive*.
EPSSUser-supplied EPSS is 0.00025 (0.025%), which is extremely low. I could not independently verify the exact percentile from a primary FIRST record in reviewed search results, so treat percentile as unverified.
KEV statusNot KEV-listed in the reviewed CISA KEV catalog. No KEV date applies.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N = remote reach, no auth, but user interaction required and no availability impact. That is classic phishing-amplifier territory, not autonomous endpoint takeover.
Affected versionsChrome desktop prior to 149.0.7827.53; official release notes show 149.0.7827.53 for Linux and 149.0.7827.53/.54 for Windows/macOS rolling out in late May 2026.
Fixed versionsPatch baseline is 149.0.7827.53 on Linux and 149.0.7827.53/.54 on Windows/macOS, with downstream distro/browser packages backporting the same fix lineage; e.g., openSUSE maintenance references this CVE.
Exposure / scanning realityShodan/Censys/FOFA are basically not useful here because this is a client-side browser flaw, not an internet-exposed service. Your exposure measurement should come from EDR, software inventory, browser management, or SBOM/package telemetry instead.
Disclosure dateUser-supplied disclosure date is 2026-06-05. Related vendor and national advisories around the 149.0.7827.53/.54 release landed from May 29, 2026 through June 2, 2026.
Researcher / reporterSpecific reporter attribution for this CVE was not located in reviewed primary sources. Comparable Chrome release notes often list the reporter, but details for this issue appear restricted or not yet surfaced publicly.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.8/10)

The decisive factor is user interaction plus browser-UI-only impact: the attacker still has to land a convincing lure and get a human to trust it. This bug may improve phishing conversion, but the reviewed evidence does not support direct host compromise, broad fleet blast radius, or active exploitation.

HIGH Attacker-position and user-interaction friction assessment
MEDIUM Impact bound to spoofing/deception rather than code execution
MEDIUM Public exploitability picture given restricted Chrome bug details

Why this verdict

  • Start at vendor 6.1, then discount for UI:R — the attacker cannot cash out without convincing a user to open and trust a crafted page.
  • Discount again for attack outcome — current public description points to Omnibox/UI deception, not RCE, sandbox escape, or credential exfiltration by itself.
  • Discount for exposure measurability and blast radius — this is a client-side browser issue affecting individual user sessions, not an internet-facing enterprise service with fleetwide unauthenticated reach.
  • Discount for threat intel — no KEV listing, no confirmed in-the-wild exploitation, and an extremely low user-supplied EPSS materially lower near-term operational risk.
  • Add back a little for ubiquity — Chrome is everywhere, and Omnibox trust cues matter, so this is not IGNORE territory.

Why not higher?

There is no evidence here of a clean one-click device compromise, privilege gain, or server-side blast radius. The chain depends on social engineering and likely ends in phishing or UI confusion, which sharply lowers enterprise patch urgency compared with memory corruption or sandbox-escape Chrome bugs.

Why not lower?

It still affects the browser trust surface that users rely on to judge destination legitimacy. In a large enterprise, even a low-grade browser UI bug can modestly improve phishing success, so it deserves routine remediation rather than dismissal.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update — Keep managed Chrome channels pinned to the latest stable build and verify relaunch compliance through your browser management stack. For a LOW verdict there is no fixed mitigation deadline, so treat this as backlog hygiene and absorb it into the normal browser-update cadence.
  2. Harden phishing-resistant auth — Prefer FIDO2/passkeys, conditional access, and IdP risk checks for high-value apps so a spoofed browser trust cue does not automatically translate into account takeover. For this severity there is no mitigation SLA, but these controls reduce the only realistic payoff path.
  3. Block risky web categories — Use secure web gateway and DNS filtering to reduce first-touch access to newly registered domains, typo-squats, and known phishing infrastructure. This is most useful while waiting for normal endpoint update convergence.
  4. Watch for stale Chrome builds — Query EDR/software inventory for versions below 149.0.7827.53 and focus on systems with disabled updates, long-lived VDI images, kiosk builds, and unmanaged admin workstations. Those laggards are the real residual risk population.
What doesn't work
  • A WAF does not help; the vulnerable component is the endpoint browser UI, not your server.
  • Network segmentation does not meaningfully reduce exposure; the trigger is a user browsing attacker-controlled content over normal web channels.
  • EDR alone is weak here; if exploitation stays in the lane of UI spoofing and phishing, there may be little or no exploit-specific host telemetry.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your EDR/live-response tooling. Invoke it with python3 chrome_cve_2026_11273_check.py on macOS/Linux or py chrome_cve_2026_11273_check.py on Windows; no admin rights are usually required if the Chrome binary is in a standard install path. It checks the local Chrome version and reports VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# chrome_cve_2026_11273_check.py
# Detect exposure to CVE-2026-11273 by checking installed 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

PATCH_LINUX = (149, 0, 7827, 53)
PATCH_WIN_MAC = (149, 0, 7827, 53)  # .53/.54 both considered fixed; anything >= .53 is acceptable.


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 compare_versions(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 '') + ' ' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


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

    if system == 'windows':
        envs = [
            os.environ.get('ProgramFiles'),
            os.environ.get('ProgramFiles(x86)'),
            os.environ.get('LocalAppData'),
        ]
        suffixes = [
            r'Google\Chrome\Application\chrome.exe',
            r'Chromium\Application\chrome.exe',
        ]
        for base in envs:
            if base:
                for s in suffixes:
                    paths.append(Path(base) / s)
    elif system == 'darwin':
        paths.extend([
            Path('/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
            Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            Path('/Applications/Chromium.app/Contents/MacOS/Chromium'),
        ])
    else:
        for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
            p = shutil.which(name)
            if p:
                paths.append(Path(p))
        paths.extend([
            Path('/opt/google/chrome/chrome'),
            Path('/usr/bin/google-chrome'),
            Path('/usr/bin/google-chrome-stable'),
            Path('/usr/bin/chromium'),
            Path('/usr/bin/chromium-browser'),
        ])

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


def get_version_from_binary(path):
    if not path.exists():
        return None, ''
    out = run_cmd([str(path), '--version'])
    ver = parse_version(out)
    return ver, out


def get_windows_registry_version():
    reg_paths = [
        r'HKLM\Software\Google\Chrome\BLBeacon',
        r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon',
        r'HKCU\Software\Google\Chrome\BLBeacon',
    ]
    for reg in reg_paths:
        out = run_cmd(['reg', 'query', reg, '/v', 'version'])
        ver = parse_version(out)
        if ver:
            return ver, out
    return None, ''


def classify(ver):
    system = platform.system().lower()
    if system == 'linux':
        return 'PATCHED' if compare_versions(ver, PATCH_LINUX) >= 0 else 'VULNERABLE'
    return 'PATCHED' if compare_versions(ver, PATCH_WIN_MAC) >= 0 else 'VULNERABLE'


def main():
    findings = []

    if platform.system().lower() == 'windows':
        ver, raw = get_windows_registry_version()
        if ver:
            findings.append(('registry', ver, raw))

    for path in candidate_paths():
        ver, raw = get_version_from_binary(path)
        if ver:
            findings.append((str(path), ver, raw))

    # Deduplicate by path/source and version
    normalized = []
    seen = set()
    for src, ver, raw in findings:
        key = (src, ver)
        if key not in seen:
            seen.add(key)
            normalized.append((src, ver, raw))

    if not normalized:
        print('UNKNOWN: Could not determine a local Chrome/Chromium version from standard paths or registry.')
        sys.exit(2)

    statuses = []
    for src, ver, raw in normalized:
        status = classify(ver)
        statuses.append(status)
        print(f'{status}: {src} -> {".".join(map(str, ver))}')

    if 'VULNERABLE' in statuses:
        sys.exit(1)
    if 'PATCHED' in statuses:
        sys.exit(0)

    print('UNKNOWN: Version data found but could not be classified.')
    sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning, treat this as a routine browser update, not an incident-response fire drill. Because the reassessed verdict is LOW, there is no noisgate mitigation SLA and no separate temporary-control deadline beyond normal hardening; treat it as backlog hygiene and focus first on stale Chrome populations, VDI gold images, kiosks, and unmanaged admin workstations. For the actual fix, align with your noisgate remediation SLA for LOW findings by rolling the vendor update through normal endpoint maintenance rather than emergency change windows; if your environment already has rapid Chrome auto-update, this should simply be verified and closed out.

Sources

  1. Google Chrome Releases - Early Stable Update for Desktop (149.0.7827.53/.54)
  2. Google Chrome Releases home
  3. Chrome Enterprise previous release notes
  4. Update Google Chrome help page
  5. Canadian Centre for Cyber Security advisory AV26-544
  6. SecurityWeek - Chrome 149 patches 429 vulnerabilities
  7. openSUSE maintenance patchinfo referencing CVE-2026-11273
  8. CISA Known Exploited Vulnerabilities Catalog
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.