Duende.BFF 4.3.3

This release lets BFF accept V2 license keys, and moves BFF's dependencies onto the ASP.NET Core 10.0.14 packages.

V8 style license keys

Identity Server V8 introduced a license key format (internally referred to as V2). BFF now reads and validates its license key the same way IdentityServer does. Before this release, BFF rejected Identity Server V8 license keys (V2): it logged "Error validating the license key" and ran as if it had no license. V2 keys are now accepted. Existing Identity Server V7 license keys(V1) keys keep working.

BFF still reads the key from BffOptions.LicenseKey, or from Duende_License.key or Duende_IdentityServer_License.key in the current directory. When IdentityServer and BFF run in the same host, they share the license.

ASP.NET Core 10.0.14 (CVE-2026-102870)

GitHub advisory GHSA-g27p-qf6j-c96c (CVE-2026-102870) now covers Microsoft.AspNetCore.Components.WebAssembly.Server 10.0.13. Duende.BFF.Blazor.Client 4.3.3 requires the 10.0.14 versions of Microsoft.AspNetCore.Components.Authorization, Microsoft.AspNetCore.Components.WebAssembly and Microsoft.Extensions.Http, and the BFF templates use 10.0.14.

If your Blazor host references Microsoft.AspNetCore.Components.WebAssembly.Server directly, update it to 10.0.14. Also update the .NET runtime on your hosts and container images to 10.0.14.

Breaking changes

None to the public API.

Full Changelog: bff-4.3.2...bff-4.3.3

This is a preview release of Duende Storage.

Full Changelog: storage-2.0.0-preview.3...storage-2.0.0-preview.6

This is a preview release of Duende Spaces. It builds on Duende Storage 2.0.0-preview.6.

Breaking changes

• Data protection is partitioned by space by default. Every data protector is bound to the space in effect when it protects or unprotects, so a value protected in one space can't be read in another. Values protected before this change keep working in the Default space only; in other spaces, cookies and other protected values from earlier versions can no longer be read, so users have to sign in again. Set SpacesOptions.PartitionDataProtection to false to turn this off.
• Space names longer than 500 characters are rejected when a space is created or updated.

What's changed

• Shared data across spaces. Use GetUnpartitioned() on the data protection provider (or IUnpartitionedDataProtectionSource) for data that must be readable in every space, such as signing keys.
• Own cache for Spaces. Spaces caches space resolution and routing in a HybridCache registered under SpacesServiceProviderKeys.SpacesCache. Register your own under that key, for example to use a separate distributed cache; otherwise Spaces registers one with default settings.
• Cache entries per space. Entries in the space-aware HybridCache are keyed by space, so two spaces using the same key no longer share a value. RemoveByTagAsync still removes matching entries in every space.
• Space queries. Space queries honor paging, sorting and filters, and return the filtered total.

Fixes

• Response callbacks (OnStarting, OnCompleted) now run in the space they were registered in. Before, a sliding cookie renewed on a response without a body failed with a 500, and a server-side session could be renewed in the Default space's storage.

Full Changelog: spaces-1.0.0-preview.3...spaces-1.0.0-preview.6

This is a preview release of IdentityServer 8.1. It builds on Duende Spaces 1.0.0-preview.6 and Duende Storage 2.0.0-preview.6.

Breaking changes

• Add Spaces from the IdentityServer builder. Call AddSpaces(configure) or AddSpaces(storageInstanceId, configure) on the IdentityServer builder, instead of services.AddSpaces() plus a separate Configure<SpacesOptions>.
• Spaces and the Entity Framework stores can't be combined. The Entity Framework stores keep one database for all spaces, so a host that uses Spaces with the Entity Framework configuration or operational store now fails at startup. Use AddConfigurationStorage() and AddOperationalStorage() with Spaces.
• Data protection is partitioned by space. With Spaces, everything IdentityServer protects (cookies, PAR requests, server-side session tickets, DPoP nonces and so on) is bound to its space. Values protected before upgrading keep working in the Default space only. Signing keys stay readable in every space. See the Duende Spaces 1.0.0-preview.6 release notes.

What's changed

• Expired data is cleaned up in every storage database. The purge of expired data and the outbox processor now run for every database registered with AddStorage, not only when AddOperationalStorage is used. For example, expired passkey challenges in a User Management database are now purged.
• The storage purge follows the registered TimeProvider.
• The IdentityServer conformance report uses Duende.ConformanceReport 0.3.0, which checks PAR, loopback redirects, discovery and the signing algorithm options in more detail.
• The XML docs for EnableJwtRequestUri link to guidance on protecting against SSRF.

Fixes

• Dynamic providers no longer keep outdated options after a provider is changed, or deleted and re-created under the same scheme, while other requests are in flight.

