MediaElement/MediaPlayer cannot open any Internet-zone http(s) source on 10.0.11, and reports it as a pack-URI error

[SerZhyAle]

Description

10.0.11 stops MediaElement and MediaPlayer from opening any Internet-zone http:// or https:// source. Every remote stream fails instantly with:

System.InvalidOperationException: Only site-of-origin pack URIs are supported for media.

Local file:// sources still work. 10.0.10 and 10.0.9 play the same URLs normally.

This is not an accident - the code is in MediaPlayerState.OpenMedia, added in the 10.0.11 servicing release:

// Default-credentials zone policy gate for the native media
// pipeline. Unlike the managed WpfWebRequestHelper path, the
// native media layer fetches the URI with system credentials
// by default and we cannot selectively suppress credentials
// from the managed side. To ensure default credentials are not
// sent to Internet/Untrusted-zone hosts, block those HTTP(S)
// URIs from reaching the native pipeline. ...
if (!CoreAppContextSwitches.DoNotApplyZoneCheckForDefaultCredentials
    && (uriToOpen.Scheme == Uri.UriSchemeHttp || uriToOpen.Scheme == Uri.UriSchemeHttps)
    && !MS.Internal.AppModel.DefaultCredentialsZonePolicy.ShouldSendDefaultCredentials(uriToOpen))
{
    _mediaEventsHelper.RaiseMediaFailed(
        new InvalidOperationException(SR.Format(SR.Media_PackURIsAreNotSupported, null)));
    return;
}

The goal is reasonable. Three things about how it shipped are not, and each is a separate ask.

1. The diagnostic points at the wrong thing. SR.Media_PackURIsAreNotSupported is "Only site-of-origin pack URIs are supported for media." Reusing it for a zone-policy block tells a developer their pack URI is wrong when they passed an ordinary https:// URL and no pack URI exists anywhere in the application. Nothing in the message, the HResult (0x80131509, the generic InvalidOperationException value) or the stack trace (null) mentions zones, credentials, security or a switch. It is not searchable either: at the time of writing, Switch.System.Windows.Net.DoNotApplyZoneCheckForDefaultCredentials returns zero hits across GitHub issues and dotnet/docs. A dedicated message naming the policy and the switch would turn a multi-hour bisect into one web search.

2. Blocking the fetch is broader than suppressing the credentials. The comment says default credentials cannot be selectively suppressed from the managed side, so the URI is blocked instead. But the overwhelming majority of WPF media playback - internet radio, podcasts, public video, RTSP - needs no credentials at all and never wanted them attached. Those scenarios pay the full cost of a protection they do not need, and the only available answer is a global escape hatch that turns the protection off for everything, including the cases that genuinely benefit. A per-MediaElement/MediaPlayer opt-out ("fetch this source anonymously"), or an anonymous fetch as the default for Internet-zone media with credentials attached only for Local/Intranet/Trusted, would serve the stated goal without ending remote media playback.

3. It shipped undocumented, in a security release. CVE-2026-62897 is CWE-190, an integer overflow, and the advisory says nothing about media, zones or credentials. There is no breaking-change entry for this, and the switch that restores the previous behaviour is not documented anywhere I can find. Applying a security patch and silently losing all remote media playback is a bad shape for a servicing update, independently of whether the block itself is right.

Reproduction Steps

Two files, no XAML, no packages.

MediaRepro.csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net10.0-windows</TargetFramework>
    <UseWPF>true</UseWPF>
    <AssemblyName>MediaRepro</AssemblyName>
  </PropertyGroup>
</Project>

Program.cs:

using System;
using System.IO;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Media;

internal static class Program
{
    [STAThread]
    private static void Main(string[] args)
    {
        var url = args[0];
        var log = new StreamWriter("repro.log") { AutoFlush = true };

        var app = new Application { ShutdownMode = ShutdownMode.OnExplicitShutdown };

        var element = new MediaElement
        {
            LoadedBehavior = MediaState.Manual,
            UnloadedBehavior = MediaState.Manual,
            Source = new Uri(url)
        };
        element.MediaOpened += (_, _) => log.WriteLine("MediaElement = MediaOpened");
        element.MediaFailed += (_, e) => log.WriteLine("MediaElement = MediaFailed | " + e.ErrorException);

        var player = new MediaPlayer();
        player.MediaOpened += (_, _) => log.WriteLine("MediaPlayer  = MediaOpened");
        player.MediaFailed += (_, e) => log.WriteLine("MediaPlayer  = MediaFailed | " + e.ErrorException);

        new Window { Width = 200, Height = 100, Content = element }.Show();
        element.Play();
        player.Open(new Uri(url));
        player.Play();

        app.Run();
    }
}

dotnet publish -c Release -r win-x64 --self-contained true -o out
out\MediaRepro.exe https://0n-60s.radionetz.de/0n-60s.mp3

