Update ASP.net Core

What the ASP.NET Core patcher does

This Automox Worklet™ patches the ASP.NET Core runtime on Windows endpoints by upgrading outdated installations to a version you specify. The Worklet inspects both 32-bit and 64-bit registry hives, identifies endpoints running an older Shared Framework build, and replaces the runtime with a Microsoft installer you stage in the Automox console. Endpoints that do not have ASP.NET Core installed exit as not applicable, so a single policy can target a mixed fleet of web hosts, build agents, and developer workstations.

ASP.NET Core ships as a separate runtime from the .NET Framework and the .NET Desktop Runtime, and it can be installed side-by-side across major versions. The Worklet reads the Shared Framework key at HKLM:\SOFTWARE\Microsoft\ASP.NET Core\Shared Framework\v{major} (and its WOW6432Node counterpart) to find every installed minor version. It then compares each version string against the $fVersion variable using a semantic version comparison, so 6.0.10 is correctly seen as older than 6.0.25.

The remediation phase reads the $x64Fname and $x86Fname variables, which name the installer files you upload to the policy. You download the official Microsoft installer (the dotnet-hosting-{version}-win.exe bundle or the aspnetcore-runtime-{version}-win-x64.exe / -win-x86.exe payloads) from the .NET release feed and attach them to the Worklet. The Worklet runs each installer with /quiet /norestart and writes a log to %WINDIR%\TEMP for post-run verification.

Why patch the ASP.NET Core runtime

ASP.NET Core is one of the most common web runtimes on Windows servers and developer machines, and Microsoft ships security updates on a near-monthly cadence through the .NET release notes. Outdated runtimes have carried serious vulnerabilities in the past, including CVE-2024-30045 (remote code execution in .NET and Visual Studio affecting .NET 7.0.x and 8.0.x), CVE-2024-21392 (denial of service in HTTP/3 request handling), and CVE-2023-36049 (FTP injection). Web servers running an old Shared Framework expose every site bound to that runtime, and a single missed update can be the entry point for credential theft or lateral movement.

ASP.NET Core advisories regularly carry HTTP/2 reset, denial-of-service, and authentication bypass CVEs that affect any Windows host running the Microsoft.AspNetCore.App Shared Framework. Developer workstations, build agents, and production web hosts often hold a long tail of side-by-side runtime versions that Microsoft Update does not always reach. This Worklet aligns every Windows endpoint to the patched 6.0, 8.0, or 9.0 build you specify in the policy, and pairs cleanly with the companion .NET Desktop Runtime and Hosting Bundle worklets so the full runtime surface stays current.

How ASP.NET Core patching works

1. Evaluation phase: The Worklet enumerates the ASP.NET Core Shared Framework key at HKLM:\SOFTWARE\Microsoft\ASP.NET Core\Shared Framework\v{major} and its 32-bit reflection under HKLM:\SOFTWARE\WOW6432Node\Microsoft\ASP.NET Core\Shared Framework\v{major}. It reads every installed minor version, cross-references the value against the $fVersion variable using [version] comparison, and flags the endpoint for remediation when any installed runtime is older than the target. The script also accepts dotnet --list-runtimes output as a fallback when the registry hive is missing on newer hosting bundles. Endpoints without an ASP.NET Core key in either hive exit as not applicable and do not consume a remediation run.

2. Remediation phase: The Worklet stages the attached installer files using Get-AutomoxFile, then invokes each one in turn. For an outdated x64 runtime on a 64-bit endpoint, it runs Start-Process -FilePath $x64Fname -ArgumentList '/quiet /norestart /log %WINDIR%\TEMP\aspnetcore-x64.log' -Wait. For an outdated x86 runtime on either a 32-bit or 64-bit endpoint, it runs the same command against $x86Fname with a separate log. The bundled hosting installer also handles IIS module replacement when the ANCMv2 module is present. Post-install, the script re-reads the registry to confirm the new version and exits 0 on success or surfaces the installer exit code (1602 user cancel, 1603 fatal error, 3010 reboot required) in the activity log.

ASP.NET Core patch requirements

• Windows 10, Windows 11, Windows Server 2016, 2019, 2022, or 2025 with ASP.NET Core already installed (the Worklet upgrades existing installations and does not perform first-time deployments)

• PowerShell 5.1 or later for the [version] type accelerator and Start-Process -Wait behavior

• Local administrator or SYSTEM context (the default Automox agent context already meets this)

• Download the Microsoft installers ('Installers' link, not 'Binaries') from the .NET download page and upload both x64 and x86 variants to the Automox console as attached files

• Set $fVersion to the target minor version (for example, '8.0.11' or '6.0.36') matching the file you uploaded

• Set $x64Fname and $x86Fname to the exact filenames you attached to the policy (e.g., 'aspnetcore-runtime-8.0.11-win-x64.exe')

• Sufficient disk space on %WINDIR%\TEMP for installer extraction (the Hosting Bundle requires roughly 300 MB free)

Expected state after the ASP.NET Core patch

After remediation, the Shared Framework registry value at HKLM:\SOFTWARE\Microsoft\ASP.NET Core\Shared Framework\v{major} reports the target version on both 32-bit and 64-bit hives, and dotnet --list-runtimes shows Microsoft.AspNetCore.App at the new build. Subsequent policy runs evaluate the endpoint as compliant and skip remediation, because the registry comparison resolves to equal or newer. Web applications hosted on IIS or Kestrel continue to bind to the new Shared Framework on the next app pool recycle, and the .NET runtime roll-forward configuration keeps targeted apps on the patched minor version.

Validate by opening an elevated PowerShell session on a remediated endpoint and running dotnet --list-runtimes. The output should list Microsoft.AspNetCore.App at the version specified in $fVersion. For audit evidence, capture %WINDIR%\TEMP\aspnetcore-x64.log and %WINDIR%\TEMP\aspnetcore-x86.log alongside the policy run identifier from the Automox Activity Log. If an installer fails, the log file contains the MSI session detail, including return codes such as 1603 (fatal install error, typically a file-in-use or permissions problem on the application pool), 1618 (another install in progress), or 3010 (success, reboot pending). Resolve file-in-use failures by stopping the affected IIS application pools or recycling the worker process before retrying the policy.