Patch CVE-2025-53772: Secure Web Deploy (MSDeploy) Now

TL;DR — Microsoft has published a security advisory for CVE-2025-53772: a deserialization vulnerability in Web Deploy (msdeploy) that can allow an authenticated (authorized) user who can reach the Web Deploy endpoint to cause remote code execution on the target server. If you run Web Deploy (the Web Deployment Handler / WMSvc / MSDeploy endpoint, commonly exposed at https://<host>:8172/MSDeploy.axd) you should treat this as high priority: apply Microsoft’s security update immediately, or if you cannot patch immediately, restrict network access to the Web Deploy endpoint (block/whitelist port 8172), disable the Web Management Service for hosts that don’t need remote deployments, and hunt for indicators of exploitation. (msrc.microsoft.com)
What this is (short)

• Vulnerability type: insecure / unsafe deserialization of untrusted data in the Web Deploy code path. Deserialization flaws let attackers cause the application to instantiate attacker-controlled object graphs that can trigger arbitrary behavior in-process (including executing OS commands) when gadget chains exist. (arxiv.org)
• Exploitability: requires an authorized/delegated Web Deploy user or otherwise an account able to connect to the msdeploy handler — this is not described as a completely unauthenticated internet‑wide zero‑click RCE, but it is network‑accessible when the Web Management Service is running and remote connections are allowed. (msrc.microsoft.com)
• Typical exposure: Web Deploy’s handler is exposed through the IIS Web Management Service (WMSvc) and commonly listens on TCP 8172 at the endpoint /MSDeploy.axd (or similar). Many installations intentionally expose this for remote deployments and it is often only protected by basic/Windows authentication, so it becomes an attractive target if credentials are weak, reused, or if the deployment account is delegated too broadly. (learn.microsoft.com)

Why this matters

• Deserialization RCE leads to code execution inside IIS worker processes (w3wp.exe) or the msdeploy process, which frequently can be leveraged to:
• drop or reflectively load in-memory payloads (fileless),
• write web shells or backdoors to disk under inetpub,
• move laterally from the web server into domain resources,
• harvest credentials and steal data.
• Because Web Deploy is a management/deployment channel, an attacker who successfully exploits the handler can often perform filesystem or configuration changes that persist across reboots. Microsoft treats this as a serious server‑side exploitation vector and has published an advisory for the CVE. (msrc.microsoft.com)

Technical root cause (high level)

• The Web Deploy handler accepts serialized data structures as part of its deployment and configuration operations. If the server deserializes data from untrusted sources (or insufficiently validated/filtered deployment inputs) using unsafe serializers or without limiting allowed types, attackers can craft serialized payloads that, when deserialized, create object graphs that trigger attacker-controlled behavior (the so‑called “gadget chain” pattern). This class of bugs is well-documented across .NET and Java ecosystems. (arxiv.org)

Where Web Deploy listens and how it’s typically used

• Remote Web Deploy (the Web Deploy Handler) is integrated with IIS’s Web Management Service (WMSvc) and by default is reachable at HTTPS on port 8172 at endpoints such as https://<server>:8172/MSDeploy.axd. Administrators frequently create delegated IIS Manager accounts to let developers or CI/CD hosts deploy without full server admin privileges. That design is convenient — and when exposed with vulnerable code it becomes a high-risk attack surface. (learn.microsoft.com)

Immediate risk and likely attack scenarios

• Attackers with valid credentials for a delegated Web Deploy user (or who can otherwise cause authenticated requests to the Web Deploy handler using stolen or weak credentials) can send specially crafted deployment requests that include a malicious serialized payload and cause code execution on the server.
• In an exploit chain, the attacker typically:
• Identifies hosts with port 8172 exposed (or reachable internally).
• Attempts credential access (phishing, credential stuffing, reuse).
• Submits a deployment or management request containing a malicious serialized payload to the msdeploy handler (/MSDeploy.axd).
• Triggers deserialization in the vulnerable code path, leading to arbitrary code execution within the web process context.
• Establishes persistence (web shell, scheduled task, service, or in-memory loader) and/or performs data exfiltration / lateral movement. (msrc.microsoft.com)

Key immediate actions (what to do in the next 24–72 hours)

• Patch first (highest priority)
• Apply the Microsoft security update for CVE-2025-53772 as provided in the MSRC advisory without delay. Patching is the canonical fix because it modifies the vulnerable deserialization code paths. If you manage many servers, prioritize internet-exposed hosts and any canonical deployment hosts first. (msrc.microsoft.com)
• If you cannot patch immediately — reduce exposure
• Block or whitelist port 8172 at network edge / host firewall so only known build/deploy hosts and admin IPs may reach MSDeploy endpoints.
• Disable the Web Management Service (WMSvc) on servers that do not need remote Web Deploy. If remote deployments are not required, stop and disable the WMSvc service. (learn.microsoft.com)
• Enforce strong access controls
• Rotate credentials used for deployment accounts, require unique non-reused passwords, and enforce MFA on any accounts that can manage web hosts (where MFA is supported).
• Review and tighten management service delegation rules in IIS — limit the operations delegated to non‑administrator users and minimize the scope (site-level instead of server-level where possible). (learn.microsoft.com)
• Hunt for indicators of prior exploitation (immediate triage)
• Search web server file-system for newly created or modified .aspx/.ashx/.asmx files and other suspicious artifacts under inetpub or application directories.
• Review WMSvc and IIS logs for POSTs to /MSDeploy.axd (port 8172) outside maintenance windows or from unusual IPs.
• Look for instances where w3wp.exe or msdeploy processes spawned cmd.exe, powershell.exe, rundll32.exe, or regsvr32.exe; check for child processes or commands with base64 content in parameters.
• Check for recently created scheduled tasks, new service installations, or changes to application pools and local user accounts.
• Capture memory images of suspect processes for forensic analysis if you find suspicious activity. (learn.microsoft.com, msrc.microsoft.com)

Concrete detection queries and rules (examples you can run now)

• Splunk (IIS logs): find POSTs to MSDeploy endpoint
• index=web sourcetype=iis | search cs_uri_stem="/MSDeploy.axd" OR cs_uri_stem="/msdeploy.axd" | stats count by src_ip, cs_uri_stem, cs_method, date_hour
• Windows event / Sysmon: processes spawned by IIS worker process
• Sysmon event ID 1 (ProcessCreate): filter ParentImage contains \w3wp.exe or Image contains msdeploy.exe and (Image endswith \cmd.exe OR Image endswith \powershell.exe OR CommandLine contains "base64" OR CommandLine contains "Invoke-Expression")
• WMSvc trace logs:
• Review %systemdrive%\inetpub\logs\wmsvc\tracinglogfiles* for failed or unexpected delegate/operation requests; look for requests that include suspicious binary/encoded content. (learn.microsoft.com)
• EDR alert hunt:
• Search for child processes of w3wp.exe that perform network connections to unusual external IPs, or create executable payloads in temporary directories (C:\Windows\Temp, %TEMP%) or under inetpub\wwwroot.

Sigma rule skeleton (example)

• title: Suspicious POST to MSDeploy handler with potential deserialization payload
  detection:
  selection:
  EventID: 3 # example mapping depends on log source
  cs_method: "POST"
  cs_uri_stem|contains: "MSDeploy.axd"
  cs_user_agent|contains:
• "msdeploy"
• "WebDeploy"
  condition: selection
  level: high
  (Translate the above to your SIEM’s schema — the important fields are POST to /MSDeploy.axd from unusual IPs or non-CI/CD actors and large request bodies or embedded binary content.)

Indicators of Compromise (IOCs) — things to look for

• Network: inbound connections to TCP 8172 from unknown IPs or from IPs that are not your build/CI/CD infrastructure.
• HTTP: POST requests to /MSDeploy.axd or unusual msdeploy client user‑agents and large multipart bodies that include binary blobs.
• Filesystem: new or modified .aspx (or other script) files in site content folders; files with random names and unusual timestamps in inetpub.
• Processes: unexpected child processes of w3wp.exe or msdeploy.exe (cmd.exe, powershell.exe, rundll32, regsvr32). Look for command-lines containing encoded blobs or base64 content.
• Accounts / Persistence: new IIS Manager users, new local users, new scheduled tasks, or new Windows services created around the time of suspicious network activity.

If you confirm exploitation — immediate incident response steps

• Isolate the affected host(s) from the network (shut down network routing or put NIC into blocking mode) but preserve host for forensic imaging if needed.
• Capture memory and disk images and collect IIS/WMSvc logs, Windows Event logs, and msdeploy traces.
• Rotate credentials used by deployment accounts and any service accounts present on the host; assume any secrets on a compromised host may be exposed.
• Remove malicious files, but only after you have collected forensic artifacts and have analyzed persistence mechanisms (fileless payloads may disappear on restart — document all findings).
• Rebuild the affected host(s) from known-good images after verification and hardening (patch first in staging, confirm fixes, then reintroduce to production).
• Notify stakeholders and follow your organization’s breach-notification policies.

Mitigations beyond patching (longer-term)

• Minimize exposure:
• Only enable remote deployment where necessary. For systems that require CI/CD, place the msdeploy endpoint on a management VLAN and only permit known deploy hosts to talk to it.
• Use network-level access controls (ACLs, perimeter firewall, Azure NSGs, etc.) to allow only the minimal set of source IPs to port 8172.
• Harden authentication and delegation:
• Avoid using the same account for multiple sites; create per‑site delegated accounts with narrow privileges.
• Use strong passwords and require multifactor authentication where possible for admin-level accounts (while msdeploy itself may require application-specific authentication, limiting credential reuse reduces exposure).
• Monitoring & logging:
• Enable WMSvc/IIS trace logging and forward logs to a central SIEM; baseline allowed deployment patterns and create rules for anomalous behavior (sudden large deployments from new IPs, repeated failed auth attempts, etc.). (learn.microsoft.com)
• Code hardening and future-proofing:
• Encourage vendor and internal app teams to avoid binary serializers for untrusted data (BinaryFormatter, similar) and to prefer safe, whitelisted deserialization models or type restrictions. This is a systemic defense against gadget‑chain deserialization attacks. (arxiv.org)

Patching and Web Deploy versions

• Microsoft publishes official Web Deploy packages (Web Deploy v4.0 and later) on the Microsoft Download Center and related IIS pages. You should upgrade to the patched Web Deploy release Microsoft specifies in the MSRC advisory for CVE-2025-53772. If you manage multiple systems, validate the patch process on a test host before rolling out broadly. (microsoft.com, iis.net)

Questions you should answer for each Web Deploy host in your environment

• Is WMSvc enabled and listening on port 8172? (If not, the immediate network exposure is lower.)
• Which accounts are authorized to deploy? Are those accounts unique, protected by MFA, and restricted to specific sites?
• Are there any recent unknown POSTs to /MSDeploy.axd? Are any unexpected child processes connected to w3wp.exe?
• Are there recent unexplained file system changes under site directories or unexpected scheduled tasks/services?

Why a quick network mitigation matters even if you plan to patch

• Attackers often scan for exposed management endpoints and attempt credential stuffing or reuse. Blocking port 8172 at the network edge (or applying a whitelisting rule in the firewall) buys time to patch and prevents opportunistic attackers from reaching the endpoint while you complete remediation. Microsoft’s official guidance for similar Web Deploy exposures has recommended restricting remote management and delegations while fixes are applied. (learn.microsoft.com, msrc.microsoft.com)

Notes about false positives and testing

• Not all POSTs to /MSDeploy.axd are malicious — legitimate deploys will use that endpoint. Before acting, correlate with known deploy schedules, legitimate deploy hosts, and source IPs.
• Test any detection rule in a staging environment and tune thresholds for request body size, frequency, and client identity. Use allowlists for your CI/CD servers to reduce noise.

References and further reading (select authoritative resources cited inline above)

• Microsoft Security Update Guide entry for CVE-2025-53772 (MSRC advisory). (msrc.microsoft.com)
• Microsoft documentation for Web Deploy / Web Deployment Handler and Web Management Service (WMSvc) including default endpoint and configuration guidance. (learn.microsoft.com)
• Web Deploy downloads and release notes (Web Deploy v4.0 / Microsoft Download Center). (microsoft.com, iis.net)
• Academic and community analyses of deserialization vulnerabilities and gadget chains (context for exploitation patterns). (arxiv.org)

Final checklist (short)

• [ ] Immediately apply Microsoft’s security update for CVE-2025-53772 on all Web Deploy hosts. (msrc.microsoft.com)
• [ ] If you cannot patch within 24–72 hours: block/whitelist port 8172 for msdeploy at the network perimeter and disable WMSvc where not needed. (learn.microsoft.com)
• [ ] Rotate and harden credentials for every account that can deploy.
• [ ] Hunt for indicators described above (POSTs to /MSDeploy.axd, w3wp child processes, new .aspx files, scheduled tasks).
• [ ] Collect forensic evidence before remediation if you suspect compromise.
• [ ] Plan a tested rollout of the Microsoft-provided patch across dev/test/stage/prod.

If you want, I can:

• produce ready-to-run Splunk, Sigma, and Sysmon queries tailored to your log schema and environment,
• create a short incident-response playbook that maps detection → containment → eradication → recovery for an exploited Web Deploy host,
• or scan an inventory you provide (list of hosts / IPs that run WMSvc / msdeploy) and produce a prioritized patch and network-mitigation plan.

Which of those would help you most right now?

---

Source: MSRC Security Update Guide - Microsoft Security Response Center