Full Changelog: is-8.1.0-preview.4...is-8.1.0-preview.6

Duende Storage 1.1.1

This is a security patch release for the 1.1.x line. It updates the .NET and SQLite dependencies of Duende Storage to versions that fix known vulnerabilities. We recommend that all users of 1.1.x upgrade.

There are no API or behavior changes.

Security fixes

• Duende.Storage.MsSql now requires System.Security.Cryptography.Pkcs 10.0.13 (CVE-2026-84008, CVE-2026-70162). Microsoft.Data.SqlClient brings in an older, vulnerable version of this package. Duende.Storage.MsSql now references the patched version directly.
• Duende.Storage.Sqlite now requires the patched SQLite native library (CVE-2025-6965). It depends on Microsoft.Data.Sqlite 10.0.9 and directly on SQLitePCLRaw.bundle_e_sqlite3 3.0.3, so applications no longer pick up the vulnerable SQLitePCLRaw.lib.e_sqlite3 2.1.11.
• Duende.Storage.CliPlugin bundles the patched assemblies: System.Security.Cryptography.Pkcs 10.0.13, Microsoft.Data.Sqlite 10.0.9 and SQLitePCLRaw 3.0.3.

Other changes

• The Microsoft.Extensions.* dependencies of all packages now require the October 2026 .NET servicing release (10.0.13).

This release moves IdentityServer's dependencies onto the .NET October 2026 security updates, and fixes an exception during access token validation.

Update your .NET runtime

Most of the October 2026 .NET vulnerabilities are in the ASP.NET Core shared framework, so upgrading IdentityServer doesn't fix them. Update every IdentityServer host and container image to the October 2026 .NET runtime. For IdentityServer, the most important fixes are:

• SAML: five Signed XML denial-of-service fixes (CVE-2026-58280, CVE-2026-69651, CVE-2026-96958, CVE-2026-96959, CVE-2026-96960). IdentityServer's SAML endpoints validate and decrypt XML before anyone signs in. System.Security.Cryptography.Xml loads from the shared framework, so these fixes come from the runtime, not from this package.
• Kestrel: HTTP/1 request smuggling (CVE-2026-88092) and HTTP/2 header handling (CVE-2026-70188), both critical.
• Request parsing: denial-of-service fixes for form and multipart parsing (CVE-2026-70181, CVE-2026-70196), which IdentityServer's protocol endpoints use for unauthenticated form posts.
• ASP.NET Core Identity: password reset and confirmation emails now go to the user's stored address (CVE-2026-70175). If your login UI implements its own reset flow, check that it does the same.

See Microsoft's .NET security announcements for the full list.

What's changed

• Dependencies: the minimum versions of the ASP.NET Core and Microsoft.IdentityModel dependencies are raised to the October 2026 patched releases.
• Access token validation: a JWT access token that has a sub claim but no resolvable client is now rejected with invalid_token, instead of throwing a NullReferenceException during user activity validation. Tokens without a sub claim, including custom JWTs issued without a client, are unaffected.

Upgrade notes

None.

Full Changelog: is-8.0.9...is-8.0.10

This release moves IdentityServer's dependencies onto the .NET October 2026 security updates, and fixes an exception during access token validation.

Update your .NET runtime

Most of the October 2026 .NET vulnerabilities are in the ASP.NET Core shared framework, so upgrading IdentityServer doesn't fix them. Update every IdentityServer host and container image to the October 2026 .NET runtime for the .NET version you run. For IdentityServer, the most important fixes are:

• Kestrel: HTTP/1 request smuggling (CVE-2026-88092) and HTTP/2 header handling (CVE-2026-70188), both critical.
• Request parsing: denial-of-service fixes for form and multipart parsing (CVE-2026-70181, CVE-2026-70196), which IdentityServer's protocol endpoints use for unauthenticated form posts.
• ASP.NET Core Identity: password reset and confirmation emails now go to the user's stored address (CVE-2026-70175). If your login UI implements its own reset flow, check that it does the same.

See Microsoft's .NET security announcements for the full list.

What's changed

• Dependencies: the minimum versions of the ASP.NET Core dependencies are raised to the October 2026 patched releases.
• Access token validation: a JWT access token that has a sub claim but no resolvable client is now rejected with invalid_token, instead of throwing during user activity validation. Tokens with neither sub nor client_id, and valid tokens with a client, are validated as before.

Upgrade notes

None.

Full Changelog: is-7.4.13...is-7.4.14

Duende.BFF 4.3.2

This release moves BFF's dependencies onto the .NET October 2026 security updates. BFF's own code hasn't changed.

Blazor WebAssembly (CVE-2026-70183)

Microsoft fixed a vulnerability in Blazor's AuthorizeRouteView, which could use a stale authorization result after navigation. Blazor WebAssembly apps load Microsoft.AspNetCore.Components.Authorization from the NuGet package, not from the server's runtime, so updating the runtime on your servers doesn't fix it.

