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

Integer overflow in Fonts in Google Chrome prior to 149

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

This is a peephole in one apartment window, not a master key to the whole building

CVE-2026-11299 is an out-of-bounds read in Chrome's Fonts handling. A user has to be lured into rendering attacker-controlled content, and the bug can then disclose data from the affected renderer process. Google shipped fixes in Chrome 149 on 2026-06-02: desktop builds prior to 149.0.7827.53/54 for Windows/macOS and 149.0.7827.53 for Linux are affected; Android 149 carries the corresponding desktop security fixes.

The supplied 6.5 / MEDIUM baseline overstates operational urgency for enterprise patch queues. Google's own Chrome release entry tags this CVE Low, and that matches reality better: this is an information leak, not code execution; it needs UI:R; there is no KEV listing or public exploitation evidence; and Chrome's sandbox, site isolation, and per-renderer memory boundaries keep the likely blast radius narrow.

"Client-side memory disclosure with user interaction, no exploit signal, and blast radius mostly capped to one browser process."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver malicious web content

The attacker needs a user to browse to a crafted page or embedded content that exercises the vulnerable font parsing path. In practice this means phishing, malvertising, or a compromised site rather than a blind internet-wide hit.
Conditions required:
  • Unauthenticated remote reachability to the victim through the web
  • Victim uses affected Chrome/Chromium build
  • Victim renders attacker-controlled content
Where this breaks in practice:
  • Requires user interaction rather than direct service exploitation
  • Enterprise browsing controls, Safe Browsing, URL filtering, and ad blocking reduce reach
  • Browser auto-update shrinks the vulnerable population quickly
Detection/coverage: Gateway and browser telemetry may catch the lure, but vulnerability scanners mostly detect this by version inventory rather than exploit pattern.
STEP 02

Trigger the Fonts out-of-bounds read

The crafted content causes the Fonts component to read past intended bounds, leaking memory from the renderer context. This is a disclosure primitive, so the attacker is trying to harvest bytes, not directly execute code.
Conditions required:
  • The vulnerable code path is reachable from the rendered content
  • The exploit stays stable enough to produce useful disclosure
Where this breaks in practice:
  • Modern browser hardening makes memory disclosure less deterministic
  • Exploit reliability can vary by platform, build flags, and renderer state
Detection/coverage: EDR is weak here unless the exploit crashes the renderer; browser crash telemetry and sandbox violation logs are more likely signals than classic IOC scanning.
STEP 03

Extract useful secrets from renderer memory

Any value to the attacker depends on what happens to be resident in the compromised renderer process at that time: page data, tokens, fragments of form contents, or cross-context artifacts if other defenses fail. That is materially less useful than arbitrary code execution or sandbox escape.
Conditions required:
  • Sensitive data is present in the same renderer process
  • The leak returns attacker-usable bytes rather than noise
Where this breaks in practice:
  • Chrome Site Isolation and process separation reduce what is co-located in one renderer
  • Many enterprises already protect session material with short-lived tokens and MFA
Detection/coverage: No reliable network signature; focus on browser version compliance and anomalous crash spikes.
STEP 04

Monetize the leak

The attacker still has to turn any disclosed data into account access, internal reconnaissance, or a follow-on exploit chain. Without a second bug or exposed secrets of real value, many successful triggers end as low-grade disclosure with little enterprise impact.
Conditions required:
  • Leaked data includes reusable secrets or sensitive content
  • Attacker has a practical follow-on use for the disclosed memory
Where this breaks in practice:
  • MFA, device binding, and token scoping often blunt stolen web material
  • Per-user blast radius limits enterprise-wide consequences
