This is a broken interior door inside a house the attacker already had to break into first
CVE-2026-11244 is an input-validation flaw in Chrome WebAuthentication that affects Google Chrome versions prior to 149.0.7827.53. Public metadata says the attacker must first compromise the renderer process, then use a crafted HTML page to bypass same-origin-policy boundaries and disclose limited data. In plain English: this is not a one-bug browser takeover; it is a post-renderer-compromise privacy boundary slip inside the browser.
The vendor's LOW rating matches reality. The decisive friction is the prerequisite attacker position: *compromised renderer process* means the adversary already needed a separate browser exploit or equivalent code-execution foothold inside Chrome before this bug matters. That turns this from an enterprise patch emergency into chain-hardening maintenance, even though Chrome itself is widely deployed.
3 steps from start to impact.
Land code execution in the renderer first
- Victim is running Chrome older than
149.0.7827.53 - Attacker has a separate working renderer-compromise primitive
- Victim reaches attacker-controlled content
- Requires a prior exploit stage, so this is not an initial-access bug
- Modern Chrome exploit mitigations and site isolation raise the bar on renderer compromise
- EDR/browser telemetry often catches the earlier stage before this one matters
Trigger the WebAuthentication validation flaw
- Renderer compromise is already in place
- A vulnerable WebAuthentication code path is reachable
- User interaction remains part of the chain
- Attack complexity is rated High, which usually means brittle sequencing and environment sensitivity
- The bug appears limited to confidentiality impact rather than full code execution
- Public bug details are restricted, which slows opportunistic copycat weaponization
Read cross-origin data
- Useful victim session or sensitive origin data is present in-browser
- Data of interest is accessible via the bypassed origin boundary
- Impact is limited to low confidentiality in public scoring
- No public evidence of chaining into persistence or system compromise
- Enterprise browser controls can reduce session exposure in high-risk workflows
The supporting signals.
| In-the-wild status | No public evidence found of active exploitation, and the CVE is not listed in CISA KEV as of this assessment. That matters because this bug already requires a prior renderer compromise. |
|---|---|
| Proof-of-concept availability | No public PoC or Metasploit/Nuclei-style check located. Chromium issue details are restricted, which is normal for Chrome until the user base is updated. |
| EPSS | 0.00027 provided in your intel, which is effectively floor-level exploit likelihood and consistent with a chained, low-impact browser bug. |
| KEV status | Not KEV-listed. No date-added because it is absent from the CISA catalog. |
| CVSS vector | CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N — network reachable in theory, but *High* complexity, user interaction required, and confidentiality-only impact. |
| Affected versions | Google Chrome prior to 149.0.7827.53; NVD currently models the vulnerable Chrome application on Windows, Linux, and macOS. |
| Fixed version | Patched in Chrome 149.0.7827.53 per NVD/vendor references. The May 29, 2026 early-stable post shows 149.0.7827.53/.54 for Windows and Mac; Linux rollout details are not exposed in the public snippets I found. |
| Scanning / exposure reality | Shodan/Censys/FOFA are basically irrelevant here because this is client-side browser code, not an internet-listening service. Exposure is broad by install base, but narrow by exploitability because an attacker must first win renderer execution. |
| Disclosure timing | Your intel says disclosed 2026-06-05; NVD shows the CVE record received on 2026-06-04 and modified on 2026-06-05. Treat June 4-5, 2026 as the public disclosure window. |
| Reporting researcher / org | Public metadata does not name an external reporter. The visible record attributes the source to Chrome, and the linked Chromium bug is permission-restricted. |
noisgate verdict.
The single factor that drives this into LOW is the prerequisite attacker position: the adversary must already have compromised Chrome's renderer process before CVE-2026-11244 is useful. That makes it exploit-chain glue with limited confidentiality impact, not a practical standalone enterprise intrusion path.
Why this verdict
- Baseline already starts low: vendor/CISA-ADP scoring is
3.1 LOW, and the public impact is confidentiality-only with no integrity or availability loss. - Requires prior compromise: the attacker must already control the renderer process, which implies a separate exploit stage or earlier compromise. That is compounding downward pressure because this bug is post-initial-access by definition.
- User interaction and high complexity narrow the reachable population: the victim still has to hit attacker-controlled content and the chain is brittle enough to score
AC:H. Modern browser defenses and telemetry are more likely to break or expose the earlier stage. - Wide install base does not equal wide exposure: Chrome is everywhere, but this flaw is not a remotely scannable service bug. Real exploitability is limited by chain requirements, not by market share.
Why not higher?
It is not higher because there is no public sign that CVE-2026-11244 is being exploited in the wild, and the bug does not hand the attacker initial code execution. The renderer-compromise prerequisite is a major real-world brake; if an attacker already has that, this CVE is just one more step in a harder chain.
Why not lower?
It is not IGNORE because browsers are high-frequency attack surfaces and this flaw still weakens origin isolation once chained. Even low-severity Chrome issues deserve eventual coverage in your evergreen browser update program, especially on unmanaged or lagging endpoints.
What to do — in priority order.
- Enforce evergreen Chrome updates — Push Chrome auto-update compliance through your endpoint management stack and close version drift to
149.0.7827.53or later. For a LOW verdict there is no SLA; treat as backlog hygiene, so fold this into your normal browser maintenance cycle rather than opening an exception bridge. - Hunt for stale browser cohorts — Query EDR, software inventory, or MDM for endpoints below
149.0.7827.53and focus on unmanaged laptops, VDI gold images, and kiosk systems where Chrome often lags. For LOW, there is no SLA; treat as backlog hygiene, but stale browser populations are where chained bugs become durable risk. - Reduce high-risk browsing on privileged endpoints — Keep administrative workflows off general web-browsing endpoints, or isolate them with browser separation/VDI where feasible. This does not change the CVE's rating, but it cuts the chance that a separate renderer exploit exists to make this bug relevant; for LOW, implement as standard hardening with no special deadline.
- A WAF does not help; this is browser-client logic, not a server-side request path you can shield at the edge.
- External perimeter scanning does not help; there is no internet-listening service to find or verify.
- Relying on MFA does not address the flaw itself; this is about same-origin isolation after renderer compromise, not account login assurance.
Crowdsourced verification payload.
Run this on the target endpoint or through your software-distribution/EDR script runner. Invoke it as python3 check_cve_2026_11244.py or point it at a specific binary with python3 check_cve_2026_11244.py --path "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"; no admin rights are normally required, but reading some installation paths on locked-down Windows images may need standard endpoint-management privileges.
#!/usr/bin/env python3
# check_cve_2026_11244.py
# Determine whether locally installed Google Chrome is vulnerable to CVE-2026-11244.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
import argparse
import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path
PATCHED_VERSION = (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 cmp_versions(a, b):
return (a > b) - (a < b)
def run_cmd(cmd):
try:
p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE, text=True, timeout=10)
if p.returncode == 0:
return p.stdout.strip() or p.stderr.strip()
except Exception:
pass
return None
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')
]
suffixes = [
r'Google\Chrome\Application\chrome.exe',
r'Google\Chrome Beta\Application\chrome.exe'
]
for base in envs:
if base:
for suf in suffixes:
paths.append(str(Path(base) / Path(suf)))
elif 'darwin' in system:
paths.extend([
'/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
str(Path.home() / 'Applications/Google Chrome.app/Contents/MacOS/Google Chrome')
])
else:
paths.extend([
'/usr/bin/google-chrome',
'/usr/bin/google-chrome-stable',
'/opt/google/chrome/chrome',
'/snap/bin/chromium',
])
for bin_name in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:
p = shutil.which(bin_name)
if p:
paths.append(p)
# de-dup while preserving order
seen = set()
out = []
for p in paths:
if p and p not in seen:
seen.add(p)
out.append(p)
return out
def get_version_from_binary(bin_path):
out = run_cmd([bin_path, '--version'])
if out:
return parse_version(out), out
return None, None
def get_version_windows_registry():
if platform.system().lower() != 'windows':
return None, None
reg_paths = [
r'HKLM\Software\Google\Chrome\BLBeacon',
r'HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon',
r'HKCU\Software\Google\Chrome\BLBeacon'
]
for reg_path in reg_paths:
out = run_cmd(['reg', 'query', reg_path, '/v', 'version'])
if out:
v = parse_version(out)
if v:
return v, out
return None, None
def main():
parser = argparse.ArgumentParser(description='Check local Chrome version for CVE-2026-11244')
parser.add_argument('--path', help='Explicit path to Chrome binary')
parser.add_argument('--version', help='Explicit version string to test, e.g. 149.0.7827.52')
args = parser.parse_args()
if args.version:
v = parse_version(args.version)
if not v:
print('UNKNOWN: could not parse supplied version string')
sys.exit(2)
if cmp_versions(v, PATCHED_VERSION) < 0:
print(f'VULNERABLE: supplied version {args.version} is older than 149.0.7827.53')
sys.exit(1)
print(f'PATCHED: supplied version {args.version} is at or above 149.0.7827.53')
sys.exit(0)
checked = []
if args.path:
checked.append(args.path)
v, raw = get_version_from_binary(args.path)
if v:
if cmp_versions(v, PATCHED_VERSION) < 0:
print(f'VULNERABLE: {args.path} -> {raw}')
sys.exit(1)
print(f'PATCHED: {args.path} -> {raw}')
sys.exit(0)
print(f'UNKNOWN: could not execute or parse version from {args.path}')
sys.exit(2)
if platform.system().lower() == 'windows':
v, raw = get_version_windows_registry()
if v:
if cmp_versions(v, PATCHED_VERSION) < 0:
print(f'VULNERABLE: registry reports Chrome version {v[0]}.{v[1]}.{v[2]}.{v[3]}')
sys.exit(1)
print(f'PATCHED: registry reports Chrome version {v[0]}.{v[1]}.{v[2]}.{v[3]}')
sys.exit(0)
for path in candidate_paths():
checked.append(path)
if os.path.exists(path):
v, raw = get_version_from_binary(path)
if v:
if cmp_versions(v, PATCHED_VERSION) < 0:
print(f'VULNERABLE: {path} -> {raw}')
sys.exit(1)
print(f'PATCHED: {path} -> {raw}')
sys.exit(0)
if checked:
print('UNKNOWN: Chrome not found or version could not be parsed. Checked: ' + ', '.join(checked))
else:
print('UNKNOWN: no Chrome candidates found')
sys.exit(2)
if __name__ == '__main__':
main()
If you remember one thing.
149.0.7827.53, and clean up unmanaged/stale cohorts as backlog hygiene; for a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA — treat it as standard maintenance, not an escalation. If your browser fleet is already auto-updating, document the chain-dependent nature of the bug and move on.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.