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

Out of bounds read in Media in Google Chrome prior to 149

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

This is a peeping hole in the wall, not a front-door kick-in

CVE-2026-10998 is an out-of-bounds read in Chrome's Media component affecting Google Chrome versions prior to 149.0.7827.53. Public wording says the attacker must be on the *local network segment*, which makes this an adjacent-network bug rather than an internet-reachable browser issue. The disclosed impact is memory disclosure, not code execution: think small slices of process memory if a crafted media-related network interaction reaches the vulnerable path.

The vendor's MEDIUM bucket is basically right, but the supplied AV:L score baseline is too low-level for the actual story. If the advisory text is accurate, this is closer to *adjacent network* reachability than *local attacker on the host*, so I bump the score a bit; still, the local-LAN prerequisite, sparse technical disclosure, lack of exploitation evidence, and low confidentiality-only impact keep it firmly out of HIGH.

"Same-LAN only and low-impact read keep this out of the fire drill pile, but the vendor score undershoots the real reachability"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Get onto the victim's network segment

The attacker first needs position on the same LAN, Wi-Fi, or otherwise adjacent network as the target endpoint. That immediately narrows the threat model: this is not an internet spray-and-pray Chrome bug. In enterprise terms, this usually means guest Wi-Fi overlap, a compromised internal device, or hostile presence in a branch or campus segment.
Conditions required:
  • Attacker has adjacent-network access to the target
  • Victim endpoint is running vulnerable Chrome prior to 149.0.7827.53
Where this breaks in practice:
  • Requires post-compromise or physical proximity in many real environments
  • Segmentation, NAC, and separate guest SSIDs can cut this path off entirely
Detection/coverage: Traditional vuln scanners will identify the Chrome version, but they will not prove reachability from an adjacent attacker position.
STEP 02

Reach the media-related network handling path

Based on the advisory wording, the vulnerable code path is likely exercised by media-related network traffic rather than by a generic web page. The exact trigger details are not public in retrieved sources, so this step is an inference from the CNA description, not a confirmed exploit recipe. The important operational point is that the attacker must hit a fairly specific browser subsystem, not just open TCP to the host.
Conditions required:
  • A media/network feature path in Chrome is active or reachable
  • The crafted traffic reaches the target endpoint without being filtered
Where this breaks in practice:
  • Sparse public bug detail means weaponization is less turnkey
  • Feature-specific trigger paths usually reduce exploitable population versus broad HTML/JS bugs
Detection/coverage: Network IDS is unlikely to have reliable signatures without public PoC details; telemetry may instead come from unusual mDNS/SSDP/casting traffic or browser crash artifacts.
STEP 03

Trigger the out-of-bounds read

The malicious traffic causes Chrome's Media component to read beyond intended bounds. Out-of-bounds reads are usually about information disclosure first, not immediate control-flow hijack. In practice, the attacker is trying to leak bits of process memory, not detonate a one-packet RCE.
Conditions required:
  • Targeted parser/state machine accepts the crafted input
  • Browser process survives long enough to expose useful memory
Where this breaks in practice:
  • Many OOB reads crash noisily before producing useful data
  • Chrome sandboxing and memory-hardening reduce blast radius
Detection/coverage: EDR can sometimes surface browser crashes or abnormal child-process termination, but coverage for pure read-only memory disclosure is inconsistent.
STEP 04

Turn disclosure into useful theft

Any real impact depends on whether the leaked bytes contain something operationally valuable such as tokens, origin data, or sensitive page content. With only C:L disclosed, expect limited and situational value rather than broad account takeover at scale. That makes exploitation opportunistic, not a dependable enterprise-wide kill chain.
Conditions required:
  • Leaked memory contains sensitive material
  • Attacker can capture or reconstruct returned/crashed-state data
Where this breaks in practice:
  • Low-confidence reward from each attempt
  • No published evidence that attackers are chaining this into reliable post-exploitation
