CVE-2026-10948 · Use after free in WebRTC in Google Chrome prior to 149.0.7827.53 allowed a remote attacker to execute arbitrary code inside a sandbox via a

01 · The Real Story

This is a burglar getting into the lobby, not the vault

CVE-2026-10948 is a use-after-free in Chrome WebRTC. In practical terms, a malicious page can drive stale memory use in the browser process handling WebRTC content and achieve arbitrary code execution inside Chrome's sandbox after a user visits attacker-controlled content. The affected line is Chrome before 149.0.7827.53; Google's June 2, 2026 stable rollout shipped 149.0.7827.53 for Linux and 149.0.7827.53/54 for Windows and macOS, with Android receiving corresponding fixes in 149.0.7827.59.

Google's HIGH 8.8 score is defensible as a pure technical memory-corruption rating, but it overstates fleet urgency for enterprise patch triage. The decisive downgrade factors are user interaction is required, exploitation appears to stop inside the sandbox, there is no KEV listing, and the supplied EPSS of 0.00071 is extremely low. This is still worth fixing because Chrome is everywhere, but it is not a drop-everything browser zero-day based on the evidence available.

"This is a real renderer bug, but it still needs a user click and lands inside Chrome's sandbox."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Land the victim on attacker content

The attacker needs the user to open a malicious page or ad frame that can exercise WebRTC code paths. The weaponized artifact here is a custom HTML/JavaScript WebRTC harness delivered over the web; Google describes the bug as reachable by a remote attacker via crafted content in Chrome's WebRTC component.

Conditions required:

Victim is running Chrome below 149.0.7827.53
Victim browses to attacker-controlled content or malvertising
WebRTC code path is reachable in the session

Where this breaks in practice:

This is UI:R; the attacker does not get drive-by server-side reachability
Enterprise browsing isolation, DNS filtering, SWG policy, or ad-blocking reduce the reachable population
Many managed fleets auto-update Chrome quickly, shrinking the vulnerable window

Detection/coverage: Network and web gateway telemetry may show delivery, but most scanners cannot directly prove exploitability from the outside because Chrome is a client application.

STEP 02

Trigger the WebRTC use-after-free

Once the page is loaded, the exploit must manipulate WebRTC object lifetime to dereference freed memory. The practical tool is a bespoke WebRTC memory-corruption exploit; I found no public PoC repo for CVE-2026-10948 in the sources reviewed, which raises attacker cost compared with one-click copy-paste weaponization.

Conditions required:

Exact vulnerable code path is still present in the installed build
Exploit primitive is reliable enough for the victim's platform and version

Where this breaks in practice:

Chrome memory-corruption exploitation is sensitive to build, platform, and mitigations
Lack of public PoC reduces mass opportunistic exploitation
Browser crash telemetry often exposes failed exploit attempts quickly

Detection/coverage: EDR and browser crash reporting can catch repeated renderer crashes or suspicious child-process behavior, but signature-level coverage for a fresh UAF is usually weak.

STEP 03

Gain code execution in the renderer sandbox

Successful exploitation yields code execution inside Chrome's sandbox, not full host compromise by itself. The exploit payload is effectively a sandboxed renderer implant with the same guardrails Chrome imposes on compromised renderer processes.

Conditions required:

The UAF is exploited successfully
Chrome sandbox remains the immediate execution boundary

Where this breaks in practice:

The sandbox materially reduces blast radius and blocks direct host takeover
Access to local files, credentials, and privileged OS resources is constrained compared with native RCE
A second bug is usually needed for reliable escape or privilege escalation

Detection/coverage: Behavioral EDR may see anomalous browser child-process activity, but many exploit chains at this stage look like browser instability rather than clean malware execution.

STEP 04

Chain with post-exploit objectives

To turn this into high-consequence compromise, the attacker normally needs a sandbox escape, token theft path, or user-session abuse chain. Without that second stage, the impact stays closer to per-tab or per-user browser compromise than broad enterprise breach.

Conditions required:

Attacker has follow-on exploit or abuse path after renderer code execution
Target environment lacks isolation controls around browser activity

Where this breaks in practice:

No public evidence in the reviewed sources shows CVE-2026-10948 being used in a broader in-the-wild chain
Modern EDR, browser hardening, and OS sandboxing increase chaining difficulty
Blast radius is usually one browsing session unless another control fails

Detection/coverage: This is where defenders have the best chance: EDR, credential guardrails, and identity telemetry are more likely to catch the follow-on than the initial renderer memory bug.

03 · Intelligence Metadata

The supporting signals.

