The Steam BrokenPipe privilege escalation is a local Windows security issue in which public research demonstrates a standard user reaching NT AUTHORITYSYSTEM through Steam Client Service without administrator credentials or a UAC prompt. The most important boundary is that BrokenPipe is not a remote entry point: an attacker or malicious process already needs local code execution as a normal Windows user before attempting the privilege escalation.
Current answer: the published proof of concept was tested against Steam version 10.96.30.42 on recent Windows 10 and Windows 11 x64 systems. TPS found no public Valve advisory or confirmed BrokenPipe-specific remediation in the reviewed current sources. That does not prove every newer Steam build remains vulnerable, so administrators should treat later-version status as unresolved until Valve or independent retesting provides stronger evidence.
What BrokenPipe changes on a Windows endpoint
A standard Windows account is normally separated from services running with SYSTEM privileges. BrokenPipe matters because the researcher demonstrated a path from that lower-privilege local context into code execution under NT AUTHORITYSYSTEM, one of the most powerful local security contexts on Windows.
That can materially increase the impact of an existing compromise. Malware or another untrusted process that initially runs only with ordinary user privileges may face restrictions that SYSTEM-level execution can bypass. BrokenPipe therefore belongs to the post-compromise privilege-escalation stage, not the initial remote-access stage.

Is BrokenPipe a remote Steam exploit?
No. The reviewed evidence describes a local privilege escalation. The attacker must already be able to execute code under a standard Windows user account on a system where Steam Client Service is installed and accessible.
This distinction prevents two opposite mistakes. Calling BrokenPipe a remote Steam compromise would overstate the evidence. Treating it as unimportant because local code execution is already required would understate the additional security boundary that SYSTEM access removes.
Does the attacker need administrator credentials or a UAC approval?
The published research says the demonstrated path does not require the standard user to supply administrator credentials or approve a UAC elevation prompt. The escalation instead abuses privileged behavior exposed through Steam Client Service.
That is the core reason defenders should treat the issue seriously on machines where untrusted code may run under ordinary accounts, including shared systems, developer machines, gaming environments and managed endpoints where Steam is permitted.
Does the Windows user need to be logged into a Steam account?
The researcher reports that a Steam-account login is not required for the demonstrated technique. The relevant dependency is the Windows-side Steam Client Service and the local execution context, not possession of a Steam account password.
Which Steam version was actually tested?
The public BrokenPipe research identifies Steam version 10.96.30.42 as the tested build and reports testing on recent Windows 10 and Windows 11 x64 systems.
That evidence should not be stretched into a claim that every earlier or later Steam build is vulnerable. A later client or service update could change behavior without the original research proving either vulnerability or safety for that build. Administrators therefore need to separate the tested vulnerable state from the current unknown state when checking newer installations.
Has Valve confirmed or fixed BrokenPipe?
No public BrokenPipe-specific Valve advisory or confirmed remediation was identified in the sources reviewed for this article. The researcher says Valve was notified in March and that the issue remained unresolved at disclosure, but TPS did not find a public Valve statement independently confirming that disclosure timeline.
This means the strongest safe wording is not that Valve has definitively refused or failed to fix the issue. The current evidence supports saying that a public researcher disclosure and PoC exist while a public vendor-confirmed fix was not identified during the review.
Is there a CVE for BrokenPipe?
No public CVE was identified in the reviewed current evidence. CVE assignment can occur after disclosure, so that state should be treated as provisional rather than permanent.
Is BrokenPipe being exploited in the wild?
No confirmed in-the-wild exploitation was established in the reviewed sources. The existence of public proof-of-concept code raises defender attention, but public PoC availability is not the same as evidence of real-world exploitation.
How should administrators assess their current risk?
If not, the demonstrated Steam Client Service path is not relevant to that machine. If Steam is installed, continue with version and exposure checks.
On enterprise, privileged, development or shared systems, consider whether Steam is operationally necessary. Software that is not required creates additional attack surface even when no active exploitation is confirmed.
If yes, BrokenPipe can matter as an escalation path because the initial local foothold and SYSTEM compromise are different security states. Investigate the endpoint rather than treating the absence of administrator credentials as sufficient containment.
Do not assume either vulnerable or fixed solely from version age. Check current Valve guidance and credible retesting because the reviewed research directly establishes only its tested build and conditions.
Endpoint-security teams should investigate anomalous SYSTEM-level process activity associated with Steam Client Service and other signs of local compromise using their normal incident-response tooling and policies.
Should organizations remove Steam?
The available evidence does not support a universal instruction that every home user must immediately uninstall Steam. BrokenPipe requires prior local code execution, so risk depends heavily on endpoint role and threat model.
Organizations managing sensitive Windows systems can take a stricter approach: inventory Steam installations, determine where the software is actually required and remove unnecessary software according to existing endpoint-hardening policy. That is general attack-surface reduction rather than a vendor-approved BrokenPipe fix.
What should defenders avoid doing?
Do not treat an unverified registry, service-permission or file-system workaround as equivalent to an official remediation. Changes to privileged services can break software or create different security problems if applied without testing. Until Valve publishes controlling guidance, remediation claims should remain clearly separated from temporary risk-reduction measures.
Likewise, keeping Steam updated is sensible maintenance practice, but a generic client update should not automatically be described as a BrokenPipe fix unless Valve or credible independent testing confirms that the affected behavior has changed.
What remains unresolved
Several important facts remain open: whether Valve publicly acknowledges the issue, whether a later Steam build silently changes the affected behavior, whether a CVE will be assigned, whether exploitation has occurred in the wild, and which exact Steam builds beyond 10.96.30.42 are vulnerable or fixed.
Those are maintenance triggers for this same canonical article. A Valve advisory, confirmed patched version, CVE assignment, CISA KEV addition, credible exploitation evidence or reliable researcher retest should update this page rather than create another URL for the same reader job.
Verification note
TPS reviewed the original BrokenPipe research repository, current independent security coverage and current Steam update surfaces. The published research supports the standard-user-to-SYSTEM demonstration and local-execution prerequisite. The vendor notification timeline and current remediation state are not independently confirmed by a public Valve BrokenPipe advisory in the reviewed evidence.
Bottom line: BrokenPipe is best understood as a high-impact local privilege escalation, not a remote Steam compromise. A standard-user foothold can reportedly become SYSTEM under the demonstrated conditions, while current Valve fix status and the vulnerability state of later Steam builds remain unresolved.