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

Inappropriate implementation in Autofill in Google Chrome prior to 149

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

This is a peephole in a front door, not a battering ram

CVE-2026-11265 is a Google Chrome Autofill bug that affects versions prior to 149.0.7827.53 and can let a malicious site leak data across origins. Public package metadata also labels it as an Autofill validation flaw, and Google shipped fixes in the 149.0.7827.53/.54 release line on May 29, 2026; downstream Chromium packaging picked up the same fix train.

Google's HIGH 7.5 baseline overstates enterprise urgency in real life. This is still a browser-delivered remote bug, but the observed impact is *confidentiality-only*, public exploit detail is sparse, there is no KEV listing, EPSS is near-zero, and the attack usually depends on the victim hitting a malicious page *plus* having useful Autofill data present to steal.

"Wide product, narrow outcome: this is a browser data leak, not a fleet-wide break-glass event"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on a crafted page

The attacker needs a page that exercises the vulnerable Autofill code path; think malicious site, malvertising, or a compromised legit page. No public weaponized PoC was found in the sources reviewed, so the likely tool is a private HTML/JS trigger rather than a commodity exploit kit.
Conditions required:
  • Victim uses vulnerable Chrome prior to 149.0.7827.53
  • Victim browses attacker-controlled or attacker-influenced web content
Where this breaks in practice:
  • This is endpoint delivery, not unauthenticated exploitation of an exposed server
  • Public exploit details are limited, which raises attacker development cost
Detection/coverage: Network scanners will not find this. Coverage comes from browser version inventory, web telemetry, and detections for suspicious exfil from browser processes.
STEP 02

Trigger the Autofill validation flaw

The crafted page abuses an Autofill implementation bug to cross an origin boundary and expose data it should not be able to read. Based on the public summary, the exploit primitive is an origin-protection failure tied to Autofill handling rather than memory corruption or code execution.
Conditions required:
  • Autofill-relevant browser state is present
  • The vulnerable UI/data handling path is reachable in the victim session
Where this breaks in practice:
  • Not every user profile will hold interesting Autofill material
  • Enterprise browser hardening, disabled Autofill, or profile separation can reduce payoff
Detection/coverage: Most vuln scanners can only flag version susceptibility. Runtime detection is weak unless you have browser telemetry or DLP catching anomalous outbound data.
STEP 03

Read and stage cross-origin data

Once the origin boundary is bypassed, the attacker can collect whatever data the bug exposes and stage it in JavaScript memory for exfiltration. The practical outcome is data theft from the browsing context, not device takeover.
Conditions required:
  • Leaked data exists and is accessible to the exploit
  • Browser policies do not otherwise block the exfil path
Where this breaks in practice:
  • Impact is bounded to what the browser/session can leak
  • No evidence in reviewed sources of privilege escalation, persistence, or sandbox escape
Detection/coverage: Watch for suspicious POST/XHR/fetch traffic from browser processes to low-reputation domains; CSP/reporting and secure web gateways may provide partial visibility.
STEP 04

Exfiltrate to attacker infrastructure

The stolen material is sent off-box using ordinary web requests. This is the easiest step operationally because browsers are expected to talk to the internet all day.
Conditions required:
  • Outbound browser traffic to attacker infrastructure is allowed
Where this breaks in practice:
  • DLP, SWG, DNS filtering, and egress controls can still catch or block commodity exfil domains
  • Attack value is lower if only low-sensitivity profile data is exposed