In-the-wild status	No confirmed active exploitation found in the reviewed sources, and not KEV-listed at time of assessment.
Proof-of-concept availability	No public PoC identified for CVE-2026-10948 in the reviewed sources. That does not make it safe, but it does reduce commodity attacker uptake.
EPSS	User-supplied EPSS is 0.00071, which is extremely low and consistent with low short-term exploitation probability relative to the broader CVE corpus.
KEV status	Not listed in CISA KEV. I found no KEV entry or due date, which removes the strongest real-world urgency amplifier.
CVSS and what it really means	Vendor vector is `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H` with HIGH 8.8. The key practical brake is `UI:R` plus sandboxed impact; this is not unauthenticated server-side RCE.
Affected versions	Chrome before 149.0.7827.53 is affected. Official release notes show the fix in 149.0.7827.53 (Linux) and 149.0.7827.53/54 (Windows/macOS), with Android inheriting corresponding desktop security fixes in 149.0.7827.59.
Fixed versions	Desktop stable: Linux `149.0.7827.53`; Windows/macOS `149.0.7827.53/54`. Android: `149.0.7827.59`. There is also an Extended Stable desktop line at `148.0.7778.254` for Windows/macOS, but Google did not map this CVE explicitly to that branch in the source text reviewed.
Disclosure timeline	There is a date nuance here: Google shipped an early stable build to a small percentage of users on 2026-05-29, then promoted Chrome 149 to full desktop stable on 2026-06-02. The user-provided disclosure date of 2026-06-04 does not match the primary release-advisory dates I found.
Researcher / reporter	Google's stable release notes list CVE-2026-10948 as reported by Google on 2026-04-20.
Exposure / scanning reality	Browser client exposure is not a Shodan/Censys problem. Chrome is usually not internet-enumerable, so external scanners will undercount real population badly. Treat exposure as a fleet inventory and version-compliance problem, not an internet-facing asset problem.

04 · The Call

noisgate verdict.

Final Verdict

↓ DOWNGRADED to MEDIUM (6.4/10)

The single biggest severity brake is that exploitation still requires user interaction and only yields code execution inside Chrome's sandbox. That turns this from a headline-grabbing browser memory bug into a narrower, per-user compromise path unless the attacker also has a second-stage escape or post-exploit chain.

HIGH Version and release-date mapping from Google's release notes

MEDIUM Real-world exploitability assessment without public technical bug details or a public PoC

Why this verdict

Down from vendor 8.8: UI:R means the attacker needs the victim to browse attacker-controlled content; this is not server-side reachability.
Down again for sandboxed impact: the bug description stops at code execution inside the sandbox, which materially narrows blast radius versus full endpoint RCE.
Down again for weak threat intel: no KEV entry, no exploitation evidence found, and the supplied EPSS 0.00071 is low.
Not lower because ubiquity matters: Chrome is one of the widest deployment surfaces in the enterprise, so even a sandboxed renderer bug can matter at scale if patch lag is bad.

Why not higher?

There is no evidence in the reviewed sources of active exploitation, no KEV listing, and no indication that the bug by itself crosses Chrome's sandbox boundary. In a 10,000-host environment, the practical risk is constrained by user interaction, browser hardening, and the need for a second-stage chain to turn this into broader host compromise.

Why not lower?

This is still a real memory-corruption flaw in a massively deployed client application reachable by web content. If you let browser versions drift, the exposure population can become very large very quickly, and successful renderer compromise is still an attacker foothold against a user session.

05 · Compensating Control

What to do — in priority order.

Force Chrome auto-update compliance — Treat this as version hygiene first. Push managed update policy and version-enforcement checks so endpoints move to the fixed branch before the 365-day remediation window closes; for a browser, you should not need anywhere near that long even though this verdict has no mitigation SLA.
Constrain risky browsing paths — Route unmanaged web destinations through SWG, DNS filtering, or remote browser isolation where available. This reduces the chance of reaching the malicious page needed to trigger the bug; because this is MEDIUM, there is no mitigation SLA — go straight to the remediation window, but this control is valuable where patch lag persists.
Watch for browser crash clusters — Use EDR and crash telemetry to spot unusual Chrome renderer crash bursts, especially after exposure to suspicious domains or ads. UAF exploitation attempts often leave a trail of instability before a reliable chain exists.
Segment privileged browsing — Keep admin workflows and high-value identities off general-purpose browsing endpoints or browsers. Even sandboxed renderer execution is more dangerous when the user session also holds privileged tokens or access paths.

What doesn't work

