CVE-2026-109476: Patch ASP.NET Core Cookie Disclosure Flaw in Self-Contained Apps and Containers

What Microsoft disclosed​

Microsoft calls CVE-2026-109476 an ASP.NET Core information disclosure vulnerability. The CVE record, as mirrored by OpenCVE, gives a short summary: improper encoding or escaping of output in ASP.NET Core allows an unauthorized attacker to disclose information over a network.

The GitHub security advisory (GHSA-xhj5-c3g8-pfj8) and the matching .NET announcement name the mechanism more precisely: a crafted X-Forwarded-Prefix can inject cookie path delimiters unless PathBase-derived cookie paths percent-encode semicolons. The weakness class is CWE-116, Improper Encoding or Escaping of Output. MITRE describes it as a product that builds a structured message for another component but fails to encode or escape the data correctly, so the message no longer keeps its intended structure.

Here are the key facts:

• CVSS 3.1 base score: 6.1. The vector is AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N: reachable over the network, high attack complexity, no privileges needed, user interaction required, changed scope, high confidentiality impact, and no integrity or availability impact.
• Platforms: Windows, Linux and macOS, on all architectures.
• Published: Advisory version 1.0 went out on November 10, 2026. OpenCVE also lists Published: 2026-11-10.
• Credit: Microsoft acknowledges researcher Raffaello Tamagnini.
• Exploitation status: Rapid7's Patch Tuesday breakdown lists the CVE as Exploitation Less Likely and not publicly disclosed. The SANS table also marks it as neither disclosed nor exploited.

A note on severity labels. The GitHub advisory rates the flaw "Moderate" (CVSS "Medium"). Patch Tuesday trackers that work from Microsoft's Security Update Guide list it as "Important": BleepingComputer's table lists CVE-2026-109476 as Important, and the SANS table matches. The two are compatible. CVSS is a numeric score, while MSRC uses its own severity scale. Your vulnerability scanner might show either label, so don't let the mismatch confuse your triage.

Section summary: This is a cookie-path encoding flaw in ASP.NET Core. The assessed impact is confidentiality only. It is cross-platform and was patched on November 10. Nobody has reported it as exploited or publicly disclosed.

Why a header and a semicolon matter​

The rest of this section is my own explanation from general web-platform knowledge. Microsoft's advisory doesn't spell out an attack sequence.

When ASP.NET Core runs behind a reverse proxy, such as Nginx, YARP, an API gateway or a load balancer that mounts the app under something like /shop, the proxy can pass the original path prefix along in an X-Forwarded-Prefix header. The app can then treat that prefix as its PathBase, so generated URLs and cookie paths point to the right place.

The Set-Cookie header uses semicolons to separate attributes such as Path, Domain, Secure and HttpOnly. If a value built from PathBase ends up in a cookie's Path and contains a raw semicolon, the browser can read part of that value as a new attribute. That matches what CWE-116 describes: the message loses its intended structure. Microsoft's fix is that semicolons in PathBase-derived cookie paths are percent-encoded.

There are also limits to what the evidence supports:

• The CVSS vector says user interaction is required and attack complexity is high. The advisory doesn't say what that interaction is or which app configurations are exposed.
• It's reasonable to infer that apps which honor X-Forwarded-Prefix are the relevant population. Microsoft's FAQ doesn't define exposure that way, though. It tells everyone to compare installed versions against the affected ranges, so do that whatever your proxy setup is.
• No exploit recipe has been published, and this article doesn't try to write one.

Section summary: A forwarded header that sets the app's base path could inject cookie-attribute delimiters. The fix is semicolon encoding. Treat any specific attack chain as unconfirmed.

Affected versions and fixes​

The advisory covers the Microsoft.AspNetCore.App.Runtime packages for every listed runtime identifier: Windows x86, x64 and arm64; macOS x64 and arm64; and Linux arm, arm64 and x64, including the musl (Alpine-style) variants. Every package uses the same version ranges:

Microsoft's .NET Blog post on the month's servicing releases backs this up. It says the November 10, 2026 servicing updates for .NET 10, .NET 9, and .NET 8 include security and non-security fixes, and it lists CVE-2026-109476 against versions 8, 9, 10 and 11.

For anyone on the .NET 11 previews: every preview and release candidate through RC3 is in the affected range, and the fix is the 11.0.0 release. If you're still on an RC build, this is another reason to move to the final release.

Microsoft has also consolidated its announcements. The CVE-specific GitHub issue (#508) was closed as a duplicate of the umbrella "November 2026 ASP.NET Core security updates" announcement (#504). Microsoft notes that the original post remains for existing links and that closing it doesn't withdraw the advisory or its remediation guidance. The umbrella announcement also covers at least one other ASP.NET Core issue this month, a SignalR flaw in which connections are not consistently bound to the identity negotiated at connection establishment, allowing injected messages to execute Hub invocations as the victim. That's a separate CVE, but if you're already patching ASP.NET Core you're covering both.

Who actually needs to act​

Most Windows users don't need to do anything. A home PC that isn't hosting an ASP.NET Core web app isn't the target. This advisory is for:

• Developers who build and ship ASP.NET Core apps.
• IT admins running ASP.NET Core workloads on IIS, Kestrel, containers, or Linux and macOS servers.
• Teams running apps behind reverse proxies or gateways that forward path prefixes. This is my inference from the mechanism Microsoft described, not a scope limit that Microsoft stated.

Step-by-step remediation​

Microsoft's FAQ is short, so here it is as a checklist:

1. Inventory what's deployed. Microsoft says to check deployed runtime and application package versions against the affected ranges. On a machine with shared runtimes, dotnet --list-runtimes lists the installed Microsoft.AspNetCore.App versions.
2. Work out each app's deployment model. Framework-dependent apps use the shared runtime installed on the machine. Self-contained apps carry their own runtime.
3. Patch shared runtimes. Install 8.0.34, 9.0.23, 10.0.15 or 11.0.0 as appropriate, then restart the applications. A process that's still running keeps the old code loaded.
4. Rebuild and redeploy self-contained apps. Microsoft says plainly that updating a machine-wide runtime doesn't replace the runtime embedded in a self-contained app. Container images that bake in an older runtime need the same treatment: rebuild them and redeploy.
5. Update independently referenced packages. If a project references affected packages directly, bump each one to its fixed version.
6. Don't count an SDK update as a fix. Microsoft warns that an SDK update alone doesn't update an application's standalone package references. A build server with a new SDK can still produce a vulnerable app if the references aren't updated.

As general hardening, and not something Microsoft lists for this CVE, it's good practice to accept forwarded headers only from known proxies, so a client on the open internet can't set X-Forwarded-Prefix itself. Treat that as defense in depth. It doesn't replace the patch.

The bigger picture​

The most useful point in this advisory is easy to skim past: updating one runtime on a machine doesn't patch every app on it. Self-contained deployments and container images keep whatever runtime was bundled when they were built, so an app with an old runtime inside can keep running for months after the host was updated. CVE-2026-109476 is a moderate bug with no known exploitation, which makes it a low-stakes reason to check that your patch process reaches inside those bundles.

Is a 6.1 confidentiality-only bug an emergency? The evidence says no: high complexity, user interaction required, and Rapid7 rates exploitation less likely. You still shouldn't defer it indefinitely, because the fix is an ordinary servicing update. The risk is in self-contained apps and old container images that miss the fix while everyone assumes the runtime update covered them.

Bottom line: If you run ASP.NET Core on .NET 8, 9, 10 or an 11 preview, update to 8.0.34, 9.0.23, 10.0.15 or 11.0.0, restart your apps, and rebuild anything self-contained.