Security Digest · Feb 27, 2024 · Vulnerability · Web framework

.NET Framework CVE-2024-29059: ObjRef Leak Enables RCE

ASP.NET apps on .NET Framework leaked .NET Remoting ObjRef URIs, opening a path to RCE. Fixed Jan 2024, in KEV since Feb 2025. Check legacy IIS hosts.

Our verdict

Check exposure

Windows servers with any .NET Framework update since January 2024 are fixed; find the unpatched legacy IIS hosts and anyone who switched LateHttpHeaderParsing back on.

Who must act: Teams running ASP.NET on .NET Framework (IIS, or Azure App Service on the ASP.NET 3.5/4.8 stack) where hosts missed the January 2024 .NET updates or set microsoft:Remoting:LateHttpHeaderParsing to true.

Who can relax: Hosts with a January 2024 or later .NET Framework update and default settings, and apps on modern .NET (formerly .NET Core), which is not in Microsoft's affected list.

Affected
.NET Framework 2.0 SP2 through 4.8.1 on Windows 10, Windows 11 and Windows Server 2008 to 2022, before the January 9, 2024 updates
ASP.NET apps on IIS with the default *.rem / *.soap HTTP .NET Remoting handler mappings
Patched hosts where microsoft:Remoting:LateHttpHeaderParsing is set to true
Fixed in
January 9, 2024 .NET Framework updates or later, e.g. KB5034275 (Windows 10 22H2), KB5033920 (Windows 11 22H2/23H2), KB5034272 (Server 2022), KB5034273 (Server 2019), KB5033910 / KB5034119 (Server 2016)
Monthly rollups KB5034278 (Server 2012), KB5034279 (Server 2012 R2), KB5034277 (Server 2008 R2)
CVSS
7.5 (v3.1, vendor)
EPSS
98.6% (percentile 99.9)
CISA KEV
Yes, listed as known exploited
Exploitation
Exploited in the wild
Severity
High

What to do

  1. Confirm every IIS host has a .NET Framework cumulative update from January 2024 or later.
  2. Search web.config files and app settings for microsoft:Remoting:LateHttpHeaderParsing and remove any value of true.
  3. If no app uses .NET Remoting, block the .rem and .soap extensions with IIS request filtering.
  4. Probe internet-facing ASP.NET apps with CODE WHITE's detection request and confirm no ObjRef URI comes back.
  5. Take any real .NET Remoting endpoint off the internet and plan its migration, as Microsoft advises.

How to check if you are affected or compromised

  • Search IIS logs (C:\inetpub\logs\LogFiles\W3SVC*) for requests to .rem or .soap paths, especially RemoteApplicationMetadata.rem?wsdl.
  • Look for w3wp.exe spawning cmd.exe, powershell.exe or other shells, and for new files in web roots.
  • Correlate IDS/IPS alerts for CVE-2024-29059 with each host's .NET patch date.

What happened#

On February 27, 2024, Markus Wulftange of CODE WHITE published details and exploit tooling for a hidden attack surface in ASP.NET. ASP.NET apps on .NET Framework could leak internal .NET Remoting object URIs (ObjRefs). An attacker who obtains one can send Remoting requests to the object and, with further tricks, reach unauthenticated remote code execution.

CODE WHITE reported the bug to Microsoft on November 3, 2023. MSRC closed the case on December 28, saying it did "not meet our bar for immediate servicing". Even so, the January 9, 2024 .NET Framework updates changed the HTTP header parsing that made the leak possible. Microsoft only published CVE-2024-29059 on March 22, 2024, explaining that the CVE was "inadvertently omitted" from the January release. Microsoft calls it information disclosure (CVSS 3.1 7.5, network, no authentication, no user interaction). Its FAQ says an attacker "could obtain the ObjRef URI which could lead to remote code execution."

CISA added the bug to KEV on February 4, 2025, without saying publicly why. SecurityWeek found "there do not appear to be any public reports describing attacks". FortiGuard later reported "a steady stream of attack attempts" blocked across up to 1,200 devices, without naming an actor. As of Oct 23, 2026, no campaign has been publicly attributed.

