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

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

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

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.

"This is exploit-chain glue, not an initial-access fire drill"
02 · The Attack Path

3 steps from start to impact.

STEP 01

Land code execution in the renderer first

The attacker needs a separate bug or exploit chain that yields control of Chrome's renderer process. CVE-2026-11244 does not provide that foothold by itself; it only becomes useful after the renderer is already compromised. In practice, this is the gating step that kills urgency for standalone prioritization.
Conditions required:
  • Victim is running Chrome older than 149.0.7827.53
  • Attacker has a separate working renderer-compromise primitive
  • Victim reaches attacker-controlled content
Where this breaks in practice:
  • 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
Detection/coverage: No network scanner will prove this prerequisite. Detection is mostly via browser version inventory plus telemetry for renderer crashes, exploit attempts, or suspicious child-process behavior.
STEP 02

Trigger the WebAuthentication validation flaw

With renderer control, the attacker serves or drives the victim into a crafted HTML page that abuses the WebAuthentication code path. The stated effect is bypass of same-origin policy, which expands what the already-compromised renderer can read across origin boundaries. Weaponization here is the crafted page itself, not a standalone public exploit kit.
Conditions required:
  • Renderer compromise is already in place
  • A vulnerable WebAuthentication code path is reachable
  • User interaction remains part of the chain
Where this breaks in practice:
  • 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
Detection/coverage: Coverage is weak at the packet layer; focus on browser version drift, exploit telemetry, and Chrome crash/abuse monitoring. Signature-based scanners are unlikely to validate live exploitability.
STEP 03

Read cross-origin data

After policy bypass, the attacker can potentially access data that should have remained origin-isolated. Based on the published CVSS impact, the public consequence is limited confidentiality loss rather than account takeover, integrity change, or availability damage. That keeps the blast radius materially below the browser RCE class.
Conditions required:
  • Useful victim session or sensitive origin data is present in-browser
  • Data of interest is accessible via the bypassed origin boundary
Where this breaks in practice:
  • 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
Detection/coverage: Direct detection is poor. You are mostly left with preventive hygiene: keep Chrome current and monitor for abnormal browser exploitation patterns.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo 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 availabilityNo public PoC or Metasploit/Nuclei-style check located. Chromium issue details are restricted, which is normal for Chrome until the user base is updated.
EPSS0.00027 provided in your intel, which is effectively floor-level exploit likelihood and consistent with a chained, low-impact browser bug.
KEV statusNot KEV-listed. No date-added because it is absent from the CISA catalog.
CVSS vectorCVSS: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 versionsGoogle Chrome prior to 149.0.7827.53; NVD currently models the vulnerable Chrome application on Windows, Linux, and macOS.
Fixed versionPatched 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 realityShodan/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 timingYour 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 / orgPublic metadata does not name an external reporter. The visible record attributes the source to Chrome, and the linked Chromium bug is permission-restricted.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to LOW (2.2/10)

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.

HIGH The downgrade pressure created by the 'compromised renderer process' prerequisite
MEDIUM The exact patched rollout details across all Chrome desktop platforms
MEDIUM Absence of public exploitation evidence at time of assessment

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.

05 · Compensating Control

What to do — in priority order.

  1. Enforce evergreen Chrome updates — Push Chrome auto-update compliance through your endpoint management stack and close version drift to 149.0.7827.53 or 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.
  2. Hunt for stale browser cohorts — Query EDR, software inventory, or MDM for endpoints below 149.0.7827.53 and 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.
  3. 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.
What doesn't work
  • 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.
06 · Verification

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.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/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()
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat CVE-2026-11244 like an out-of-band browser emergency. Put it into your normal evergreen browser sweep, use version inventory to find endpoints below 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

  1. NVD entry for CVE-2026-11244
  2. Chrome Releases archive home
  3. Chrome early stable update to 149.0.7827.53/.54
  4. Chrome Releases 2026 archive
  5. Chromium issue reference 497609145
  6. CISA Known Exploited Vulnerabilities catalog
  7. FIRST EPSS API query for CVE-2026-11244
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.