Port 5040 – CDPSvc (Connected Devices Platform Service)

Port 5040 is opened on Windows 10 and 11 by CDPSvc, the Connected Devices Platform Service, running inside a shared svchost.exe process. It’s the port people notice when they run netstat on their own PC and ask “why is something listening on 5040?” — the short answer is that it’s a normal, signed Windows service, not a sign of compromise. CDPSvc coordinates Microsoft’s “Shared Experiences” features — Nearby Sharing, Phone Link, cross-device clipboard, and Timeline — and 5040 is the local endpoint it uses for that. The Windows Firewall blocks inbound 5040 by default, so on a stock machine it has essentially no remote attack surface. The realistic questions on this port are the opposite of the usual ones: is this actually the genuine service, or something masquerading on the port, and is it needlessly reachable from the network?

Note: this page was historically titled “Windows Diagnostics Hub Standard Collector.” That was a misidentification — the Diagnostics Hub Standard Collector (diagsvc / DiagnosticsHub.StandardCollector.Service) is a separate Visual Studio profiling service, and it does not own port 5040. On Windows 10/11 the process that binds TCP 5040 is CDPSvc.

Why It’s Open

CDPSvc is part of the Connected Devices Platform (CDP), Microsoft’s framework — originally “Project Rome” — for letting a Windows PC talk to other devices you own: phones, tablets, and other PCs signed into the same Microsoft account. It’s enabled by default on consumer and most business editions of Windows 10 and 11, which is why so many machines show 5040 listening even though the user never deliberately turned anything on.

The features that ride on top of it are the ones most people recognize:

• Nearby Sharing — sending files and links to nearby Windows devices over Bluetooth/Wi-Fi.
• Phone Link (Your Phone) — mirroring texts, photos, notifications, and calls from an Android phone.
• Cross-device clipboard and Timeline — “continue on PC,” clipboard sync, and shared activity history across your devices.

CDPSvc runs as NT AUTHORITY\LocalService and starts automatically. When it initializes it opens a TCP listener on 5040 as a local coordination/IPC endpoint for the platform. Because it’s a stock Windows service rather than something an admin installs, it turns up everywhere: laptops, desktops, and virtual machines alike. Where you find it you’ll often find its device-discovery relatives too, like WSDAPI on port 5357 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 actual risk is:

• Malware masquerading on the port. The single most useful check is confirming that the process on 5040 really is a signed svchost.exe hosting CDPSvc — and not an unsigned binary that has parked itself on a “boring” Windows port to blend in. An open 5040 owned by something other than CDPSvc is the finding, not the port number itself.
• Local privilege escalation. CDPSvc runs as a service and has had a steady run of local elevation-of-privilege bugs (use-after-free and heap-overflow issues) that let a low-privileged user already on the box escalate to SYSTEM. These need local access — they are not remote 5040 exploits — but on an unpatched host they’re a real post-compromise step.
• Unnecessary network exposure. CDPSvc binds the listener to 0.0.0.0 (all interfaces), and it’s the default firewall rules that keep it from being reachable. If those inbound rules are disabled, loosened, or the host firewall is off, 5040 can become needlessly reachable from the LAN — extra attack surface for no benefit, since it doesn’t need to answer the network.
• Minor information/fingerprinting value. An open 5040 is a reliable “this is a modern Windows 10/11 host with Shared Experiences enabled” signal during recon — low severity, but it helps an attacker profile the environment.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

The goal here isn’t to “exploit port 5040” — it’s to confirm the listener is the legitimate CDPSvc, check that it isn’t exposed beyond the local host, and verify the binary is the signed Microsoft service.

See what’s listening and on which address

netstat -anob | findstr 5040

Run from an elevated prompt (-b needs admin). Note the local address: 127.0.0.1:5040 is loopback-only; 0.0.0.0:5040 binds all interfaces (the CDPSvc default) and relies on the firewall to stay unreachable.

Map the port to a process and service (PowerShell)

Get-Process -Id (Get-NetTCPConnection -LocalPort 5040).OwningProcess
tasklist /svc | findstr <PID>

On a healthy host the owning process is svchost.exe and the service listed is CDPSvc.

Confirm the service identity

sc.exe queryex CDPSvc
Get-Service CDPSvc | Format-List *

You should see the display name Connected Devices Platform Service running as LocalService.

Verify the binary is the genuine, signed Microsoft service

Get-AuthenticodeSignature C:\Windows\System32\svchost.exe
Get-AuthenticodeSignature C:\Windows\System32\cdpsvc.dll

A valid signature from Microsoft Windows on both svchost.exe and the cdpsvc.dll service DLL (in System32, not a user or temp path) is what tells you this is the real thing and not an impostor. A copy running from an unusual path, or an invalid/absent signature, is the red flag.

Check reachability from another host

nmap -sT -p 5040 <target>

From off-box, 5040 should show as filtered on a default-firewalled Windows machine. An open result from the network means the inbound firewall protection isn’t in place.

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

What to Look For

Known CVEs and Exploits

Port 5040 itself has no remote-exploit history — there is no unauthenticated “port 5040 RCE.” The vulnerabilities that matter are local elevation-of-privilege flaws in the CDPSvc service code, which require an attacker to already have code execution on the machine. They’re patched in the normal Windows monthly updates.