Who is affected#

Microsoft lists .NET Framework 2.0 SP2 through 4.8.1 on Windows 10, Windows 11 and Windows Server 2008 through 2022. The real exposure is ASP.NET on IIS. The *.rem and *.soap handler mappings mean the HTTP Remoting channel "is available by default", even in apps that never use Remoting. The leak also needs a MarshalByRefObject in the request's logical call context. CODE WHITE names Application Insights' DiagnosticSource among the suspected sources of one. It also found Azure App Service apps on the ASP.NET 4.8 stack affected by default.

Do you really need to act?#

If your servers have taken any .NET Framework update since January 2024, you are fixed. One exception: setting the app setting microsoft:Remoting:LateHttpHeaderParsing to true restores the vulnerable behavior. By default the deserialization runs under TypeFilterLevel.Low, so RCE needs an extra bypass that CODE WHITE did not publish. Still, public tooling and KEV status make unpatched, internet-facing IIS hosts a real target. The risk is concentrated in legacy servers that fell off the patch cycle.

What to do now#

  1. Check patches: Get-HotFix | Sort-Object InstalledOn -Descending. Look for a .NET Framework cumulative update from January 2024 or later, such as KB5034275 (Windows 10 22H2), KB5033920 (Windows 11 22H2/23H2), KB5034272 (Server 2022), KB5034273 (Server 2019), or KB5033910/KB5034119 (Server 2016).
  2. Check for the opt-out: Get-ChildItem C:\inetpub -Recurse -Filter web.config | Select-String LateHttpHeaderParsing. Also check Azure App Service app settings.
  3. If nothing uses Remoting, block the extensions: %windir%\system32\inetsrv\appcmd.exe set config /section:requestFiltering /+fileExtensions.[fileExtension='.rem',allowed='false'], then the same for .soap.
  4. Probe your apps: curl -s -H "__RequestVerb: POST" -H "Content-Type: text/xml" "https://app.example.com/RemoteApplicationMetadata.rem?wsdl". A response containing a path like /<hex>/<name>_<n>.rem means an ObjRef is leaking.
  5. Microsoft's own guidance is that you "should never expose a .NET Remoting endpoint to the Internet". Move any real Remoting endpoint behind a trust boundary and plan its migration.

How to tell if you were hit#

Search IIS logs: Select-String -Path C:\inetpub\logs\LogFiles\W3SVC*\*.log -Pattern '\.rem|\.soap'. Requests for RemoteApplicationMetadata.rem?wsdl from outside are probes. IIS does not log the __RequestVerb header by default. On hosts that were unpatched and internet-facing, check EDR for w3wp.exe spawning shells, and look for new files in web roots and new local accounts. If you find any of these, treat the host as compromised.

Timeline#

  • — CODE WHITE reports the bug to MSRC.
  • — The .NET Framework updates fix it, without a CVE.
  • — CODE WHITE publishes details and tooling.
  • — Microsoft publishes CVE-2024-29059.
  • — CISA adds it to KEV, with a deadline of Feb 25, 2025.
  • — FortiGuard reports ongoing attack attempts.

Vulnerability records

  • CVE-2024-29059 · KEV 2025-02-04 · .NET Framework Information Disclosure Vulnerability

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

  1. Microsoft — Security Update Guide: CVE-2024-29059 msrc.microsoft.com
  2. Microsoft — March 2024 Security Updates (CVRF) api.msrc.microsoft.com
  3. CVE record — CVE-2024-29059 cve.org
  4. NVD — CVE-2024-29059 nvd.nist.gov
  5. CISA — Known Exploited Vulnerabilities: CVE-2024-29059 cisa.gov
  6. CODE WHITE — Leaking ObjRefs to Exploit HTTP .NET Remoting code-white.com
  7. CODE WHITE — HttpRemotingObjRefLeak (GitHub) github.com
  8. FortiGuard Labs — Outbreak Alert: Microsoft .NET Framework Information Disclosure fortiguard.com

Coverage and analysis

  1. SecurityWeek — CISA Issues Exploitation Warning for .NET Vulnerability securityweek.com