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

Inappropriate implementation in TabGroups in Google Chrome prior to 149

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

This is a fake office door sign, not a lock pick

CVE-2026-11232 is a UI spoofing flaw in Chrome's TabGroups feature affecting builds prior to 149.0.7827.53. A remote attacker can serve malicious content that manipulates how tab-group UI is presented, making browser chrome look more trustworthy or less suspicious than it really is. The practical impact is user deception: tricking someone into trusting the wrong tab, origin, or workflow.

paragraph 2: Google's MEDIUM 5.4 baseline is technically fair in CVSS terms, but it overstates operational urgency for enterprise patch queues. This bug does not hand an attacker code execution, sandbox escape, privilege gain, or durable endpoint access; it requires user interaction and succeeds mainly when the victim is fooled by the spoofed interface. That makes it a real security issue, but much closer to phishing enablement than to a breach-by-itself vulnerability.

"This is phishing fuel, not a browser takeover: patch it, but do not let a MEDIUM label jump the queue."
02 · The Attack Path

3 steps from start to impact.

STEP 01

Lure the user to attacker-controlled content

The attacker needs the target to open a crafted page or follow a link that renders malicious content in Chrome. The payload abuses the vulnerable TabGroups UI behavior rather than memory corruption, so the first stage is straight social engineering or commodity phishing delivery. No authentication or pre-existing foothold is required on the endpoint.
Conditions required:
  • Victim uses Google Chrome prior to 149.0.7827.53
  • Victim opens attacker-controlled web content
  • TabGroups-related UI state is reachable during the session
Where this breaks in practice:
  • Requires a real user click or navigation event
  • Email gateways, URL filtering, browser isolation, and user awareness can block delivery before the bug matters
  • Managed fleets often auto-update Chrome quickly, shrinking vulnerable population
Detection/coverage: Vulnerability scanners can identify outdated Chrome builds, but they generally do not validate exploitability of the UI spoof path itself.
STEP 02

Trigger misleading TabGroups presentation

The attacker uses crafted content to induce Chrome into presenting deceptive tab-group UI. The weaponized tool here is just the browser plus attacker HTML and network-delivered content; there is no public exploit framework or post-exploitation toolkit required in reviewed sources. The effect is to blur the user's mental model of which tab or origin is trustworthy.
Conditions required:
  • Specific vulnerable UI behavior must be reproducible in the target build
  • Victim must actually see and rely on the spoofed browser chrome
Where this breaks in practice:
  • UI spoofing is brittle across screen sizes, themes, OS variants, and user habits
  • Users who verify the address bar or rely on password manager origin binding are harder to fool
  • No evidence of broad weaponization was found in reviewed sources
Detection/coverage: EDR usually will not flag this as malicious unless the delivery page or follow-on phishing activity is detected elsewhere.
STEP 03

Convert confusion into action

The exploit only becomes valuable if the spoofed interface persuades the user to do something sensitive: enter credentials, approve a workflow, trust a tab, or ignore a warning. In practice this is where the attacker harvests value, usually by pairing the bug with a credential-phishing or consent-phishing flow. The browser flaw is an amplifier, not the complete intrusion chain.
Conditions required:
  • Victim performs a sensitive action after seeing the spoof
  • Attacker has a follow-on phishing or impersonation workflow ready
Where this breaks in practice:
  • Modern MFA, WebAuthn, password managers, and IdP risk controls reduce payoff
  • Blast radius is typically limited to the user who was fooled, not instant fleet-wide compromise
  • No direct persistence or arbitrary code execution comes from this CVE alone
Detection/coverage: Detection is usually indirect: IdP sign-in telemetry, phishing URL detections, impossible-travel alerts, or helpdesk reports of suspicious browser behavior.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found in reviewed sources; CISA KEV does not list this CVE.
Proof-of-concept availabilityNo public PoC or weaponized exploit repo was found in reviewed sources. That is an inference from source review, not proof that private tradecraft does not exist.
EPSS0.00057 per the user-supplied intel, which is extremely low and consistent with limited observed exploitation interest.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities Catalog.
CVSS vector and read-throughCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:L means remote delivery is possible, but the exploit still needs user interaction and only low confidentiality/availability impact is modeled.
Affected versionsGoogle Chrome prior to 149.0.7827.53; Google notes Windows and macOS 149.0.7827.53/.54 and Linux 149.0.7827.53 in adjacent release material.
Fixed versionsUpgrade to Chrome 149.0.7827.53 or later; on some desktop platforms Google references 149.0.7827.54 as the paired stable build.
Scanning and exposure realityThis is an endpoint-side browser UI bug, so Shodan/Censys/FOFA style internet exposure counts are not the right lens. Your real exposure metric is fleet patch compliance: how many managed endpoints still run pre-149.0.7827.53 Chrome.
Disclosure date2026-06-04 per the supplied advisory metadata.
Reporter / research creditNo public researcher attribution was confirmed in reviewed sources for this specific CVE.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.4/10)