• CVE-2025-48000 — Use-after-free in the Connected Devices Platform Service. An authorized local user can elevate to SYSTEM. Local only, CVSS 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
• CVE-2025-54102 — Another use-after-free in CDPSvc allowing local privilege escalation to SYSTEM. Local only, CVSS 7.8.
• CVE-2025-59191 — Heap-based buffer overflow in CDPSvc; a low-privileged local user can elevate to SYSTEM. Affects Windows 10 (1809–22H2), Windows 11 (22H2–25H2), and Server 2019/2022/2025. Local only, CVSS 7.8.
• CVE-2018-0952 — The one genuine bug in the Diagnostics Hub Standard Collector (the service this port was once mislabeled as): it allowed file creation in arbitrary locations, giving a local EoP. Local only, CVSS 7.8. Included here because it’s the accurate version of the “Diagnostics Hub” CVE, and it too is a local-access issue, not a 5040 network flaw.

The previous version of this page listed CVE-2018-0824 as a “Windows Diagnostics Hub Standard Collector Service” remote code execution bug. That’s a misattribution — CVE-2018-0824 is a Microsoft COM for Windows deserialization RCE (CWE-502) and has nothing to do with the Diagnostics Hub or port 5040. It has been removed.

Mitigation

CDPSvc is a default Windows service, and for most machines the right call is to leave it alone — disabling it breaks Nearby Sharing, Phone Link, and cross-device clipboard/Shared Experiences. Harden rather than remove:

• Keep Windows patched. The CDPSvc EoP CVEs above are fixed in monthly cumulative updates — routine patching closes them.
• Confirm it’s the real service. Verify the process is a signed svchost.exe hosting cdpsvc.dll from System32. If it isn’t, treat it as a compromise and investigate, don’t just “close the port.”
• Don’t expose it to the network. Leave the host firewall on and the default inbound block for 5040 in place. It never needs to be reachable from other hosts — block 5040 inbound at the host firewall if you want to be explicit.
• Disable only if you genuinely don’t use the features. On a device where Nearby Sharing, Phone Link, and shared clipboard aren’t wanted (a locked-down server or kiosk, say), you can set the service to disabled:

Stop-Service CDPSvc
Set-Service CDPSvc -StartupType Disabled

Expect Nearby Sharing and Phone Link to stop working afterward, and prefer managing this via Group Policy/MDM across a fleet rather than per-machine.

Real-World Example

The everyday “incident” on port 5040 is a false alarm: someone runs netstat -an, sees 0.0.0.0:5040 LISTENING, searches the number, and concludes their PC has been hacked — when it’s just CDPSvc doing its job. That reflex isn’t wrong, though; it’s exactly the right instinct applied to the wrong port. The reason 5040 is a good teaching case is that the correct response — map the port to its process, confirm the owning binary is the signed Microsoft service, and check whether it’s reachable from the network — is the same discipline that catches the real problem: malware that deliberately squats on a mundane, trusted-looking Windows port to hide in plain sight. On 5040 the answer is almost always “benign CDPSvc,” but the value is in verifying it rather than assuming it.

FAQ

Is port 5040 safe, or is it a virus?

On a normal Windows 10/11 machine, port 5040 is safe — it’s the Connected Devices Platform Service (CDPSvc), a signed Microsoft service that powers Nearby Sharing and Phone Link. It’s not a virus. The one way it becomes a concern is if the process listening on 5040 turns out not to be a signed svchost.exe/CDPSvc — that would suggest malware masquerading on the port, which is worth confirming with the checks above.

Why is port 5040 listening on my PC?

Because CDPSvc starts automatically and opens 5040 to coordinate Microsoft’s Shared Experiences features (Nearby Sharing, Phone Link, cross-device clipboard, Timeline). It’s on by default in Windows 10 and 11, which is why the port appears even if you’ve never used those features.

Is port 5040 a remote security risk?

Not in a default configuration. CDPSvc binds the listener but the Windows Firewall blocks inbound 5040, so it isn’t reachable from other hosts. The known CDPSvc vulnerabilities are all local privilege-escalation bugs that require an attacker to already be on the machine — there’s no remote “port 5040 exploit.”

How do I close or disable port 5040?

Set the service to disabled: Stop-Service CDPSvc then Set-Service CDPSvc -StartupType Disabled (elevated). That frees the port, but it also disables Nearby Sharing, Phone Link, and cross-device clipboard, so only do it on machines that don’t use those features. If you just want it off the network, leave the service running and keep 5040 blocked inbound at the host firewall instead.

Is 5040 the Diagnostics Hub Standard Collector?

No — that’s a common mix-up. The Diagnostics Hub Standard Collector (diagsvc) is a separate Visual Studio profiling service and doesn’t own 5040. The process listening on TCP 5040 in Windows 10/11 is CDPSvc, the Connected Devices Platform Service.

TL;DR

• Service: CDPSvc — the Windows Connected Devices Platform Service (hosted in svchost.exe)
• Default port: 5040/TCP, opened by default on Windows 10/11
• What it does: coordinates Shared Experiences — Nearby Sharing, Phone Link, cross-device clipboard/Timeline
• Biggest risk: local privilege-escalation CVEs in CDPSvc (need local access); malware masquerading on the port; needless network exposure — not remote RCE
• Mitigation: keep Windows patched, confirm it’s the signed service, block 5040 inbound at the firewall, and disable CDPSvc only if you don’t use the features