Summary. Microsoft Web Deploy (msdeploy) contains a high-severity flaw (CVSS 8.8) stemming from deserialization of untrusted data. An authenticated attacker can reach code execution over the network. Patch is available; update immediately.
What’s Actually Vulnerable?
-
Class: CWE-502 — Deserialization of Untrusted Data
-
Impact: Remote Code Execution (RCE) with service privileges
-
Auth: Low privileges required (no user interaction)
-
Fix: Install the latest Web Deploy v4.0 package which contains the remediation for CVE-2025-53772. If Web Deploy came with Visual Studio, uninstall that first and install the updated package.
Exposure surface. In typical deployments, Web Deploy is reachable via the Web Management Service (WMSvc) on HTTPS 8172/TCP, using the handler endpoint /MsDeploy.axd
. (Some setups may also surface MsDepSvc over 80/TCP.)
Attack Chain (Conceptual — No PoC)
-
Access: Attacker holds low-privilege credentials to a target that exposes Web Deploy (e.g.,
https://host:8172/MsDeploy.axd
). -
Payload: A serialized object is crafted so that, when deserialized by server logic, it invokes attacker-controlled behavior.
-
Trigger: The payload is sent in an authenticated request; the service deserializes untrusted content.
-
Effect: The deserialization flow reaches a “gadget” or dangerous sink → arbitrary code execution under the service’s account.
As of the August 2025 Patch Tuesday coverage, CVE-2025-53772 was not publicly exploited and no public PoC was noted by Rapid7. Still, risk is high. Patch now.
Safe Code Illustrations — How This Class of Bug Happens (and How to Fix It)
These snippets are illustrative, not the Web Deploy code. They show how deserialization bugs arise in .NET stacks and how to prevent them.
1) JSON Polymorphism: Dangerous Defaults
⚠️ Vulnerable pattern (illustrative C#):
// DO NOT DO THIS using Newtonsoft.Json; public static object InsecureDeserialize(string json) { // TypeNameHandling.All accepts $type from attacker input → remote type materialization. return JsonConvert.DeserializeObject( json, new JsonSerializerSettings { TypeNameHandling = TypeNameHandling.All // dangerous // No SerializationBinder to restrict types } ); }
✅ Hardened pattern (restrict types / disable polymorphic type hints):
using Newtonsoft.Json; using System; using System.Collections.Generic; public sealed class KnownTypesBinder : ISerializationBinder { private readonly IDictionary<string, Type> _allowed = new Dictionary<string, Type> { ["DeploymentRequest"] = typeof(DeploymentRequest), ["PackageMetadata"] = typeof(PackageMetadata) }; public Type BindToType(string assemblyName, string typeName) => _allowed.TryGetValue(typeName, out var t) ? t : throw new JsonSerializationException("Type not allowed."); public void BindToName(Type serializedType, out string assemblyName, out string typeName) { assemblyName = null; typeName = serializedType.Name; } } public static T SecureDeserialize<T>(string json) { var settings = new JsonSerializerSettings { // Prefer None; if you MUST support polymorphism, combine Auto with a strict binder. TypeNameHandling = TypeNameHandling.None, SerializationBinder = new KnownTypesBinder() }; return JsonConvert.DeserializeObject<T>(json, settings); }
2) .NET Binary/XML Deserialization: Dangerous Sinks
⚠️ Anti-pattern (legacy .NET):
// DO NOT USE BinaryFormatter on untrusted data (ever). // var bf = new BinaryFormatter(); // var obj = bf.Deserialize(networkStream); // classic dangerous sink
✅ Safer alternative with explicit model & quotas:
using System.IO; using System.Runtime.Serialization; using System.Xml; [DataContract] public sealed class DeploymentRequest { [DataMember] public string SiteName { get; set; } [DataMember] public PackageMetadata Package { get; set; } } [DataContract] public sealed class PackageMetadata { [DataMember] public string Hash { get; set; } [DataMember] public long Size { get; set; } } public static DeploymentRequest ReadDeploymentRequest(Stream s) { var quotas = new XmlDictionaryReaderQuotas { MaxDepth = 32, MaxArrayLength = 1024 * 1024, MaxStringContentLength = 1024 * 1024 }; using var xr = XmlDictionaryReader.CreateTextReader(s, quotas); var serializer = new DataContractSerializer( typeof(DeploymentRequest), knownTypes: new[] { typeof(PackageMetadata) }, // explicit known types only maxItemsInObjectGraph: 1024, ignoreExtensionDataObject: true, preserveObjectReferences: false ); return (DeploymentRequest)serializer.ReadObject(xr); // model-bound, not object }
Key takeaways from the code above:
-
Never deserialize to
object
or permissive polymorphic types from user input. -
Disable or strictly bind
$type
(JSON) / explicit known types (XML). -
Impose quotas and size limits to reduce DoS/deserialization abuse surface.
Blue-Team: Quick Detection & Verification (Safe)
Log analytics — look for unusual POSTs to the handler and spikes in body sizes:
index=iis sourcetype="iis:log" (cs_uri_stem="/MsDeploy.axd") | stats count, values(cs_method) as methods, values(sc_status) as statuses, avg(cs_bytes) as avg_req_bytes, avg(sc_bytes) as avg_resp_bytes by c_ip, cs_username | where count > 10 OR (avg_req_bytes > 50000)
PowerShell — check installed Web Deploy & versions (safe):
$paths = @( "$env:ProgramFiles\IIS\Microsoft Web Deploy V4\msdeploy.exe", "$env:ProgramFiles\IIS\Microsoft Web Deploy V3\msdeploy.exe", "$env:ProgramFiles(x86)\IIS\Microsoft Web Deploy V3\msdeploy.exe" ) $paths | ? { Test-Path $_ } | % { (Get-Item $_).VersionInfo | Select FileName, ProductVersion, FileVersion }
Then install the updated Web Deploy v4.0 package that includes the fix for CVE-2025-53772 (remove any older Visual Studio-bundled Web Deploy first).
Mitigation Checklist
-
Patch now: Install the fixed Web Deploy v4.0 build.
-
Reduce exposure: Restrict 8172/TCP (WMSvc) to trusted admin networks/VPN; do not leave it internet-wide.
-
Harden auth: Enforce MFA; keep delegated deployment accounts least-privileged.
-
Observe & limit: Enable detailed IIS/WMSvc logging and rate/size limits for handler traffic.
Final Note
We intentionally do not publish a working exploit or PoC. The goal here is to help your readers understand the vulnerability class, recognize risky code patterns, and fix them, while avoiding material that directly enables abuse.
Discussion