The decisive factor is that this bug is post-click user deception, not direct system compromise. It can amplify phishing, but without a separate follow-on action by the victim it does not give the attacker code execution, privilege escalation, or durable access.

HIGH Assessment that this is lower operational urgency than a typical remotely exploitable Chrome memory-safety issue
MEDIUM Assessment of public exploit availability and real-world weaponization signal

Why this verdict

  • Requires user interaction: the attacker position is unauthenticated remote, but success still depends on a user visiting crafted content and being fooled by the UI.
  • Narrow operational blast radius: this is per-user deception on managed endpoints, not a service-side foothold that scales across a 10,000-host estate in one shot.
  • Security stack meaningfully blunts payoff: password managers, MFA/WebAuthn, URL filtering, browser isolation, and IdP sign-in protections all cut down the value of a successful spoof.
  • Low exploit signal: no KEV listing, extremely low EPSS, and no public PoC found in reviewed sources push this down from the vendor baseline.
  • Exposure is broad but shallow: Chrome is everywhere, which keeps the issue relevant, but the reachable population for a successful exploit chain is only the subset that is both unpatched and convincible.

Why not higher?

A higher severity would need either a stronger impact class or stronger threat evidence. We do not have RCE, sandbox escape, auth bypass, privilege gain, mass-exploitable server exposure, KEV status, or credible public exploitation reporting here. The chain also assumes a successful social-engineering stage, which is a compounding friction point.

Why not lower?

This is not pure noise because Chrome is ubiquitous and UI spoofing can absolutely help steal credentials or approvals at scale during phishing campaigns. If you run a large managed browser fleet, even low-probability per-user deception bugs deserve routine cleanup because the target population is so large.

05 · Compensating Control

What to do — in priority order.

  1. Force browser auto-update — Use your browser management stack to verify and enforce Chrome version compliance across Windows, macOS, and Linux. For a LOW verdict there is no SLA (treat as backlog hygiene), so keep this in the normal endpoint maintenance stream rather than preempting higher-risk patch work.
  2. Harden phishing resistance — Prioritize phishing-resistant MFA, password manager origin binding, and IdP sign-in risk controls so a spoofed browser surface does not easily turn into credential theft. For a LOW verdict there is no SLA (treat as backlog hygiene), but this control has cross-cutting value well beyond this CVE.
  3. Keep web filtering and isolation on — Maintain URL filtering, Safe Browsing, and remote browser isolation for high-risk user groups to stop the attacker before the UI spoof is rendered at all. For a LOW verdict there is no SLA (treat as backlog hygiene), so validate policy coverage during the next normal control review.
  4. Measure vulnerable build count — Treat this as a fleet hygiene problem: inventory endpoints still below 149.0.7827.53 and trend them down through standard browser lifecycle operations. For a LOW verdict there is no SLA (treat as backlog hygiene), so use reporting rather than emergency change windows.
