Steam Zero-Click RCE: 6 Flaws Let Attackers Hijack PCs

A second computer logged into your Steam account is all an attacker needs to run code on your PC, with no clicks and no prompts, according to research Atredis Partners published on October 28.

Atredis researcher Bryan Alexander found six vulnerabilities across Steam’s Windows client and its privileged background service: two remote code execution bugs that fire between PCs signed into the same account, and four local privilege escalation flaws that hand an attacker SYSTEM. The firm released working proof-of-concept exploits for all of them and says every bug is either patched or has passed its disclosure deadline.

The headline finding is a zero-click chain. An attacker who controls any one client authenticated to the victim’s Steam account can send a malformed synchronization message and take over the victim’s machine without the victim touching anything. Steam runs on roughly 75% of the PC gaming market and regularly sees 35 to 40 million daily active users, so the exposed surface is enormous.

Alexander presented part of the work at BSides PDX 2026 before the full write-up went live. Atredis reported everything through Valve’s HackerOne program. No CVE identifiers have been assigned to the set, and Valve has not published a statement on the research.

How the Zero-Click Attack Works

One Steam account can stay logged in on several machines at once, and those machines keep each other in sync, download schedules, install progress, and similar status, over Valve’s Connection Manager infrastructure. Each authenticated instance opens a direct connection to every other instance and exchanges encrypted SteamToSteam packets. Crucially, this happens automatically after login, with no Remote Play pairing and no extra permission granted.

That channel is where the two overflows live. The first is in the handler for download-schedule changes, an internal message Steam sends when a host’s download queue is updated.

The receiving client copies an attacker-supplied list of application IDs into a fixed-size buffer on the stack without checking how many entries arrived. Pack more than about 200 entries into the message, and the write runs off the end of the buffer and over the function’s return address, handing the attacker control of execution flow.

The second overflow is in the app-status handler, which reports per-application install and update progress to peers. Steam copies each update’s progress records into a stack array with room for just seven entries. A message carrying more than seven records spills into adjacent stack memory, and because the written values come straight from the attacker’s message, they get precise control over what lands there, including the instruction pointer.

A memory overwrite alone is not enough on a modern Windows build, where address space layout randomization scrambles where code sits in memory. Alexander cleared that hurdle with a third bug, an information leak in the outbound download-schedule message.

When Steam builds that message, it always copies a fixed 32 four-byte values out of a stack buffer regardless of how many schedule entries actually exist, and the buffer is never zeroed first. The leftover stack contents, including live pointers into Steam’s steamclient64 library, get broadcast to every connected client.

An attacker can simply wait for a client to connect and leak its memory layout, or prod an already-connected client into sending one by transmitting a schedule message of their own. With a leaked pointer, the attacker computes the base address of steamclient64, builds a return-oriented programming chain around the overflow, and finishes with a clean CreateProcessA call. Atredis demonstrated the full chain with a Windows 10 virtual machine in the attacker position and a fully updated Windows 11 system as the target.

Four Ways to Reach SYSTEM Locally

The local flaws all abuse steamservice.exe, the privileged component that runs as SYSTEM to install game dependencies, drivers, and other system-level tasks. Any process on the machine, at any integrity level, can connect to the service and issue requests, which is what makes these bugs reachable for an unprivileged attacker.

The first route abuses Valve Data Files, the install scripts bundled with most games. Steam signs and allowlists the binaries a script is permitted to run, but the allowlist records fully resolved paths that sit inside user-writable directories, and it does no further check before execution.

By allowlisting a legitimate signed script pointed at a folder they control, then dropping a renamed copy of cmd.exe at the expected path and submitting a second, unsigned script, an attacker coerces the SYSTEM service into running arbitrary commands.

The second route targets a legacy module-loading interface. The service can be told to load a DLL and then execute it either in-process, where a Valve signature is verified, or by spawning a child process, where it is not. A single flag in the request chooses between the two paths, and that flag is exposed directly over the IPC interface. An attacker drops their own executable named steamservice.exe into a user-writable Steam folder, loads a module, and sets the flag to run it as SYSTEM with no signature validation.

The third is the most visual. Steam’s secure desktop capture feature, built for Remote Play so remote users can answer elevation prompts on the host, sets up a shared input buffer that forwards keyboard and mouse events into Windows’ secure desktop. The buffer’s permissions let any desktop user write to it, and its optional encryption is entirely client-controlled and can be switched off per event.

Once the feature is authorized, a local attacker can spawn a program that asks for administrator rights and then spam the “Y” key into the secure desktop to approve its own UAC prompt. In testing, this produced no visible notification and happened instantly.

The fourth is a bring-your-own-vulnerable-driver opening in the function that installs the Steam Frame wireless dongle driver. The routine verifies a driver catalog’s Authenticode signature but never confirms the setup file actually matches the expected driver, and the check happens before the install, leaving a time-of-check-to-time-of-use window. An attacker can swap the file between validation and the pnputil install step to load an unrelated signed, vulnerable driver as SYSTEM.

Is Steam Being Exploited?

There is no evidence of exploitation in the wild. Atredis found the bugs through its own research, reported them, and published after they were resolved or ran past the firm’s standard 90-day disclosure deadline. What raises the stakes is that full proof-of-concept code and the BSides PDX slides are now public on Atredis’s GitHub, which lowers the bar for anyone trying to reproduce the work.

The one caveat worth stating plainly: Atredis says the issues are patched or past deadline but does not itemize the fix status of each individual bug or list the exact Steam client builds that close them, and Valve has not responded publicly. The remote chain is the priority for users, since it is the one that needs no local access and no interaction.

What Steam Users Should Do

Make sure the Steam client is current. Steam updates itself automatically on launch, but you can force a check through the Steam menu by selecting “Check for Steam Client Updates,” then restart the client so any pending update applies.

Because the remote attack depends on a hostile client being logged into your account, review your authorized devices and sign out anything you do not recognize. In the Steam client, that lives under Steam, Settings, Security, and on the web under Account details, with options to deauthorize unfamiliar sessions and to force a sign-out everywhere.

Keeping Steam Guard two-factor authentication enabled remains the most effective barrier against an attacker getting a second session onto your account in the first place.