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.
3 steps from start to impact.
Lure the user to attacker-controlled content
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.- 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
- 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
Trigger misleading TabGroups presentation
- Specific vulnerable UI behavior must be reproducible in the target build
- Victim must actually see and rely on the spoofed browser chrome
- 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
Convert confusion into action
- Victim performs a sensitive action after seeing the spoof
- Attacker has a follow-on phishing or impersonation workflow ready
- 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
The supporting signals.
| In-the-wild status | No confirmed active exploitation found in reviewed sources; CISA KEV does not list this CVE. |
|---|---|
| Proof-of-concept availability | No 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. |
| EPSS | 0.00057 per the user-supplied intel, which is extremely low and consistent with limited observed exploitation interest. |
| KEV status | Not listed in the CISA Known Exploited Vulnerabilities Catalog. |
| CVSS vector and read-through | CVSS: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 versions | Google 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 versions | Upgrade 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 reality | This 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 date | 2026-06-04 per the supplied advisory metadata. |
| Reporter / research credit | No public researcher attribution was confirmed in reviewed sources for this specific CVE. |
noisgate verdict.
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.
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.
What to do — in priority order.
- Force browser auto-update — Use your browser management stack to verify and enforce Chrome version compliance across Windows, macOS, and Linux. For a
LOWverdict there is no SLA (treat as backlog hygiene), so keep this in the normal endpoint maintenance stream rather than preempting higher-risk patch work. - 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
LOWverdict there is no SLA (treat as backlog hygiene), but this control has cross-cutting value well beyond this CVE. - 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
LOWverdict there is no SLA (treat as backlog hygiene), so validate policy coverage during the next normal control review. - Measure vulnerable build count — Treat this as a fleet hygiene problem: inventory endpoints still below
149.0.7827.53and trend them down through standard browser lifecycle operations. For aLOWverdict there is no SLA (treat as backlog hygiene), so use reporting rather than emergency change windows.
- 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.
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.
#!/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()\nIf you remember one thing.
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
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.