Port 5357 – WSDAPI (Web Services on Devices)

Port 5357 is opened on Windows (Vista, 7, 8, 10, and 11) by WSDAPI — the Web Services on Devices API, Microsoft’s implementation of WS-Discovery and the Devices Profile for Web Services (DPWS). It’s the HTTP endpoint Windows uses for network device discovery: finding and talking to WSD printers and scanners, and letting a PC advertise itself to other devices on the LAN. It’s the port people spot when they run netstat and ask “why is port 5357 listening on my Windows PC — is it a virus?” The short answer is that it’s a normal, built-in Windows networking component tied to Network Discovery, not a sign of compromise. It’s only meant to answer on the local subnet, so the realistic questions are the same ones that matter for CDPSvc on port 5040: is this genuinely the Windows service, and is it reachable further than it should be? — plus one historic WSDAPI remote-code-execution bug worth knowing about.

Why It’s Open

WSDAPI is the modern, zero-configuration way Windows discovers devices on a network. When Network Discovery is enabled — which is the default on a Private network profile — Windows publishes the machine and its resources over WSD and listens for other devices doing the same. That’s what puts a listener on TCP 5357. Two stock services drive it:

• Function Discovery Resource Publication (FDResPub) — publishes this computer and its resources (including WSD print/scan endpoints) so other hosts can find them.
• Function Discovery Provider Host (fdPHost) — hosts the discovery providers, including the WSD and SSDP providers.

The everyday features that ride on 5357 are WSD network printers and scanners — the “just plug it into the network and it appears” experience — and general device browsing under Network in File Explorer. Because WSDAPI registers its endpoint with the kernel HTTP stack (http.sys), the listener shows up as owned by the System process rather than a named svchost, and a scanner fingerprints it as Microsoft HTTPAPI httpd 2.0. Its companions are UDP 3702 (WS-Discovery multicast to 239.255.255.250) and TCP 5358 (WSD over TLS). It’s enabled out of the box on client Windows, so it turns up constantly — and where you find it you’ll usually find its device-discovery relatives too, like mDNS on port 5353 and the Microsoft RPC endpoint mapper on port 135.

Common Risks

For a port that’s benign in the common case, it’s worth being precise about where the real risk is:

• Malware masquerading on the port. The most useful check is confirming the listener really is the genuine Windows WSD stack (owned by System/http.sys, backed by FDResPub/fdPHost) — and not an unsigned binary parked on a “boring” Windows port to blend in. An open 5357 owned by something other than the WSD stack is the finding, not the port number itself.
• Unnecessary network exposure. WSD is meant to stay on the local subnet, and the Windows Firewall scopes inbound 5357 to the local network on a Private profile. If those rules are loosened, the profile is misconfigured, or 5357 is reachable across VLANs or from the internet, it becomes needless attack surface — it never has a reason to answer the wider network.
• Information disclosure / fingerprinting. WSD device metadata leaks hostnames, OS and device model, and the presence of WSD printers/scanners. An open 5357 is also a reliable “this is a Windows host with Network Discovery on” signal during recon — low severity on its own, but useful for profiling.
• A historic WSDAPI RCE. On Windows Vista and Server 2008, a crafted WSD packet could trigger remote code execution (MS09-063 / CVE-2009-2512, covered below). It’s patched and limited to the local subnet, but it’s the reason 5357 shouldn’t be treated as purely cosmetic.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

The goal isn’t to “exploit port 5357” — it’s to confirm the listener is the legitimate Windows WSD service, check that it isn’t reachable beyond the local subnet, and rule out something masquerading on the port.

Detect the service and grab the fingerprint

nmap -sV -p 5357 <target>

On a normal Windows host this reports Microsoft HTTPAPI httpd 2.0 (often with a Service Unavailable title) — the http.sys-fronted WSD endpoint.

Poke the HTTP endpoint

curl -i http://<target>:5357/

WSD answers on http.sys, so a bare request typically returns 404/503 rather than a browsable page — enough to confirm the HTTPAPI listener is live.

See what’s listening and on which address (Windows, elevated)

netstat -anob | findstr 5357

Note the local address: 0.0.0.0:5357 binds all interfaces (the default) and relies on the firewall to stay subnet-local. Because WSD rides http.sys, the owning line usually maps to the System process (PID 4), not a specific svchost.

Map the port to the WSD services (PowerShell)

Get-Process -Id (Get-NetTCPConnection -LocalPort 5357).OwningProcess
Get-Service FDResPub, fdPHost | Format-List Name, DisplayName, Status

On a healthy host the owner is System and the discovery is provided by Function Discovery Resource Publication (FDResPub) and Function Discovery Provider Host (fdPHost).

Check reachability from another host

nmap -sT -p 5357 <target>

From outside the local subnet, 5357 should show as filtered on a default-firewalled Windows machine. An open result from a different subnet or the internet means the inbound scoping isn’t in place.

Record anything you confirm — the owning process, the bind address, and whether it’s reachable off-subnet — in the pentest report rather than a scratch file, so the “5357 was exposed / was an impostor” finding is documented.

What to Look For

Known CVEs and Exploits

Modern Windows (7, 8, 10, 11) has no comparable public unauthenticated “port 5357 RCE” — on current builds this is a benign discovery endpoint. The one notable vulnerability is historic and firewall-scoped to the local subnet:

• CVE-2009-2512 (MS09-063) — The Web Services on Devices API Memory Corruption Vulnerability. WSDAPI does not correctly validate the headers of a received WSD message, so a specially crafted packet to TCP 5357/5358 could allow remote code execution with full control of the system. Affects Windows Vista (Gold/SP1/SP2) and Windows Server 2008 (Gold/SP2) only — Windows XP, Server 2003, Windows 7, and Server 2008 R2 are not affected. Rated Critical / RCE; CVSS 2.0 9.3, later scored 9.8 on CVSS 3.1 by NVD. Crucial scope: only attackers on the local subnet can exploit it — the Windows Firewall exposes WSD only to the local network, so this was never an internet-facing bug. Microsoft’s own workaround was to block inbound TCP 5357/5358 and outbound UDP 3702.