Detection/coverage: No off-the-shelf scanner validates data theft here; prioritize browser version inventory plus crash and network telemetry correlation.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public exploitation evidence found in retrieved sources; not KEV-listed.
Proof-of-concept availabilityNo public PoC or weaponized repo found in retrieved sources.
EPSSUser-supplied EPSS is 0.00005, which is effectively near-floor exploit probability; percentile was not independently confirmed from retrieved FIRST data.
KEV statusNo — absent from the CISA KEV catalog as checked against retrieved sources.
CVSS vector reality checkVendor-supplied vector is CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N, but the description says *attacker on the local network segment*, which operationally reads more like adjacent network than local host.
Affected versionsGoogle Chrome prior to 149.0.7827.53; retrieved Chrome release material shows 149.0.7827.53/.54 in the early stable rollout for desktop.
Fixed versionPatch baseline is 149.0.7827.53; later tags such as 149.0.7827.54 and above are beyond the vulnerable cutoff.
Exposure modelThis is client-side adjacent-network exposure, not a public-facing server surface. Shodan/Censys-style internet counts are therefore not a meaningful prioritization signal.
Disclosure date2026-06-04 per the supplied intel and third-party CVE aggregators in retrieved results.
Reporting detailsPublicly retrieved sources did not expose a researcher credit or bug ID for this specific CVE; Chrome often withholds bug detail until most users are updated.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to MEDIUM (4.8/10)

The decisive factor is the attacker position requirement: same-LAN access massively shrinks the reachable population compared with normal Chrome drive-by bugs. I raised the score slightly because the published description implies adjacent-network reachability rather than a purely local-on-host attacker, but the limited confidentiality impact and zero exploitation evidence keep it in MEDIUM.

HIGH Version cutoff and patched baseline
MEDIUM Severity bucket assignment
LOW Exact trigger mechanics inside the Media subsystem

Why this verdict

  • Baseline adjusted up: vendor says MEDIUM/4, but the description says *local network segment*, which is more reachable than AV:L and justifies a modest score increase.
  • Major downward pressure: attacker must be on the same network segment, which usually implies physical proximity, rogue Wi-Fi presence, or a prior internal foothold.
  • Impact capped: disclosed effect is out-of-bounds read with C:L/I:N/A:N, so this is not the kind of Chrome bug that reliably turns into endpoint takeover.

Why not higher?

Because every serious step in the chain narrows the real-world population: adjacent network only, likely feature-specific traffic, and confidentiality-only impact. If this were internet-reachable or paired with code execution, the score would jump fast; it is not.

Why not lower?

Because Chrome is ubiquitous, no user interaction is stated, and a hostile same-LAN actor is a real enterprise scenario on guest Wi-Fi, branch networks, and already-compromised segments. Also, the vendor's AV:L framing likely understates operational reachability if the advisory text is taken at face value.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update compliance — Make sure managed endpoints actually converge on 149.0.7827.53 or later and flag stragglers via fleet inventory. For a MEDIUM finding there is no mitigation SLA — use this as routine control enforcement while you work inside the 365-day remediation window.
  2. Segment guest and untrusted Wi-Fi from corporate endpoints — The bug's entire value proposition starts with adjacent-network access, so isolate guest SSIDs, contractor VLANs, lab segments, and unmanaged BYOD away from employee workstations. There is no mitigation SLA for MEDIUM, but this is worthwhile hardening immediately because it cuts off the main prerequisite.
  3. Restrict local discovery and casting where unused — If your environment does not need media discovery/casting workflows, limit or disable them through enterprise policy and network controls such as mDNS/SSDP filtering between segments. This is a temporary exposure reducer, not a substitute for patching, and for MEDIUM there is no mitigation SLA.
  4. Watch for Chrome crash clusters — Correlate EDR/browser telemetry for sudden spikes in chrome renderer/GPU/media-process crashes on specific Wi-Fi or branch segments. Use it as a hunting signal while the fleet rolls forward; there is no mitigation SLA for MEDIUM.
