Service:
Dynamic Windows MSRPC endpoints; Supermicro IPMI/BMC web serviceProtocol:
TCP/UDPPort:
49152Used for:
The first port in the Windows/IANA ephemeral range, usually handed to a dynamic Microsoft RPC endpoint, and on many Supermicro servers a BMC/IPMI web service that has leaked plaintext credentialsPort 49152 is the very first port in the IANA/Windows ephemeral (dynamic) range, 49152–65535, and that one fact explains almost everything you’ll find on it. Modern Windows hands this range out to services that ask the OS for a port at runtime, so an open 49152 is usually a dynamic Microsoft RPC (MSRPC) endpoint — some system service (Task Scheduler, the Encrypting File System service, the print spooler, a DCOM application) that registered itself with the RPC Endpoint Mapper on port 135 and was assigned the first free high port. The number itself tells you nothing about the service; to learn what actually answers on 49152 you map it back through 135. The other classic occupant is a Supermicro baseboard management controller (BMC): for years, tens of thousands of Supermicro IPMI boards ran a web/UPnP helper on 49152 that would hand an unauthenticated attacker a file of plaintext BMC credentials. So on any open 49152 there are two jobs — resolve the RPC endpoint back to a real service, and rule out the Supermicro IPMI leak.
Why It’s Open
The dominant reason 49152 is open is Windows dynamic RPC. When an RPC-based service starts, it can ask Windows for any free port instead of binding a fixed one. Windows allocates from the top of the ephemeral range, and 49152 is the lowest port in that range — so on a freshly booted Windows host, the first service to request a dynamic endpoint frequently lands exactly on 49152. That endpoint could be almost anything that speaks DCE/RPC: the Task Scheduler (MS-TSCH), the Encrypting File System Remote service (MS-EFSRPC), the print spooler (MS-RPRN/MS-PAR), the Event Log, WMI/DCOM, or a third-party service. Clients never guess the port — they ask the Endpoint Mapper on 135, which returns the interface UUID and its current dynamic port. That is why 135 and 49152+ almost always appear together, and why enumerating 49152 always routes back through 135.
The second reason is hardware management. Many Supermicro server motherboards expose their onboard IPMI/BMC through a small embedded web stack, and on a large family of ATEN-firmware boards a UPnP/web helper listened on TCP 49152. On those boards the port isn’t Windows RPC at all — it’s a BMC service that (in)famously served configuration files, including one holding cleartext administrator credentials. An open 49152 on a rack server, a hosting node, or a management VLAN is therefore worth checking against the Supermicro case before you assume it’s an ordinary Windows RPC endpoint. Because RPC services can also bind UDP, a thorough check scans both protocols.
Common Risks
- The service behind the port is the real attack surface. 49152 is just a number; the risk lives in whatever RPC interface the Endpoint Mapper points you to. Coercion and RCE bugs like PetitPotam (EFSRPC) and PrintNightmare (spooler) are reached over exactly these dynamic RPC endpoints, so an exposed 49152 can be the doorway to a domain-critical service.
- Endpoint Mapper leaks the internal service inventory. Query 135 and it will happily list every registered interface UUID and its dynamic port — a free map of what’s running, letting an attacker pick the vulnerable interface behind 49152.
- Lateral movement over DCE/RPC. Tools such as Impacket’s
wmiexec.pyanddcomexec.py, plus PsExec-style techniques (often paired with SMB on 445), ride RPC/DCOM over dynamic high ports to run commands across a Windows domain once creds are in hand. - Supermicro IPMI plaintext credential disclosure. On vulnerable Supermicro BMCs, an unauthenticated
GET /PSBlock(or/PSStore) to port 49152 returns administrator usernames and passwords in cleartext — an instant, no-exploit-needed takeover of the out-of-band management plane. - BMC compromise means total host compromise. A BMC sits below the OS with power, KVM, and virtual-media control. Owning the IPMI plane via a 49152 leak lets an attacker reboot, reimage, or mount media on the server regardless of what the OS is doing.
- High ports left open by loose firewall rules. Firewalls that permit the whole 49152–65535 range “for RPC” often expose far more than intended, pushing internal management and RPC surfaces out to untrusted zones or the internet.
Want to save time on reporting?
Let PentestPad generate, track, and export your reports - automatically.