To compare against 10.0.10, add a Directory.Build.targets beside the project and publish again. Note that neither the global RuntimeFrameworkVersion property nor RuntimeFrameworkVersion metadata on a FrameworkReference works for this - the first fails restore with NU1102, the second is silently ignored and ships 10.0.11 anyway:

<Project>
  <ItemGroup>
    <KnownFrameworkReference Update="Microsoft.WindowsDesktop.App"
                             DefaultRuntimeFrameworkVersion="10.0.10"
                             LatestRuntimeFrameworkVersion="10.0.10" />
  </ItemGroup>
</Project>

Measured, same source, same machine, same minute:

runtime	PresentationCore.dll	https://	http://	file://
10.0.11	10.0.1126.37416	MediaFailed	MediaFailed	MediaOpened
10.0.11 + switch	10.0.1126.37416	MediaOpened	MediaOpened	MediaOpened
10.0.10	10.0.1026.32716	MediaOpened	MediaOpened	MediaOpened
10.0.9	10.0.926.27113	MediaOpened	MediaOpened	MediaOpened

MediaElement and MediaPlayer behave identically in every row. Self-contained and framework-dependent publishes behave identically. Two unrelated stream hosts behave identically. The 10.0.9 and 10.0.10 rows were also produced a second way, by overlaying only the WindowsDesktop runtime assemblies onto one already-published, otherwise byte-identical application, so the difference is the runtime alone.

Expected behavior

A remote http:// or https:// media source opens and plays, as on 10.0.10 and earlier. If the fetch must not carry default credentials, it should be made anonymously rather than refused.

Failing that, the failure should say what actually happened and name the switch that changes it.

Actual behavior

MediaFailed fires immediately with InvalidOperationException: Only site-of-origin pack URIs are supported for media., HResult 0x80131509, StackTrace null. No pack URI is involved anywhere.

The URI never reaches Media Foundation. Loaded MF modules, same application and URL:

10.0.11:           MFPlat.DLL
10.0.11 + switch:  MF.dll, mfasfsrcsnk.dll, MFCORE.DLL, mfnetcore.dll, MFPlat.DLL,
                   mfps.dll, mfsrcsnk.dll, MFTranscode.DLL
10.0.10:           MF.dll, mfasfsrcsnk.dll, MFCORE.DLL, mfnetcore.dll, MFPlat.DLL,
                   mfps.dll, mfsrcsnk.dll, MFTranscode.DLL

mfnetcore.dll is the Media Foundation network source; on 10.0.11 it is never loaded.

Regression?

Yes, in 10.0.11 (2026-08-11) exactly. 10.0.10 and 10.0.9 both work.

Known Workarounds

<ItemGroup>
  <RuntimeHostConfigurationOption
    Include="Switch.System.Windows.Net.DoNotApplyZoneCheckForDefaultCredentials"
    Value="true" />
</ItemGroup>

Verified: this restores playback on 10.0.11 with the full MF chain loaded.

It is a blunt instrument, though - source documents it as restoring "the previous behavior where every outgoing HttpWebRequest unconditionally has UseDefaultCredentials = true", so an application that wants remote media has to disable the credential protection for its non-media web requests too.

Pinning the runtime back to 10.0.10 also works and is what we shipped first, but it means declining CVE-2026-62897, which is worse. We are moving to the switch.

Impact

Any WPF application that plays network audio or video stops playing anything on 10.0.11. The failure is total, not intermittent, and silent from the user's side: the application starts, its UI works, and no media ever plays.

It is invisible to ordinary build gates. Our full test suite stayed green throughout, because nothing in the application was wrong - the defect arrived with a runtime patch and only surfaces if something actually opens a remote stream during verification. We published a release carrying it before noticing.

Self-contained deployments make it worse: the runtime is baked into the artifact, so an already-shipped build cannot be repaired by patching the machine.

Configuration

• .NET SDK 10.0.400; Microsoft.WindowsDesktop.App 10.0.11 (broken) against 10.0.10 and 10.0.9 (working)
• Windows 11 Pro 10.0.26200 build 26200, x64
• Reproduced self-contained and framework-dependent

Other information

• Throw site: src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/MediaPlayerState.cs, in OpenMedia
• Reused string: Media_PackURIsAreNotSupported in PresentationCore/Resources/ExceptionStringTable.txt
• Switch: Switch.System.Windows.Net.DoNotApplyZoneCheckForDefaultCredentials in PresentationCore/MS/internal/CoreAppContextSwitches.cs
• Policy: MS/Internal/AppModel/DefaultCredentialsZonePolicy.cs

If only one of the three asks is actionable, the first is the cheapest and helps everyone who hits this next: a distinct message naming the zone policy and the switch, instead of the pack-URI string.