dotnet/wpf · error · FileFormatException

SR.Resource_XpsPackageBoundaryViolation

Error message

SR.Resource_XpsPackageBoundaryViolation

What it means

ColorContext.Initialize throws FileFormatException(SR.Resource_XpsPackageBoundaryViolation) when a non-standard profile URI is being loaded while XPS package URI boundary checks fail. The library captures the active XPS package origin via XpsLoadingContext and only allows URIs that are explicitly permitted against that package; this is a security defense against loading arbitrary profile resources across package boundaries.

Solutions

  1. Ensure the profile URI is inside the XPS package being loaded and use a pack URI relative to that package
  2. Use one of the standard/system profile URIs (sRGB etc.) which are exempt from the boundary check
  3. If the profile legitimately lives in another package, load the correct XpsPackage/XpsLoadingContext first so ActivePackageUri matches
  4. Catch FileFormatException and surface a clear 'profile not allowed in this package' message instead of crashing

Example fix

// before
var ctx = new ColorContext(new Uri("file:///C:/profiles/custom.icc"));
// after
var ctx = new ColorContext(new Uri("pack://application:,,,/profiles/custom.icc")); // within allowed package, or use PixelFormats sRGB standard profile
Defensive patterns

Strategy: validation

Validate before calling

bool isAllowed = XpsLoadingContext.ActivePackageUri != null && (isStandardProfileUriNotFromUser || XpsLoadingContext.IsUriAllowedAgainstPackage(XpsLoadingContext.ActivePackageUri, profileUri));

Try / catch

try { var ctx = new ColorContext(profileUri); } catch (FileFormatException ex) { /* fall back to standard profile or surface package-boundary error */ }

Prevention

When it happens

Trigger: Constructing a ColorContext with a profileUri that is not a standard/system profile URI while XpsLoadingContext.IsUriAllowedAgainstPackage returns false for the currently active XPS package URI (e.g. profile URI points outside the loading XPS package).

Common situations: Loading XPS documents that reference embedded ICC color profiles with URIs not belonging to the package; hand-crafted or tampered XPS files; code creating ColorContext from a relative or cross-package URI while an XPS package load is in progress.

Understand the failure class

Background: Path traversal blocked: "path escapes the workspace" and "outside site root" errors when a path will not stay inside its allowed directory — this error's family across 26 libraries.

Related errors

AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14). Data as JSON: /api/errors/71b6929b31b641e6. Report an issue: GitHub.

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/PresentationCore/System/Windows/Media/ColorContext.cs:499

            bool tryProfileFromResource = false;

            ArgumentNullException.ThrowIfNull(profileUri);

            if (!profileUri.IsAbsoluteUri)
            {
                throw new ArgumentException(SR.UriNotAbsolute, nameof(profileUri));
            }

            // Security: When loading XPS content, block color profile URIs that
            // escape the current package to prevent SSRF. Standard system profiles
            // (isStandardProfileUriNotFromUser == true) are always local file
            // paths and are exempt from this check. Uses both ambient context
            // and captured origin for defense-in-depth.
            _xpsPackageOrigin = XpsLoadingContext.ActivePackageUri;
            if (!isStandardProfileUriNotFromUser
                && !XpsLoadingContext.IsUriAllowedAgainstPackage(_xpsPackageOrigin, profileUri))
            {
                throw new FileFormatException(SR.Resource_XpsPackageBoundaryViolation);
            }

            _profileUri = profileUri;
            _isProfileUriNotFromUser = isStandardProfileUriNotFromUser;

            Stream profileStream = null;

            try
            {
                profileStream = WpfWebRequestHelper.CreateRequestAndGetResponseStream(profileUri);
            }
            catch (WebException)
            {
                //
                // If we couldn't load the system's default color profile (e.g. in partial trust), load a color profile from
                // a resource so the image shows up at least. If the user specified a color profile and we weren't 
                // able to load it, we'll fail to avoid letting the user use this resource fallback as a way to discover 
                // files on disk.

View on GitHub (pinned to 81131a70a4)