Enumeration & Testing
The entire job on 49152 is identification: figure out whether you’re looking at a Windows dynamic RPC endpoint or a Supermicro BMC, then test the real service. Start with a version scan across both protocols.
Detect the service and version
nmap -sV -p 49152 <target>nmap -sU -sV -p 49152 <target>Resolve the dynamic RPC endpoint via the Endpoint Mapper (port 135)
A high MSRPC port is meaningless until you map it back to an interface. Dump every endpoint the target registered on 135, then read off which UUID landed on 49152:
# Impacket: list every RPC interface, its UUID, and its bindings/portsrpcdump.py <target>
# Metasploit: Endpoint Mapper Service Discovery (RPORT defaults to 135)msfconsole -quse auxiliary/scanner/dcerpc/endpoint_mapperset RHOSTS <target>runMap a specific high port back to its interface
# Bind directly to 49152 and enumerate the interfaces exposed thererpcmap.py 'ncacn_ip_tcp:<target>[49152]'Check for the Supermicro IPMI credential leak
If the host is a server/BMC rather than a Windows box, test the plaintext-password disclosure. The vulnerable BMC serves the credential file with no authentication:
# Download the plaintext credential blocks (unauthenticated)curl -s http://<target>:49152/PSBlockcurl -s http://<target>:49152/PSStore
# Nmap NSE that automates the Supermicro IPMI config downloadnmap -p 49152 --script supermicro-ipmi-conf <target>
# Metasploit module for the same 49152 file exposuremsfconsole -quse auxiliary/scanner/http/smt_ipmi_49152_exposureset RHOSTS <target>runIdentify the local process (on the Windows host itself)
# Windows: which PID owns 49152netstat -anob | findstr 49152Record every open 49152, the interface UUID it resolves to, and any credential file you pull, so the evidence lands in the pentest report instead of a scratch terminal you’ll lose.
What to Look For
| Checkpoint | What it means |
|---|---|
nmap -sV reports “Microsoft Windows RPC” |
A dynamic MSRPC endpoint — resolve its UUID through the Endpoint Mapper on 135 |
| Endpoint Mapper maps 49152 to EFSRPC / spooler / Task Scheduler | A specific, potentially exploitable RPC service (PetitPotam, PrintNightmare, etc.) |
| 135 open alongside 49152 | Normal Windows RPC pairing — use 135 to identify what 49152 actually is |
| HTTP/UPnP banner on 49152 (not Windows RPC) | Likely an embedded BMC — test for the Supermicro IPMI leak |
GET /PSBlock returns readable text |
Supermicro plaintext credential disclosure — immediate BMC takeover |
| Whole 49152–65535 range reachable externally | Over-broad firewall rule exposing internal RPC/management surface |
Known CVEs and Exploits
There is no CVE for “port 49152” itself — it’s just the first slot in the ephemeral range. The vulnerabilities that matter belong to whatever is listening, and they split cleanly along the two occupants of this port.
Windows dynamic RPC — the flaw is the service the Endpoint Mapper points you to. Once 135 tells you which interface landed on 49152, that interface’s CVEs apply. The most relevant, all reachable over dynamic RPC endpoints, are:
- CVE-2021-34527 — “PrintNightmare.” A remote code execution flaw in the Windows Print Spooler service (MS-RPRN/MS-PAR), which registers dynamic RPC endpoints just like this one. An attacker who reaches the spooler RPC interface runs code as SYSTEM. CVSS 8.8 and on CISA’s Known Exploited Vulnerabilities list.
- CVE-2021-36942 — “PetitPotam,” the Windows LSA spoofing bug patched to blunt MS-EFSRPC coercion. EFSRPC is exposed over RPC (named pipes and dynamic TCP endpoints), and coercing a machine account into authenticating to an attacker enables NTLM relay to AD CS. CVSS 7.5, also on CISA KEV.
- CVE-2021-26414 — Windows DCOM Server Security Feature Bypass. DCOM rides RPC over these same dynamic high ports; the fix hardens the authentication level DCOM/RPC will accept. CVSS 6.5.
Supermicro IPMI on 49152 — a real, mass-exploited leak with no CVE. The famous unauthenticated plaintext-password disclosure (GET /PSBlock / /PSStore on port 49152 of Supermicro ATEN-firmware BMCs) was never assigned a CVE. Rapid7’s own Metasploit module for it, auxiliary/scanner/http/smt_ipmi_49152_exposure, lists no CVE, and the issue is tracked instead through that module and the Nmap supermicro-ipmi-conf NSE script. It’s no less real for lacking an ID — roughly 32,000 exposed boards were confirmed at disclosure. For the Supermicro IPMI web interface (a separate service on 80/443, not 49152), the stack-overflow RCEs such as CVE-2013-3623 (CVSS 10.0, close_window.cgi) apply — worth checking on the same board, but scope them to the web port, not to 49152.
CVEs removed from the previous version of this page. The old stub cited CVE-2017-8464, which is a Windows Shell
.LNK/shortcut icon RCE with nothing to do with RPC or port 49152 — it was mislabeled here as “LNK file triggering via RPC-based exploitation” and has been removed. It also cited CVE-2020-0662 as an “RPC privilege escalation”; NVD actually describes it as a Windows memory-corruption RCE and does not tie it to dynamic RPC on this port, so it too was dropped. And a note on the Supermicro side: CVE-2014-8272 is often mis-attributed to Supermicro but is in fact a Dell iDRAC IPMI session-ID weakness — it is not the 49152 disclosure and is not used here. Verify every CVE against its NVD record and scope it to the actual service before trusting it.
Mitigation
- Identify the real service before doing anything else. You cannot secure 49152 generically. Resolve it through the Endpoint Mapper on 135, find out whether it’s EFSRPC, the spooler, Task Scheduler, DCOM, or a BMC, and harden that specific thing.
- Patch the service behind the port. Apply the PrintNightmare, PetitPotam, and DCOM hardening updates; disable the print spooler on servers that don’t need it; and enable the DCOM authentication-level enforcement.
- Don’t expose RPC to untrusted networks. Firewall 135 and the dynamic range (49152–65535) so only trusted management hosts can reach them, and never publish them to the internet.
- Pin the RPC dynamic range and allow only that. Use
netsh int ipv4 set dynamicport tcp(or the RPC registry policy) to narrow the port range, then firewall exactly that window instead of the whole 16k-port range. - For Supermicro BMCs: patch the IPMI firmware immediately and rotate every credential that could have leaked, then move the IPMI/BMC plane onto an isolated management VLAN that is never routable from user or internet networks.
- Rescan to confirm. After locking down, re-run
nmap -p 135,49152 <target>(and the Supermicro check) to verify the surface is actually gone, and log the result in your pentest report.
Real-World Example
The cleanest illustration of why 49152 matters is the 2014 Supermicro IPMI disclosure. In June 2014, Zachary Wikholm of CARI.net published that a large family of Supermicro baseboard management controllers ran a service on TCP 49152 that would return the file /PSBlock — an XML blob containing the BMC’s administrator username and password in cleartext — to anyone who asked, with no authentication. The same exposed directory also leaked server.pem keys and WSMAN admin credentials. Using Shodan, researchers found roughly 32,000 vulnerable Supermicro systems answering a GET /PSBlock on 49152, and among them thousands still used trivial default passwords (some literally “password”). Supermicro had been notified the previous November. Because a BMC controls power, console, and virtual media beneath the operating system, each of those leaks was a complete out-of-band takeover of a physical server — no exploit, no overflow, just a plaintext file on a port most operators had never thought to firewall. It’s the port-49152 lesson exactly: the number is mundane and shared, but whatever is bound to it — here, an out-of-band management controller handing out its own password — is the real attack surface.
FAQ
What is port 49152 used for?
Port 49152 is the first port in the IANA/Windows ephemeral (dynamic) range, 49152–65535. On Windows it’s typically handed to a dynamic Microsoft RPC endpoint — a service like Task Scheduler, EFSRPC, the print spooler, or a DCOM app that registered with the Endpoint Mapper on 135 and got the first free high port. On many Supermicro servers it’s instead a BMC/IPMI web service. The port number alone doesn’t identify the service; you have to resolve it.
Why is port 49152 open on my computer?
On a Windows machine it’s almost always normal: some RPC-based system service asked the OS for a dynamic port and was assigned 49152 because it’s the lowest one in the range. You’ll usually see port 135 open alongside it. On a server or hosting node it can instead be an onboard Supermicro IPMI/BMC service — which historically leaked credentials — so identify which one it is before assuming it’s benign.
How do I find out what service is really behind port 49152?
Query the RPC Endpoint Mapper on 135. Run rpcdump.py <host> or the Metasploit auxiliary/scanner/dcerpc/endpoint_mapper module to list every registered interface, its UUID, and its dynamic port, then read off which interface landed on 49152. nmap -sV -p 49152 <host> will label a Windows endpoint “Microsoft Windows RPC”; an HTTP/UPnP banner instead points to a BMC to test with the Supermicro checks.
Is the Supermicro port 49152 password vulnerability still a thing?
The bug is old (disclosed 2014) and patched firmware exists, but unpatched Supermicro BMCs still turn up on management networks and, occasionally, the internet. If you see 49152 answering as HTTP/UPnP on a Supermicro board, test GET /PSBlock and /PSStore — if either returns readable text, the box is fully exposed. Note it has no CVE; it’s tracked via the Metasploit smt_ipmi_49152_exposure module and the supermicro-ipmi-conf NSE script.
Is port 49152 TCP or UDP?
It can be either. RPC services usually bind TCP (ncacn_ip_tcp) but can also use UDP, and the Supermicro BMC service is TCP HTTP/UPnP. Scan both (nmap -sV -p 49152 and nmap -sU -sV -p 49152) so you don’t miss a UDP endpoint.
How do I secure or close port 49152?
Identify the service first. If it’s Windows RPC, patch it (PrintNightmare/PetitPotam/DCOM hardening), optionally pin the RPC dynamic range to a narrow window, and firewall 135 plus the dynamic range to trusted management hosts only. If it’s a Supermicro BMC, patch the IPMI firmware, rotate all credentials, and move the IPMI plane to an isolated VLAN. Then rescan to confirm.
TL;DR
- Service: no single service — the first port of the Windows/IANA dynamic range (49152–65535), usually a dynamic Microsoft RPC endpoint resolved via the Endpoint Mapper on 135; on many Supermicro servers, a BMC/IPMI web service
- Default port: 49152/TCP (and UDP for some RPC services); the lowest ephemeral/dynamic port
- Biggest risk: the service behind the port — RPC interfaces like the spooler (PrintNightmare, CVE-2021-34527) or EFSRPC (PetitPotam, CVE-2021-36942) — or the unauthenticated Supermicro IPMI plaintext-password leak (
GET /PSBlock, ~32,000 boards exposed, no CVE) - Mitigation: resolve the endpoint via 135, patch the real service, pin/firewall the RPC dynamic range to trusted hosts, and for Supermicro BMCs patch IPMI firmware, rotate creds, and isolate the management VLAN