What doesn't work
  • Network IDS signatures do not solve this well because the vulnerable condition is a client-side UI rendering issue, not a distinctive exploit packet you can reliably block in transit.
  • External attack-surface scanners are poor controls here because they cannot see the browser version and user-behavior conditions on internal endpoints.
  • MFA by itself is not enough if your estate still allows phishable factors or approval-fatigue workflows; the bug's value is in tricking the human.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software inventory agent. Invoke it with python3 chrome_cve_2026_11232_check.py on Linux/macOS or py chrome_cve_2026_11232_check.py on Windows; no admin rights are usually required, but reading some install paths or registry keys may work best in the user context that runs Chrome.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3\n# CVE-2026-11232 Chrome version check\n# Outputs: VULNERABLE / PATCHED / UNKNOWN\n# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN\n\nimport os\nimport platform\nimport re\nimport shutil\nimport subprocess\nimport sys\n\nTHRESHOLD = (149, 0, 7827, 53)\n\ndef parse_version(text):\n    m = re.search(r'(\\d+)\\.(\\d+)\\.(\\d+)\\.(\\d+)', text)\n    if not m:\n        return None\n    return tuple(int(x) for x in m.groups())\n\ndef run_cmd(cmd):\n    try:\n        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)\n        if p.returncode == 0:\n            return (p.stdout or p.stderr).strip()\n    except Exception:\n        pass\n    return None\n\ndef version_from_windows():\n    reg_paths = [\n        ["reg", "query", r"HKCU\\Software\\Google\\Chrome\\BLBeacon", "/v", "version"],\n        ["reg", "query", r"HKLM\\Software\\Google\\Chrome\\BLBeacon", "/v", "version"],\n        ["reg", "query", r"HKLM\\Software\\WOW6432Node\\Google\\Chrome\\BLBeacon", "/v", "version"],\n    ]\n    for cmd in reg_paths:\n        out = run_cmd(cmd)\n        if out:\n            v = parse_version(out)\n            if v:\n                return v\n\n    candidates = [\n        os.path.expandvars(r"%ProgramFiles%\\Google\\Chrome\\Application\\chrome.exe"),\n        os.path.expandvars(r"%ProgramFiles(x86)%\\Google\\Chrome\\Application\\chrome.exe"),\n        os.path.expandvars(r"%LocalAppData%\\Google\\Chrome\\Application\\chrome.exe"),\n    ]\n    for path in candidates:\n        if path and os.path.exists(path):\n            out = run_cmd([path, "--version"])\n            if out:\n                v = parse_version(out)\n                if v:\n                    return v\n    return None\n\ndef version_from_macos():\n    candidates = [\n        "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome",\n        os.path.expanduser("~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"),\n    ]\n    for path in candidates:\n        if os.path.exists(path):\n            out = run_cmd([path, "--version"])\n            if out:\n                v = parse_version(out)\n                if v:\n                    return v\n    return None\n\ndef version_from_linux():\n    commands = ["google-chrome", "google-chrome-stable", "chromium", "chromium-browser"]\n    for cmd in commands:\n        full = shutil.which(cmd)\n        if full:\n            out = run_cmd([full, "--version"])\n            if out:\n                v = parse_version(out)\n                if v:\n                    return v\n    return None\n\ndef compare_versions(found, threshold):\n    if found < threshold:\n        return -1\n    if found > threshold:\n        return 1\n    return 0\n\ndef main():\n    system = platform.system().lower()\n    found = None\n\n    if system == "windows":\n        found = version_from_windows()\n    elif system == "darwin":\n        found = version_from_macos()\n    elif system == "linux":\n        found = version_from_linux()\n\n    if not found:\n        print("UNKNOWN: Could not determine installed Google Chrome version")\n        sys.exit(2)\n\n    cmp_result = compare_versions(found, THRESHOLD)\n    version_str = ".".join(str(x) for x in found)\n    threshold_str = ".".join(str(x) for x in THRESHOLD)\n\n    if cmp_result < 0:\n        print(f"VULNERABLE: Installed Chrome version {version_str} is older than fixed version {threshold_str}")\n        sys.exit(1)\n    else:\n        print(f"PATCHED: Installed Chrome version {version_str} is at or above fixed version {threshold_str}")\n        sys.exit(0)\n\nif __name__ == "__main__":\n    main()\n
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not let this displace memory-corruption or KEV-listed browser issues. Use fleet tooling to find Chrome builds below 149.0.7827.53, confirm auto-update is working, and fold remediation into your normal browser maintenance stream; for a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA beyond backlog hygiene. In practice: document the downgrade rationale now, verify update coverage this week, and let standard browser rollout policy clean up stragglers rather than burning emergency change capacity.

Sources

  1. Chrome Releases: Early Stable Update for Desktop
  2. Chrome Releases: Chrome Beta for Desktop Update
  3. Chrome Enterprise previous release notes
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS API documentation
  6. FIRST EPSS overview
  7. CVE.org record lookup
  8. NVD detail page
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.