MFA does not stop initial exploitation of a malicious page; it only helps if the attacker later tries to abuse harvested credentials or session flows.
Perimeter vulnerability scans do not meaningfully measure this risk because Chrome is a client application and usually not externally enumerable.
A generic network firewall rule does not fix a browser memory bug; the attacker can deliver the trigger over ordinary web traffic the business already allows.

06 · Verification

Crowdsourced verification payload.

Run this on the target endpoint or through your software-distribution/EDR script runner. Invoke it as python3 check_chrome_cve_2026_10948.py; it needs no admin rights and checks common desktop Chrome install paths and version sources, then prints VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.py

PYTHONREAD-ONLYSAFE

#!/usr/bin/env python3\n# check_chrome_cve_2026_10948.py\n# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN\n\nimport os\nimport platform\nimport re\nimport shutil\nimport subprocess\nimport sys\n\nFIXED = (149, 0, 7827, 53)\n\ndef parse_version(text):\n    if not text:\n        return None\n    m = re.search(r'(\\d+)\\.(\\d+)\\.(\\d+)\\.(\\d+)', text)\n    if not m:\n        return None\n    return tuple(int(x) for x in m.groups())\n\ndef version_lt(a, b):\n    return a < b\n\ndef run_cmd(cmd):\n    try:\n        out = subprocess.check_output(cmd, stderr=subprocess.STDOUT, text=True).strip()\n        return out\n    except Exception:\n        return None\n\ndef detect_windows():\n    try:\n        import winreg\n    except Exception:\n        return None\n\n    reg_paths = [\n        r'SOFTWARE\\Google\\Chrome\\BLBeacon',\n        r'SOFTWARE\\WOW6432Node\\Google\\Chrome\\BLBeacon'\n    ]\n    for hive in (winreg.HKEY_CURRENT_USER, winreg.HKEY_LOCAL_MACHINE):\n        for path in reg_paths:\n            try:\n                with winreg.OpenKey(hive, path) as key:\n                    value, _ = winreg.QueryValueEx(key, 'version')\n                    v = parse_version(str(value))\n                    if v:\n                        return ('Google Chrome', v)\n            except Exception:\n                pass\n    return None\n\ndef detect_macos():\n    app = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'\n    if os.path.exists(app):\n        out = run_cmd([app, '--version'])\n        v = parse_version(out)\n        if v:\n            return ('Google Chrome', v)\n    plistbuddy = '/usr/libexec/PlistBuddy'\n    plist = '/Applications/Google Chrome.app/Contents/Info.plist'\n    if os.path.exists(plistbuddy) and os.path.exists(plist):\n        out = run_cmd([plistbuddy, '-c', 'Print :CFBundleShortVersionString', plist])\n        v = parse_version(out)\n        if v:\n            return ('Google Chrome', v)\n    return None\n\ndef detect_linux():\n    for binary in ['google-chrome', 'google-chrome-stable', 'chrome', 'chromium', 'chromium-browser']:\n        path = shutil.which(binary)\n        if path:\n            out = run_cmd([path, '--version'])\n            v = parse_version(out)\n            if v:\n                name = 'Google Chrome' if 'chrome' in binary else binary\n                return (name, v)\n    return None\n\ndef main():\n    system = platform.system().lower()\n    result = None\n\n    if system == 'windows':\n        result = detect_windows()\n    elif system == 'darwin':\n        result = detect_macos()\n    elif system == 'linux':\n        result = detect_linux()\n\n    if not result:\n        print('UNKNOWN: Chrome version not found on this host')\n        sys.exit(2)\n\n    product, version = result\n    version_str = '.'.join(str(x) for x in version)\n\n    # This script assesses desktop Chrome against CVE-2026-10948.\n    # Android is out of scope for local desktop execution.\n    if version_lt(version, FIXED):\n        print(f'VULNERABLE: {product} {version_str} is below fixed version 149.0.7827.53')\n        sys.exit(1)\n    else:\n        print(f'PATCHED: {product} {version_str} is at or above fixed version 149.0.7827.53')\n        sys.exit(0)\n\nif __name__ == '__main__':\n    main()\n

07 · Bottom Line

If you remember one thing.

TL;DR

Monday morning, treat this as routine-but-real browser patch hygiene, not an emergency war room. There is no noisgate mitigation SLA — go straight to the 365-day remediation window for this MEDIUM verdict, but because this is Chrome you should still use fleet policy to collapse version drift quickly and verify every desktop browser reaches the fixed branch well before the noisgate remediation SLA of ≤ 365 days; focus first on unmanaged endpoints, exception groups, and users with broad internet access.

Sources

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.