Duende.BFF.Blazor.Client 4.3.2 now requires the patched version of that package, so upgrading BFF picks up the fix for you. You can also reference the patched Microsoft.AspNetCore.Components.Authorization directly in your WebAssembly client project.

Update the .NET runtime on your hosts

Most of the October 2026 .NET vulnerabilities are in the ASP.NET Core shared framework, including critical Kestrel fixes for HTTP/1 request smuggling (CVE-2026-88092) and HTTP/2 header handling (CVE-2026-70188). Your app uses the shared framework installed on the host or in the container base image, so upgrading the BFF packages doesn't fix these. Update your hosts and container images to the October 2026 .NET runtime.

Developers working on Blazor WebAssembly apps should also update their .NET SDK, which fixes the WebAssembly debug proxy and dev server vulnerabilities (CVE-2026-102870, CVE-2026-96230).

Breaking changes

None.

Full Changelog: bff-4.3.1...bff-4.3.2

Duende.BFF 3.1.2

This release moves BFF's dependencies onto the .NET October 2026 security updates. BFF's own code hasn't changed.

Blazor WebAssembly (CVE-2026-70183)

Microsoft fixed a vulnerability in Blazor's AuthorizeRouteView, which could use a stale authorization result after navigation. Blazor WebAssembly apps load Microsoft.AspNetCore.Components.Authorization from the NuGet package, not from the server's runtime, so updating the runtime on your servers doesn't fix it.

Duende.BFF.Blazor.Client 3.1.2 now requires the patched version of that package for each target framework, so upgrading BFF picks up the fix for you. You can also reference the patched Microsoft.AspNetCore.Components.Authorization directly in your WebAssembly client project.

Update the .NET runtime on your hosts

Most of the October 2026 .NET vulnerabilities are in the ASP.NET Core shared framework, including critical Kestrel fixes for HTTP/1 request smuggling (CVE-2026-88092) and HTTP/2 header handling (CVE-2026-70188). Your app uses the shared framework installed on the host or in the container base image, so upgrading the BFF packages doesn't fix these. Update your hosts and container images to the October 2026 .NET runtime for the .NET version you run.

Developers working on Blazor WebAssembly apps should also update their .NET SDK, which fixes the WebAssembly debug proxy and dev server vulnerabilities (CVE-2026-102870, CVE-2026-96230).

Breaking changes

None.

Full Changelog: bff-3.1.1...bff-3.1.2

Duende.BFF 4.3.1

This is a security patch release for the 4.x line. It fixes two vulnerabilities in Duende.BFF.Yarp. We recommend that all users of 4.x upgrade.

Both fixes change default behavior. Read Breaking changes below before you upgrade.

The same fixes are released in 4.3.1, 4.2.1, 4.1.3 and 4.0.4.

Security fixes

• Remote APIs on dynamic frontends now enforce the anti-forgery header (GHSA-4j63-5v5f-xcc4). Remote APIs configured on a dynamic frontend (with WithRemoteApis or with Frontends:<name>:RemoteApis in configuration) were proxied with the user's access token, but the BFF didn't check for the anti-forgery header (X-CSRF: 1). A cross-site page could therefore make state-changing calls to the backend on behalf of a logged-in user. The BFF now checks the header on these routes before it attaches the access token. Requests without the header get 401 Unauthorized, and the BFF logs a warning. The check respects BffOptions.DisableAntiForgeryCheck. MapRemoteBffApiEndpoint, local BFF APIs and YARP routes were already protected and aren't affected.
• The YARP integration no longer forwards the Cookie header (GHSA-vvg7-p7jw-8qr3). Routes proxied through the BFF's YARP integration (AddYarpConfig, or AddReverseProxy().AddBffExtensions()) forwarded the incoming Cookie header to the remote API. That header includes the BFF session cookie, which was sent along with the access token. The BFF now removes the Cookie header from requests on all YARP routes, as MapRemoteBffApiEndpoint already did.

Breaking changes

• Remote API calls on dynamic frontends need the X-CSRF: 1 header. Make sure your frontend sends it on every call to a remote API configured on a dynamic frontend. Calls without it now return 401.

• YARP routes no longer forward cookies to remote APIs. If an upstream API needs cookies from the browser, you can turn this off for the whole application with the new BffOptions.RemoveCookieHeaderFromYarpRequests option:

  builder.Services.AddBff(options =>
  {
      options.RemoveCookieHeaderFromYarpRequests = false;
  });

  With the option set to false, YARP forwards cookies as before. You can then control cookie forwarding per route with standard YARP transforms, for example RequestHeaderRemove: Cookie. Only do this for upstream APIs you trust with the BFF session cookie.