The Steam BrokenPipe vulnerability can reportedly allow a standard Windows user to escalate privileges to NT AUTHORITY\SYSTEM through the privileged Steam Client Service without administrator credentials or a User Account Control prompt.
The proof of concept, called BrokenPipe, was published by security researcher KillaBoi and targets steamservice.exe, the privileged Windows service installed with Steam.
The issue is important because it does not require remote exploitation by itself. An attacker must already be able to run code as a normal local user. However, if that initial foothold exists, BrokenPipe could provide a path from limited user privileges to SYSTEM-level execution.
At the time of writing, no public CVE assignment or Valve security advisory specifically addressing BrokenPipe has been identified. The researcher describes the issue as known to Valve before public disclosure, but that claim has not been independently confirmed by a public vendor statement.
How the Steam BrokenPipe Vulnerability Works
According to the researcher’s technical description, BrokenPipe abuses the Steam Client Service installation workflow rather than a memory-corruption bug.
The service accepts a genuine Valve-signed install-script VDF together with an installation root that can be influenced by the caller.
The key weakness, according to the researcher, is that the caller-controlled installation path is not covered by the signature protecting the signed VDF.
That creates a signature-coverage gap: the signed script remains genuine, but the privileged service can be directed toward a relocated executable controlled by the attacker.
BrokenPipe therefore does not need to forge or modify Valve’s signature. Instead, it abuses what the signature does not protect.
Administrators tracking similar enterprise security flaws can also follow our Critical CVE Vulnerabilities 2026 Enterprise Security Hub for related vulnerability and patch updates.
Steam Client Service Can Launch the Relocated Executable as SYSTEM
The BrokenPipe proof of concept communicates with the Steam Client Service through its inter-process communication interface.
The researcher describes a flow involving Steam’s IClientInstallUtils interface. A signed install-script is first added to the service’s trusted workflow while using an attacker-selected installation location.
The service can then process that trusted installation script and launch the selected executable using the Steam Client Service’s privileges.
Because steamservice.exe operates with SYSTEM-level privileges, the resulting child process can also execute as NT AUTHORITY\SYSTEM.
In the researcher’s demonstration, the resulting command shell reports NT AUTHORITY\SYSTEM, while the Windows security identifier is shown as S-1-5-18.
Microsoft documents S-1-5-18 as the well-known SID for the Windows LocalSystem account.
No Steam Login or Game Launch Is Required
One unusual aspect of the demonstration is that the user does not need to be authenticated to a Steam account.
According to the BrokenPipe project, Steam can remain at its unauthenticated login screen while the local privilege-escalation path is triggered.
The researcher also states that no game needs to be launched.
The important prerequisites are instead:
- Steam must already be installed on the Windows machine.
- The Steam Client Service must be available.
- The attacker must already have the ability to execute code as a standard local user.
That last requirement matters because BrokenPipe is not a standalone remote-code-execution vulnerability.
Why Local Privilege Escalation Still Matters
A local privilege-escalation flaw becomes most useful after an attacker has already gained an initial foothold.
For example, malware, phishing, a malicious download or another vulnerability may initially provide code execution only under a restricted user account.
That user context can limit access to protected files, services, credentials and system configuration.
If the attacker can then escalate to SYSTEM, the security impact can increase significantly.
SYSTEM-level execution can potentially give malicious code broad local access and make it much easier to disable defenses, access protected resources or establish deeper persistence.
This is why local privilege-escalation vulnerabilities are frequently valuable as second-stage components in multi-step attacks.
BrokenPipe Was Tested on Steam 10.96.30.42
The researcher states that BrokenPipe was validated against Steam version 10.96.30.42 on recent 64-bit Windows 10 and Windows 11 installations.
That does not automatically prove that every older or newer Steam build is affected.
Until Valve publishes an official advisory, administrators should avoid assuming an exact affected-version range beyond what has been demonstrated publicly.
Similarly, users should not assume that simply running the latest Steam build fixes BrokenPipe unless Valve explicitly confirms that the underlying issue has been remediated.
No Public CVE or Confirmed Valve Patch Yet
At publication time, the public BrokenPipe disclosure does not provide a CVE identifier.
We also did not identify a public Valve security advisory specifically confirming a fix for the issue.
The researcher says Valve has been aware of the underlying problem since March 2026. That statement comes from the researcher’s disclosure and should not be treated as an independently confirmed Valve timeline unless the company publishes its own response.
For the same reason, calling the issue a confirmed vendor-recognized zero-day would currently overstate the available evidence.
The more defensible description is a publicly disclosed Steam local privilege-escalation vulnerability with public proof-of-concept code and no publicly confirmed vendor fix identified at publication time.
What Administrators Should Do Now
Organizations that allow Steam on business-managed Windows systems should first determine where the software is installed.
- Inventory Steam installations: Identify corporate, lab, shared and kiosk systems where the Steam client is present.
- Remove unnecessary installations: Systems that do not need Steam should not carry the additional privileged service.
- Monitor
steamservice.exe: Investigate unusual child processes launched by the Steam Client Service. - Watch user-writable locations: SYSTEM-level processes originating from writable user directories deserve investigation.
- Keep Steam updated: Continue applying Steam client updates while monitoring for explicit remediation guidance from Valve.
- Restrict local code execution: Application control and endpoint security can reduce opportunities for untrusted local binaries to run.
Organizations should also monitor vulnerability disclosures affecting Windows privilege boundaries. CyberUpdates365 previously covered the LegacyHive Windows privilege-escalation issue, which affects a different Windows component but demonstrates why local privilege boundaries remain important defensive controls.
Detection Ideas for Security Teams
Security teams should focus less on the BrokenPipe name and more on the behavior produced by exploitation.
Potentially suspicious patterns include:
- Unexpected child processes created by
steamservice.exe. - Command shells or scripting engines running as SYSTEM shortly after Steam service activity.
- SYSTEM-level executables launched from user-writable directories.
- Unusual Steam Client Service activity on managed endpoints where users are not expected to administer games or Steam installations.
- Privilege changes occurring immediately after execution by a standard local user.
None of these signals alone proves BrokenPipe exploitation. They should be correlated with endpoint telemetry, process ancestry, file origin and user activity.
BrokenPipe Is Not a Remote Steam Account Hack
The flaw should not be confused with a vulnerability that remotely compromises arbitrary Steam accounts or Windows PCs over the internet.
The attacker must already have code execution on the target Windows system as a local user.
BrokenPipe then provides the privilege-escalation step.
This distinction is important for users evaluating their immediate risk. Simply having Steam installed does not mean a remote attacker can automatically obtain SYSTEM privileges.
The concern becomes greater when a Windows machine is already compromised by malware or another exploit.
CyberUpdates365 Analysis
The most significant part of BrokenPipe is the trust-boundary failure between a privileged Windows service and caller-controlled installation paths.
The Steam Client Service needs elevated privileges to perform legitimate installation and maintenance operations. That makes validation around signed installation content and file locations especially important.
According to the researcher’s analysis, Steam correctly validates the signed VDF but does not sufficiently bind that trust decision to the location from which the associated executable is loaded.
That type of design weakness can be more subtle than a classic unsigned-code execution bug because the trusted artifact itself remains valid.
For enterprises, the practical question is straightforward: if Steam has no business requirement on a managed endpoint, removing it also removes this privileged service from the attack surface.
For home users, there is currently no evidence that BrokenPipe alone allows remote compromise. The primary concern is its potential use after malware or another attacker-controlled process has already obtained local execution.
What We Are Monitoring
CyberUpdates365 will monitor for:
- a Valve security advisory or acknowledgement;
- a confirmed patched Steam client version;
- a CVE assignment;
- changes to the affected-version range;
- reports of real-world exploitation.
Until those details are available, claims about confirmed active exploitation, a complete affected-version range or a specific patched build should be treated as unverified.
