Steam BrokenPipe: Local Privilege Escalation on Windows

A local escalation that skips the UAC promptA proof of concept circulating as BrokenPipe has drawn attention to a component that sits quietly on a gre...

A local escalation that skips the UAC prompt

A proof of concept circulating as BrokenPipe has drawn attention to a component that sits quietly on a great many Windows machines: the auxiliary service Steam installs to carry out tasks that need elevated rights. According to the demonstration, an account without administrator permissions can end up running code as NT AUTHORITY\SYSTEM, with no password request and no UAC dialogue appearing on screen. The behaviour was reproduced on Windows 10 and Windows 11 with Steam 10.96.30.42.

It is worth being precise about the scope. This is a local privilege escalation, not a remote one. The attacker first needs a foothold: the ability to run code on the machine with an ordinary account. That is not exotic. It is the normal situation on shared workstations, corporate laptops used by several people, and any environment where day-to-day users are deliberately kept away from administrative rights.

Why a helper service becomes an attack surface

The component under scrutiny is steamservice.exe, the executable behind Steam Client Service. It runs as a Windows service with maximum privileges and exposes an interface so the client can perform maintenance and deployment operations. That pattern is common in software that has to update itself or install dependencies, and it is not inherently wrong. The trouble starts when the validation logic does not close every door.

The technical explanation points to insufficient signature validation in VDF installation scripts. The weakness is not simply whether the content is signed, but how the path the service accepts and executes is assembled. Part of that path would fall outside the coverage of the signature, which allows an attacker to influence where the script is looked up. From there, the interface can be used to add a malicious script to an allow list and force its execution, so the payload runs with SYSTEM privileges.

What we know, and what we do not

At the time of writing there is no public CVE associated with this case, nor confirmation of active exploitation in real campaigns. Valve was reportedly notified months before the public disclosure, with March mentioned as the notification date. That leaves administrators in a familiar position: act on exposure and compensating controls while waiting for an official statement on affected versions and a specific fix.

For companies in Barcelona, Lleida, Tarragona or Girona running mixed fleets, the practical question is not whether Steam is a security product, but whether an unnecessary privileged service is present on machines that hold business data.

A practical checklist for administrators

Inventory first. Find out which Windows endpoints actually have Steam installed. In many organisations the answer is more surprising than expected, especially on developer and design workstations.
Question the need. Decide whether Steam Client Service is required on sensitive or shared equipment. On a kiosk, a reception desk or a warehouse terminal, the answer is usually no.
Prioritise the known build. If Steam 10.96.30.42 is detected on Windows 10 or Windows 11, treat the review as urgent.
Reduce execution of untrusted code. Application allow lists, script control and execution policies make it much harder for a standard account to launch the payload in the first place.
Watch the telemetry. Process creation in a SYSTEM context linked to steamservice.exe, cmd.exe or other launchers appearing from paths associated with Steam, and any anomalous execution pattern around the service deserve investigation.
Apply attack surface reduction. Removing non-essential software from critical endpoints remains one of the cheapest and most effective hygiene measures available.

Keeping Steam updated still matters, but in this case it is not enough on its own. Follow the vendor's official communications and its security programme to know whether a specific patch for BrokenPipe exists and which versions it covers.

Where centralised protection pays off

Cases like this one illustrate a broader truth: the risk rarely comes from the obvious server in the rack. It comes from auxiliary services, third-party agents and helper processes that were installed for convenience and then forgotten. On a single machine, that is an annoyance. Across twenty or two hundred servers, it is a management problem.

This is the ground where Abuse Shield operates. Instead of configuring protection machine by machine, it centralises it: automatic blocking of malicious IP addresses, managed fail2ban across multiple machines, and a reputation feed shared between all your servers. When one node observes abusive behaviour, the others learn about it, so the same attacker does not get a fresh attempt on every host. For hosting companies and SMEs running their own infrastructure, that shared intelligence is what turns isolated hardening into a coherent defensive posture.

BrokenPipe is a reminder that privilege escalation usually starts small. The response should be equally systematic: know what runs on your systems, remove what does not need to be there, and make sure the protection you do deploy is consistent, centralised and informed by what the rest of your fleet is seeing.

Put these ideas into practice

Talk to ALMC about a solution for your business. Explore your options or contact our team.

Results without leaving the page.