Detection/coverage: Good SWG/DNS controls can see this step; they do not prevent the underlying version-based exposure.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation in the reviewed sources, and not listed in CISA KEV.
Proof-of-concept availabilityNo public PoC or exploit repo was found during review. That does not mean unexploitable; it means attacker tradecraft is likely private right now.
EPSS0.00014 from the user intel block — effectively near-zero predicted exploitation probability. Percentile was not independently confirmed from an authoritative record.
KEV statusNot present in the CISA Known Exploited Vulnerabilities Catalog.
CVSS vector reality checkVendor vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, which models a no-auth remote confidentiality hit. In practice, the missing friction is victim browsing context and useful Autofill state.
Affected versionsGoogle states Chrome versions prior to 149.0.7827.53 are affected; the early stable desktop fix landed as 149.0.7827.53/.54.
Fixed versionsGoogle desktop fix floor: 149.0.7827.53/.54. Beta moved to 149.0.7827.53 on the same date. openSUSE package metadata shows Chromium 149 updates carrying this CVE as well.
Exposure / scanabilityShodan/Censys/FOFA-style internet exposure data is basically not meaningful here because Chrome is a client application, not a remotely enumerable service. Your risk lives in endpoint population and browser lag, not public attack surface counts.
TimelineUser-supplied disclosure date is 2026-06-05; Google shipped the relevant fixed desktop build on 2026-05-29. Public downstream metadata appeared around 2026-06-04 to 2026-06-05.
Researcher / creditNo public researcher credit was confirmed from the accessible vendor and CVE-facing sources reviewed.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to MEDIUM (5.8/10)

The decisive downgrade is that this is a *browser-session data leak*, not server-side unauthenticated compromise or client RCE. The reachable population is large because Chrome is everywhere, but the blast radius is narrower because the attacker still needs a victim browsing event and only gets what the vulnerable Autofill/session context can expose.

HIGH Patch floor and affected product family
MEDIUM Exploit chain details inferred from sparse public summaries

Why this verdict

  • Vendor starts at 7.5, but the outcome is confidentiality-only — there is no public indication of code execution, persistence, or host compromise.
  • Requires a victim browser session — this is not an internet-facing service flaw you can hit blindly across a subnet; the attacker needs users to render crafted content.
  • Useful payload depends on local browser state — the bug matters more when Autofill holds valuable data, which is a real but narrowing condition compared with a universal browser takeover primitive.
  • Threat intel is cold — no KEV, no public campaign reporting, and an EPSS of 0.00014 all push downward.
  • Public exploit detail is thin — absent public PoC or issue disclosure, mass weaponization is less likely in the immediate term.

Why not higher?

If this had public exploit code, active abuse, or a path to credential theft at scale with no meaningful per-user dependency, I would keep it in HIGH. But the available evidence says *data leak via browser context*, not one-click fleet compromise, and that matters more than the theoretical CVSS top line.

Why not lower?

Chrome is massively deployed, and a malicious page is a realistic delivery channel. Even a confidentiality-only browser bug can still expose sensitive user data, so this is not backlog fluff or something to ignore.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update health — Verify managed endpoints are actually consuming Chrome updates and not pinned below 149.0.7827.53/.54. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but in practice you should fix update drift in the next normal browser cycle because this is a user-facing internet entry point.
  2. Reduce Autofill exposure where feasible — For high-risk cohorts, disable or restrict Autofill storage/use through enterprise browser policy if business impact is acceptable. This cuts the value of exploitation while you remediate; for MEDIUM, there is no separate mitigation SLA, so treat it as risk reduction rather than a mandated emergency control.
  3. Tighten egress filtering for browsers — Use SWG, DNS filtering, and reputation-based blocking to make exfiltration harder from browser processes. That will not cure the vuln, but it can reduce the success rate of commodity attacker infrastructure during the remediation window.
  4. Prioritize sensitive user groups first — Patch executives, finance, admins, developers, and researcher workstations ahead of the broad fleet if you cannot update all endpoints at once. The impact here is data exposure, so the *value of the victim profile* should drive sequencing.
What doesn't work
  • A perimeter vuln scanner does not solve this, because it cannot see browser-session exploitation and Chrome is not an externally exposed service.
  • Server-side WAF rules are unreliable here, because the vulnerable logic sits in the client browser and the triggering page can look like ordinary web content.
  • MFA does not meaningfully reduce the core browser data-leak condition unless the only thing exposed would have been session establishment secrets that are separately protected.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management tooling. Invoke it as python3 check_chrome_cve_2026_11265.py on macOS/Linux or py check_chrome_cve_2026_11265.py on Windows; no admin rights are required, but the script must be able to execute Chrome or read its installed version from common locations.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11265.py
