A newly disclosed Windows vulnerability in Valve’s Steam client could give an attacker the highest local privileges on a computer without an administrator password or User Account Control prompt. The issue, demonstrated in a proof of concept called BrokenPipe, abuses a trust decision made by the Steam Client Service rather than relying on memory corruption or a forged digital signature.

The technique matters because Steam is common on personal machines and can also appear on shared workstations, development systems and corporate laptops. An attacker still needs the ability to run code as an ordinary user, so this is not a remote compromise on its own. In a multi-stage intrusion, however, a dependable route from a limited account to NT AUTHORITY\SYSTEM can turn a foothold into complete control.

How the Steam service is reportedly abused

Steam uses a privileged Windows service, steamservice.exe, for installation and maintenance jobs that require more rights than the desktop client normally has. According to the researcher’s technical description, the service validates a Valve-signed install-script VDF but also accepts a caller-selected installation root. The signature protects the manifest, yet it does not bind the trusted workflow to a safe location on disk.

BrokenPipe connects to the service through its inter-process communication mechanism. It supplies an authentic signed VDF together with an installation directory controlled by the unprivileged user. The service then treats a launcher found through that relocated path as trusted. A later call asks the service to run the install script, causing the attacker-selected launcher to execute under the service’s SYSTEM account.

The public demonstration reportedly copies the Windows command prompt to the expected launcher name. When invoked by Steam, that program inherits LocalSystem rights. This distinction is important: the attack does not alter Valve’s signature or defeat cryptography. It exploits incomplete signature coverage and unsafe handling of a path that remains under the caller’s influence.

Why local privilege escalation raises the stakes

A standard account normally limits what malware can change. SYSTEM access can allow an intruder to tamper with security tooling, read data belonging to other users, install persistent services and modify protected operating-system areas. It may also help attackers extract credentials and prepare lateral movement, depending on the computer’s role and available defenses.

The researcher reported successful testing against Steam version 10.96.30.42 on current 64-bit Windows 10 and Windows 11 systems. Steam must be installed and its service available. The disclosure says Valve had been aware of the issue since March 2026, but no public Valve advisory, CVE identifier or confirmed security update was identified when the report was published. That leaves defenders without a vendor-verified remediation status.

Practical steps while a fix is unclear

Organizations should first determine whether Steam is present on managed Windows endpoints. Removing it from systems where it has no business purpose reduces exposure immediately. Where the client is permitted, security teams should confirm that application-control policies prevent ordinary users from launching unapproved executables from writable folders.

• Monitor steamservice.exe for unusual child processes, especially shells and scripting engines.
• Alert when SYSTEM-level programs launch from user profiles, temporary folders or other writable locations.
• Review software inventory for Steam on privileged workstations, jump hosts and administrator devices.
• Keep the client updated, while waiting for explicit confirmation that a release addresses BrokenPipe.

Endpoint telemetry can also reveal the larger attack chain. A Steam service event preceded by a suspicious download, archive extraction, PowerShell execution or newly created launcher file deserves investigation. Teams should preserve process ancestry and file-creation evidence rather than looking only at the final privileged process.

A useful lesson beyond gaming software

The case illustrates a recurring design risk in privileged installers: validating one component is not enough if an attacker can redirect where other components are loaded from. Signed configuration data, helper executables and installation paths must be evaluated as a single trust boundary.

Until Valve publishes guidance, the safest posture is to treat the reported flaw as an escalation opportunity that can amplify another compromise. It does not make every Steam installation remotely exploitable, but it can remove a critical barrier once malicious code is already running under a normal Windows account.