The previous version of this page listed CVE-2019-10149 and CVE-2022-30798 as WSD issues. Both were misattributions and have been removed: CVE-2019-10149 is the Exim mail-server “Return of the WIZard” RCE, and CVE-2022-30798 is a SQL injection in “Online Ordering System v1.0” — neither has anything to do with WSD, WSDAPI, or port 5357.

Mitigation

WSDAPI is a default Windows component, and on a machine that uses WSD network printers or device discovery the right call is to leave it and harden around it rather than rip it out:

• Keep Windows patched. MS09-063 is long fixed in the monthly updates — routine patching closes the one serious WSDAPI RCE. Retire any Vista/Server 2008 hosts that can’t be patched.
• Don’t expose it beyond the local subnet. Leave the host firewall on and keep inbound 5357/5358 scoped to the local network. Block 5357 (and 5358, plus outbound UDP 3702) at VLAN boundaries and the perimeter — WSD has no legitimate reason to cross a subnet or reach the internet.
• Confirm it’s the real service. Verify the listener is owned by System/http.sys and backed by FDResPub/fdPHost. If something else owns 5357, treat it as a compromise and investigate — don’t just “close the port.”
• Disable it only if you don’t use WSD. On a host that doesn’t need network device discovery, turn off Network Discovery or set the Function Discovery services to disabled:

Stop-Service FDResPub
Set-Service FDResPub -StartupType Disabled

Expect WSD printer/scanner discovery and Network browsing to stop working afterward. Prefer managing this via Group Policy/MDM across a fleet.

• Segment printers and IoT. Put WSD-chatty printers and devices on their own VLAN, isolated from user and server subnets, and prefer standard IPP printing where you want tighter control.

Real-World Example

The everyday “incident” on port 5357 is a false alarm: someone runs netstat -an, sees 0.0.0.0:5357 LISTENING, searches the number, and concludes the PC is infected — when it’s just WSDAPI doing network device discovery. That reflex isn’t wrong, though; it’s the right instinct pointed at the wrong port. The value of 5357 as a teaching case is that the correct response — fingerprint the service, confirm it’s the System/http.sys WSD listener backed by the Function Discovery services, and check whether it answers from outside the local subnet — is the same discipline that catches the genuine problems: a host still exposed to the MS09-063 WSDAPI RCE (Vista/Server 2008), or malware squatting on a mundane, trusted-looking Windows port. On a patched, properly firewalled machine the answer is almost always “benign WSD,” but the point is to verify it rather than assume it.

FAQ

Is port 5357 safe, or is it a virus?

On a normal Windows machine, port 5357 is safe — it’s WSDAPI (Web Services on Devices), the built-in service Windows uses for network device discovery like WSD printers and scanners. It’s not a virus. The only way it becomes a concern is if the process listening on 5357 turns out not to be the genuine Windows WSD stack (System/http.sys, backed by FDResPub/fdPHost) — that would suggest malware masquerading on the port, which is worth confirming with the checks above.

Why is port 5357 listening on my PC?

Because Network Discovery is enabled — the default on a Private network — and the Function Discovery Resource Publication (FDResPub) service publishes your PC and its resources over WSD, opening TCP 5357. It’s on out of the box on Windows Vista through 11, which is why the port appears even if you’ve never deliberately used WSD.

Is port 5357 a remote security risk?

Not in a default configuration on a supported, patched Windows version. The Windows Firewall scopes inbound 5357 to the local subnet, and current Windows has no public unauthenticated 5357 RCE. The one serious bug — MS09-063 / CVE-2009-2512 — affects only Vista and Server 2008 and is exploitable only from the local subnet. The realistic risks are needless exposure beyond the LAN and confirming the listener is genuine.

How do I close or disable port 5357?

If you don’t use WSD network printers or device discovery, turn off Network Discovery, or disable the service: Stop-Service FDResPub then Set-Service FDResPub -StartupType Disabled (elevated). That frees the port but also stops WSD printer/scanner discovery and Network browsing. If you just want it off the wider network, leave the service running and block 5357 (and 5358) inbound at the host/network firewall so it stays subnet-local.

Is port 5357 the same as SSDP/UPnP?

They’re related but distinct. WSD (5357) and SSDP/UPnP (port 1900, with http.sys also fronting 2869) are both Windows device-discovery mechanisms, and Function Discovery hosts providers for both — which is why they often appear together in a scan. WSD is the WS-Discovery/DPWS stack used for modern WSD printers and scanners; SSDP/UPnP is the older discovery protocol.

TL;DR

• Service: WSDAPI — the Windows Web Services on Devices API (WS-Discovery / DPWS), fronted by http.sys and driven by the Function Discovery services (FDResPub / fdPHost)
• Default port: 5357/TCP, opened by Network Discovery on Windows Vista–11 (companions: 5358/TCP WSD-TLS, 3702/UDP WS-Discovery)
• What it does: network device discovery — finding and using WSD printers, scanners, and other devices, and advertising the PC on the LAN
• Biggest risk: needless exposure beyond the local subnet + info disclosure; malware masquerading on the port; the historic MS09-063 WSDAPI RCE on Vista/Server 2008 — not a remote RCE on modern, patched Windows
• Mitigation: keep Windows patched, keep 5357 scoped to the local subnet (block it crossing VLANs/the internet), confirm it’s the genuine WSD service, and disable Network Discovery/FDResPub only if you don’t use WSD