Detection/coverage: Downstream detections come from identity misuse, impossible travel, token abuse, or suspicious SaaS access—not from the font bug itself.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo public evidence of active exploitation found as of 2026-06-05; not listed in CISA KEV.
Proof-of-concept availabilityNo widely referenced public PoC or weaponized exploit surfaced in the sources reviewed. That sharply lowers urgency versus browser RCEs that get same-day GitHub demos.
EPSS0.00028 from the prompt intel, which is extremely low expected exploitation probability. Percentile was not confirmed from an authoritative public page in the reviewed sources.
KEV statusNo. CISA KEV catalog reviewed with no listing for CVE-2026-11299 as of 2026-06-05.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N — easy to trigger once a user lands on content, but UI:R and confidentiality-only impact are the important brakes.
Affected versionsChrome desktop prior to 149.0.7827.53/54 on Windows/macOS and prior to 149.0.7827.53 on Linux. Google published Chrome 149 stable on 2026-06-02.
Fixed versionsUpgrade to 149.0.7827.53+ as the safe floor across enterprise inventory; Windows/macOS stable shipped as 149.0.7827.53/54. Distro backports exist; for example, openSUSE maintenance shipped a Chromium fixset including this CVE.
Exposure and scanning realityThis is a client-side browser flaw, not an internet-facing daemon. Shodan/Censys/FOFA/GreyNoise are mostly irrelevant; exposure is measured by endpoint browser version inventory, not open ports.
Disclosure and reporterGoogle's release stream shows the fix on 2026-06-02 and the CVE record surfaced publicly on 2026-06-05. Google credits [email protected], reported 2026-04-14.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (3.9/10)

The decisive factor is that this bug is a user-driven information leak in a browser renderer, not a server-side foothold or code-execution primitive. Even at Chrome scale, the combination of UI:R, no exploitation evidence, and per-process blast radius keeps this in backlog territory rather than emergency patch territory.

HIGH No active exploitation / no KEV signal
MEDIUM Impact bounded by Chrome renderer and browser isolation model

Why this verdict

  • User interaction is mandatory: the attacker cannot hit a listening service; they need a user to render attacker-controlled content first.
  • This is disclosure, not execution: the practical outcome is leaked renderer memory, which is materially less dangerous than Chrome sandbox escape or RCE.
  • Real-world population narrows fast: Chrome auto-update plus enterprise browser management compresses exposure far faster than on server middleware.
  • No threat intel amplifier: no KEV listing, no public campaign reporting, no obvious public PoC, and an EPSS value close to floor.

Why not higher?

A higher rating would need at least one strong amplifier: active exploitation, a public reliable PoC, a sandbox escape chain, or evidence that the leak routinely exposes reusable enterprise secrets. None of that is present here. On top of that, this is post-lure and per-user, not a broad unauthenticated service compromise.

Why not lower?

It is still a remotely triggerable browser memory disclosure in an extremely widespread product. In a 10,000-host estate, someone will eventually browse hostile content, so this is not ignorable. Sensitive renderer memory leaks can become chainable intelligence for a second-stage attack even when they are weak standalone bugs.

05 · Compensating Control

What to do — in priority order.

  1. Enforce browser auto-update — Make sure managed Chrome/Chromium channels are allowed to self-update and restart on the next normal user disruption window. For a LOW verdict there is no mitigation SLA; do this in routine endpoint hygiene because stale browser populations are what turn minor client bugs into recurring exposure.
  2. Block unmanaged browser versions — Use EDR, MDM, or application control to flag or restrict old Chrome/Chromium builds that fall below 149.0.7827.53. This is the most scalable control for a 10,000-host estate, and for LOW severity it belongs in standard compliance enforcement rather than emergency change.
  3. Harden the web path — Keep Safe Browsing, DNS/web filtering, and ad/malvertising controls enabled because they cut off the lure stage that this CVE depends on. With no active exploitation evidence, routine maintenance timing is fine; the point is reducing the chance of users ever rendering hostile content.
  4. Monitor browser crash anomalies — Collect Chrome crash and renderer instability telemetry so a sudden spike around font handling stands out. This will not prevent exploitation, but it can surface testing or unreliable weaponization attempts during the normal backlog window.
What doesn't work
  • Perimeter firewall rules do not solve this; there is no inbound service to shield because the attack arrives through normal user web browsing.
  • Network IPS signatures are weak coverage; memory disclosure through crafted browser content rarely yields durable signatures with good precision.
  • MFA does not prevent the bug from triggering; it only reduces value if leaked material later includes reusable session data.