What doesn't work
  • A generic perimeter WAF does not help; the attack is not described as a public web-app request path.
  • MFA is irrelevant to the memory-safety trigger itself; it may reduce follow-on abuse of stolen data, but it does not stop the browser bug.
  • Internet exposure reduction alone misses the point; this is about adjacent-network reachability, not inbound exposure from the public internet.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your endpoint management tooling. Invoke it with python3 verify_cve_2026_10998.py on macOS/Linux or py verify_cve_2026_10998.py on Windows; no admin rights are usually needed, though registry access on locked-down Windows images may require standard local read permissions.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# verify_cve_2026_10998.py
# Checks whether Google Chrome is older than 149.0.7827.53
# Outputs exactly 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

PATCHED = (149, 0, 7827, 53)


def parse_version(text):
    m = re.search(r'(\d+)\.(\d+)\.(\d+)\.(\d+)', text or '')
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def cmp_version(a, b):
    return (a > b) - (a < b)


def run_cmd(cmd):
    try:
        p = subprocess.run(cmd, capture_output=True, text=True, timeout=10)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return out.strip()
    except Exception:
        return ''


def get_windows_version():
    candidates = [
        ["reg", "query", r"HKLM\Software\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKLM\Software\WOW6432Node\Google\Chrome\BLBeacon", "/v", "version"],
        ["reg", "query", r"HKCU\Software\Google\Chrome\BLBeacon", "/v", "version"],
    ]
    for cmd in candidates:
        out = run_cmd(cmd)
        v = parse_version(out)
        if v:
            return v
    exe_candidates = [
        os.path.join(os.environ.get("ProgramFiles", r"C:\Program Files"), "Google", "Chrome", "Application", "chrome.exe"),
        os.path.join(os.environ.get("ProgramFiles(x86)", r"C:\Program Files (x86)"), "Google", "Chrome", "Application", "chrome.exe"),
        os.path.join(os.environ.get("LOCALAPPDATA", ""), "Google", "Chrome", "Application", "chrome.exe"),
    ]
    for exe in exe_candidates:
        if exe and os.path.exists(exe):
            out = run_cmd([exe, "--version"])
            v = parse_version(out)
            if v:
                return v
    return None


def get_macos_version():
    app = "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome"
    if os.path.exists(app):
        out = run_cmd([app, "--version"])
        v = parse_version(out)
        if v:
            return v
    mdls = run_cmd(["mdls", "-name", "kMDItemVersion", "/Applications/Google Chrome.app"])
    v = parse_version(mdls)
    if v:
        return v
    return None


def get_linux_version():
    bins = ["google-chrome", "google-chrome-stable", "chrome"]
    for b in bins:
        path = shutil.which(b)
        if path:
            out = run_cmd([path, "--version"])
            v = parse_version(out)
            if v:
                return v
    return None


def main():
    system = platform.system().lower()
    if 'windows' in system:
        ver = get_windows_version()
    elif 'darwin' in system:
        ver = get_macos_version()
    else:
        ver = get_linux_version()

    if not ver:
        print("UNKNOWN")
        sys.exit(2)

    if cmp_version(ver, PATCHED) < 0:
        print("VULNERABLE")
        sys.exit(1)
    else:
        print("PATCHED")
        sys.exit(0)


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

If you remember one thing.

TL;DR
Monday morning: pull a version report for all managed Chrome installs and clean up anything still below 149.0.7827.53, especially on laptops that roam onto shared Wi-Fi, branch offices, labs, and contractor networks. For a MEDIUM reassessment there is no noisgate mitigation SLA — go straight to the 365-day remediation window; in practice, because this is Chrome and updates are easy, use your normal browser ring to get compliant quickly and finish well inside the noisgate remediation SLA of ≤365 days, while using segmentation and discovery/casting restrictions as temporary exposure reducers for laggards.

Sources

  1. Chrome Releases: Early Stable Update for Desktop
  2. Chrome for Developers: Change in release schedule from Chrome 110
  3. Chromium source tags including 149.0.7827.53
  4. CISA Known Exploited Vulnerabilities Catalog
  5. FIRST EPSS data and statistics
  6. Quanteta CVE tracker entry set showing CVE-2026-10998 metadata
  7. VulDB search result for CVE-2026-10998
  8. CVE.report search result containing CVE-2026-10998
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.