The 16-Day Window: How Valve's CEF Debt Became My Problem
The forensic pass is complete. The answer was not on my machine.
That was the question the first article left open: how did the session token leave? After mounting the Windows partition read-only from Kali and walking through Event IDs, extension install timestamps, and Steam config modification times, the answer is documented and timestamped.
The breach point was not my practices. It was not my software choices. It was not anything I could have caught or patched myself. It was a 16-day window between when Google patched a critical zero-day and when Valve shipped the corresponding fix to the Chromium Embedded Framework binary sitting inside every Windows Steam client.
The file that proves it: Program Files (x86)\Steam\bin\cef\cef.win64\ — updated June 24th.
The attack happened June 17th.
The Evidence Chain
April 27, 2026 — CVE-2026-11645 reported to Google. A CVSS 8.8 out-of-bounds read and write vulnerability in V8, Chrome's JavaScript engine, exploitable via a crafted HTML page. Arbitrary code execution inside the browser sandbox. Actively exploited in the wild before the patch existed.
June 8, 2026 — Google patches Chrome. Fifth actively exploited zero-day of 2026. CISA adds it to the Known Exploited Vulnerabilities catalog and directs all Federal Civilian Executive Branch agencies to patch by June 23rd.
June 17, 2026, 3:27 AM — Major file activity on my machine, centered on Steam's embedded browser process. Steam was not running interactively. No keyboard or mouse attached. The activity was not me.
June 23–24, 2026 — Valve ships a Steam client update. CEF binaries in cef.win64 updated June 24th. The patch that closed the window arrives 16 days after it should have — one day after the federal deadline.
July 9, 2026, 5:55 AM — Harvested session token replayed from Madrid via a geographically matched SOCKS5 proxy. Automated fraud pipeline runs the full playbook in 18 minutes. I had the account back in 57.
The Mechanism
Steam's built-in browser, steamwebhelper, runs on a custom build of the Chromium Embedded Framework. Security researchers documented in 2024 that Steam's CEF version was built on Chromium 85.0.4183.121 — a build from September 2020 — and that nearly all vulnerabilities found since that version had not been patched by Valve.
When steamwebhelper loads Steam platform pages, it injects a privileged JavaScript object — SteamClient — directly into the renderer context. A V8 exploit gains code execution inside the renderer. The SteamClient object provides direct access to session tokens. No filesystem read required. No user interaction beyond Steam being installed and the browser process running in the background.
The exploit used CVE-2026-11645 or one of the four earlier 2026 Chrome zero-days — all of which were unpatched in Steam's CEF build at the time of the compromise. The stolen session token was exfiltrated encrypted, leaving no artifacts on the machine. Malwarebytes found nothing because there was nothing local to find. The first article said as much. Now I know why.
The Institutional Failure
This is not a novel problem. Valve's community has been raising the CEF version lag as a documented security risk for years. Forum threads, bug reports, and public security research all point to the same structural issue: Valve treats their CEF dependency as a product feature to be updated on their own schedule, not a security-critical component requiring rapid patch response.
CISA directed federal agencies to patch CVE-2026-11645 by June 23rd. Steam's CEF wasn't updated until June 24th — one day after the federal deadline. Every Steam user on Windows was running a vulnerable browser engine with privileged JavaScript access to their session tokens for 16 days after a known, actively exploited zero-day was patched upstream.
That's not a gap. That's a policy.
I had:
- 25 years of active cybersecurity experience
- A freshly built, hardened system
- Total account compartmentalization
- 2FA on every account
- No reused passwords
- An isolated recovery email on a separate device, never connected to the compromised machine
- A clean, audited software list with no third-party plugins or upstream package dependencies
None of it mattered at 3:27 AM on June 17th. The vulnerability was in software I couldn't patch, maintained by a company that didn't prioritize patching it.
The Stealer Pipeline
The token harvested on June 17th sat in a stealer log for 22 days before being actioned. This is consistent with how modern infostealer-as-a-service operations work. Storm, KuinaExtractor, and similar platforms sell or queue harvested credentials for use by separate operators on their own timeline. The 5:55 AM automated fraud run on July 9th — card addition, funds loaded, account drained through a gacha title — was a practiced pipeline that had run against hundreds of accounts before mine.
The 10:48 PM manual re-attempt documented in the first article was a human, frustrated that the automation had failed. Recovery was faster than anticipated. It happens.
What Actually Protected the Account
Two things. Neither of them Valve's.
The iCloud separation. Steam's recovery email lived on Apple, on a device that has never touched the compromised machine. The attackers could change the account language — they switched it to Traditional Chinese, a documented technique to route confirmation emails into a script the victim likely can't read fast enough to respond to. They could drain the balance. They could not change the recovery email. Full account takeover was architecturally impossible from the moment the attack started.
Speed. 57 minutes from waking up to account recovery. Multiple AI instances running in parallel — Claude for forensic reasoning and documentation, Gemini for real-time translation of the Traditional Chinese confirmation emails — and enough familiarity with the systems to not spend time on the wrong questions.
Valve's own infrastructure — Steam Guard, geographic anomaly detection, session validation — did not prevent the compromise, did not flag the Madrid login in time to stop the fraud, and made account recovery harder than it needed to be. Every block in the support process had to be navigated manually, under time pressure, while the balance was already gone.
The Pattern
This isn't unique to Valve. The pattern repeats across the industry:
A dependency with a known, documented security lag. A community raising it for years. A corporate timeline that treats security patches as a feature release concern rather than an emergency response obligation. A zero-day that exploits the gap. Users who did everything right, compromised anyway.
The difference here is that the forensic evidence is complete and timestamped. The CEF binary update date is on disk. The CVE patch date is public record. The attack date is in Steam's own logs on Valve's servers. The 16-day window is not speculation — it is documented fact.
Recommendations
If you run Steam on Windows:
Steam's recovery email should live on a separate device and account from anything connected to the machines you run Steam on. This is the single most important control, and the one that made full account takeover impossible in this case.
Session tokens in CEF-based applications are not protected by Chrome's App-Bound Encryption. Treat them as more exposed than standard Chrome session cookies.
A clean reinstall after a confirmed compromise window is correct hygiene regardless of what forensics shows. Absence of evidence is not evidence of absence when the stealer was designed to leave none.
For Valve:
CEF security patches are not feature updates. They require an emergency response cadence aligned with upstream Chromium security releases — not a product release schedule. The SteamClient privileged JavaScript injection into the renderer context of a CEF build with a documented multi-year security lag is an architectural risk that has now produced a confirmed, documented, timestamped exploitation. security@valvesoftware.com will receive this timeline.
For the industry:
Every Electron app, every CEF integration, every embedded Chromium runtime is a separate patch surface that does not automatically inherit Chrome's security updates. Treat them accordingly. "We use Chromium" is not a security posture. "We patch our Chromium build within 24 hours of a confirmed zero-day" is.
Closing
The first article asked how an attacker got through security that most CISOs only claim to have.
The answer turned out to be: they didn't. They went around it, through a door that a major corporation left open for 16 days after being told to close it.
The victim's vault held. Valve's did not.
Alexius McMullin has 25 years in cybersecurity. He is also, somehow, still annoyed that his DayZ bearskin hat is now in compromised account limbo pending reinstall. The fraudulent purchase remains Umamusume: Pretty Derby. Priorities.