06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or via your software inventory agent to validate the installed Chrome/Chromium version. Invoke with python3 check_chrome_cve_2026_11299.py on Linux/macOS or py check_chrome_cve_2026_11299.py on Windows; standard user rights are usually enough because the script only reads executable metadata.

noisgate-verify.py
PYTHONREAD-ONLYSAFE
#!/usr/bin/env python3
# check_chrome_cve_2026_11299.py
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import os
import platform
import re
import shutil
import subprocess
import sys
from pathlib import Path

SAFE_FLOOR = (149, 0, 7827, 53)
CANDIDATES = {
    'Windows': [
        r'C:\\Program Files\\Google\\Chrome\\Application\\chrome.exe',
        r'C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe',
        r'C:\\Program Files\\Chromium\\Application\\chrome.exe',
        r'C:\\Program Files (x86)\\Chromium\\Application\\chrome.exe',
        r'C:\\Program Files\\Microsoft\\Edge\\Application\\msedge.exe',
        r'C:\\Program Files (x86)\\Microsoft\\Edge\\Application\\msedge.exe',
    ],
    'Darwin': [
        '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
        '/Applications/Chromium.app/Contents/MacOS/Chromium',
        '/Applications/Microsoft Edge.app/Contents/MacOS/Microsoft Edge',
    ],
    'Linux': [
        '/usr/bin/google-chrome',
        '/usr/bin/google-chrome-stable',
        '/usr/bin/chromium',
        '/usr/bin/chromium-browser',
        '/snap/bin/chromium',
        '/usr/bin/microsoft-edge',
        '/usr/bin/microsoft-edge-stable',
    ],
}


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 version_str(v):
    return '.'.join(str(x) for x in v)


def is_patched(v):
    return v >= SAFE_FLOOR


def run_version(path):
    try:
        p = subprocess.run([path, '--version'], capture_output=True, text=True, timeout=8)
        out = (p.stdout or '') + ' ' + (p.stderr or '')
        return parse_version(out)
    except Exception:
        return None


def find_installs():
    sysname = platform.system()
    found = []

    for p in CANDIDATES.get(sysname, []):
        if os.path.exists(p):
            found.append(p)

    for cmd in ['google-chrome', 'google-chrome-stable', 'chromium', 'chromium-browser', 'msedge', 'microsoft-edge', 'microsoft-edge-stable']:
        loc = shutil.which(cmd)
        if loc and loc not in found:
            found.append(loc)

    return found


def main():
    installs = find_installs()
    if not installs:
        print('UNKNOWN - no Chrome/Chromium-family executable found')
        sys.exit(2)

    results = []
    for path in installs:
        ver = run_version(path)
        if ver is None:
            results.append((path, None, 'UNKNOWN'))
        elif is_patched(ver):
            results.append((path, ver, 'PATCHED'))
        else:
            results.append((path, ver, 'VULNERABLE'))

    # Print per-install result
    for path, ver, state in results:
        if ver is None:
            print(f'{state} - {path} - version unreadable')
        else:
            print(f'{state} - {path} - {version_str(ver)}')

    # Overall state: vulnerable wins, else patched if any patched and none vulnerable, else unknown
    if any(state == 'VULNERABLE' for _, _, state in results):
        sys.exit(1)
    if any(state == 'PATCHED' for _, _, state in results):
        sys.exit(0)
    sys.exit(2)


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

If you remember one thing.

TL;DR
Monday morning, do not burn emergency change capacity on this one unless your browser fleet is badly behind. Use endpoint inventory to find Chrome/Chromium installs below 149.0.7827.53, fold them into the next normal browser maintenance wave, and keep normal web filtering and auto-update controls in place. For a LOW verdict, the noisgate mitigation SLA is no SLA (treat as backlog hygiene) and the noisgate remediation SLA is likewise no SLA (treat as backlog hygiene); in practice that means fix it in routine endpoint patching, not an out-of-band campaign.

Sources

  1. Chrome Releases 2026 archive
  2. Chrome 149 release notes
  3. Canadian Centre for Cyber Security advisory AV26-544
  4. GovCERT.HK alert A26-06-08
  5. openSUSE Chromium maintenance patchinfo
  6. CISA Known Exploited Vulnerabilities catalog
  7. FIRST EPSS model 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.