# Determine whether installed Google Chrome is vulnerable to CVE-2026-11265.
# Outputs one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys

FIXED_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_ver(a, b):
    return (a > b) - (a < b)


def run_and_get_version(cmd):
    try:
        p = subprocess.run(cmd, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, text=True, timeout=5)
        out = (p.stdout or '').strip()
        v = parse_version(out)
        if v:
            return v, out, ' '.join(cmd)
    except Exception:
        pass
    return None, None, None


def candidate_commands():
    system = platform.system().lower()
    cmds = []

    if system == 'windows':
        local = os.environ.get('LOCALAPPDATA', '')
        pf = os.environ.get('PROGRAMFILES', '')
        pf86 = os.environ.get('PROGRAMFILES(X86)', '')
        paths = [
            os.path.join(local, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(pf, 'Google', 'Chrome', 'Application', 'chrome.exe'),
            os.path.join(pf86, 'Google', 'Chrome', 'Application', 'chrome.exe'),
        ]
        for p in paths:
            if p and os.path.exists(p):
                cmds.append([p, '--version'])
        for name in ['chrome', 'google-chrome', 'google-chrome-stable']:
            resolved = shutil.which(name)
            if resolved:
                cmds.append([resolved, '--version'])

    elif system == 'darwin':
        mac_paths = [
            '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
            os.path.expanduser('~/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'),
        ]
        for p in mac_paths:
            if os.path.exists(p):
                cmds.append([p, '--version'])
        for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
            resolved = shutil.which(name)
            if resolved:
                cmds.append([resolved, '--version'])

    else:
        for name in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser']:
            resolved = shutil.which(name)
            if resolved:
                cmds.append([resolved, '--version'])
        linux_paths = [
            '/opt/google/chrome/chrome',
            '/usr/bin/google-chrome',
            '/usr/bin/google-chrome-stable',
            '/usr/bin/chromium',
            '/usr/bin/chromium-browser',
        ]
        for p in linux_paths:
            if os.path.exists(p):
                cmds.append([p, '--version'])

    # Deduplicate while preserving order
    seen = set()
    uniq = []
    for cmd in cmds:
        key = tuple(cmd)
        if key not in seen:
            seen.add(key)
            uniq.append(cmd)
    return uniq


def main():
    cmds = candidate_commands()
    if not cmds:
        print('UNKNOWN - Chrome executable not found in common locations')
        sys.exit(2)

    found = []
    for cmd in cmds:
        v, raw, used = run_and_get_version(cmd)
        if v:
            found.append((v, raw, used))

    if not found:
        print('UNKNOWN - Could not determine Chrome version from discovered executables')
        sys.exit(2)

    # Use the highest discovered version; multiple channels may coexist.
    found.sort(key=lambda x: x[0], reverse=True)
    version, raw, used = found[0]
    version_str = '.'.join(str(x) for x in version)
    fixed_str = '.'.join(str(x) for x in FIXED_VERSION)

    if cmp_ver(version, FIXED_VERSION) < 0:
        print(f'VULNERABLE - Found version {version_str} via [{used}] ; fixed version is {fixed_str} or later')
        sys.exit(1)
    else:
        print(f'PATCHED - Found version {version_str} via [{used}] ; fixed threshold is {fixed_str}')
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: pull a version inventory for Chrome and Chrome-derived packages, verify which cohorts are still below 149.0.7827.53/.54, and clean up update drift rather than treating this like a zero-day fire drill. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window under the noisgate remediation SLA, but because this is a browser-facing internet delivery path, most enterprises should still roll the fix in their next managed browser update wave and verify laggards instead of letting it age indefinitely.

Sources

  1. CVE Record URL
  2. Google Chrome Releases - Early Stable Update for Desktop
  3. Google Chrome Releases - Chrome Beta for Desktop Update
  4. openSUSE Chromium patch metadata listing CVE-2026-11265
  5. CISA Known Exploited Vulnerabilities Catalog
  6. FIRST EPSS data and report documentation
  7. FIRST EPSS API documentation
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.