arrow-left Back to Announcements
DATE:
AUTHOR:
Ory Team
Ory Network Ory Hydra Ory Kratos Ory Keto Ory Oathkeeper Ory Enterprise License

Ory Network, Ory Hydra, Ory Kratos, Ory Keto, Ory Oathkeeper v26.3.2 released

DATE:
AUTHOR: Ory Team

Ory Network

Enforce a DNS-label boundary on wildcard return URLs and CORS origins

A wildcard in a return URL or CORS origin is now honored only when the * is confined to a subdomain label and the host part after it is a registrable domain (an eTLD+1, such as https://*.example.com or https://*.example.co.uk). The wildcard then matches only hosts under that one customer-owned domain.

These forms are no longer honored, because each can match an attacker-registrable host:

  • dot-less, e.g. https://*foo.com (matches https://evilfoo.com);

  • public-suffix base, e.g. https://*.com, https://*.co.uk, https://*.vercel.app;

  • trailing or bare, e.g. https://www.example.*, https://*.

Only the host is checked: wildcards in the URL path are unaffected. Exact origins and the catch-all * are unchanged.

What enforces it

  • Return URLs: unsafe wildcard allowed_return_urls entries never match. In the Console and API, saving a project rejects a newly added unsafe wildcard with an error pointing to the https://*.example.com form; an already-stored one is dropped so the project can still save other changes.

  • CORS origins: matching enforces the same boundary at request time. Saving a custom domain rejects an unsafe wildcard origin at authoring time, and a new custom domain rejects unsafe wildcards even for projects with the allow_insecure_origins entitlement.

Breaking changes

Replace any unsafe wildcard with the labelled https://*.example.com form, or list exact origins.

Projects granted the allow_insecure_origins entitlement (issued by Ory for a time-boxed migration window) keep honoring their existing unbounded wildcards — return URLs, CORS origins, and existing custom domains — until they migrate to the labelled form. Creating a new custom domain always requires the labelled form.

Console shows API error details on failed actions

The self-hosted Ory Console now shows the exact error returned by the API when an action fails, instead of a generic failure message. This covers saving OAuth2 clients (for example a malformed redirect URI or one containing a fragment), resetting passwords, creating and removing permission relationships, editing permission namespaces, saving the OPL configuration, and terminating sessions. Previously a rejected change could look like a silent save failure.

This is now available on Ory Network, for the Ory Enterprise License, and will be part of the next Ory Open Source release.

Ory Hydra

Enforce a DNS-label boundary on wildcard return URLs and CORS origins

A wildcard in a return URL or CORS origin is now honored only when the * is confined to a subdomain label and the host part after it is a registrable domain (an eTLD+1, such as https://*.example.com or https://*.example.co.uk). The wildcard then matches only hosts under that one customer-owned domain.

These forms are no longer honored, because each can match an attacker-registrable host:

  • dot-less, e.g. https://*foo.com (matches https://evilfoo.com);

  • public-suffix base, e.g. https://*.com, https://*.co.uk, https://*.vercel.app;

  • trailing or bare, e.g. https://www.example.*, https://*.

Only the host is checked: wildcards in the URL path are unaffected. Exact origins and the catch-all * are unchanged.

What enforces it

  • Return URLs: unsafe wildcard allowed_return_urls entries never match. In the Console and API, saving a project rejects a newly added unsafe wildcard with an error pointing to the https://*.example.com form; an already-stored one is dropped so the project can still save other changes.

  • CORS origins: matching enforces the same boundary at request time. Saving a custom domain rejects an unsafe wildcard origin at authoring time, and a new custom domain rejects unsafe wildcards even for projects with the allow_insecure_origins entitlement.

Breaking changes

Replace any unsafe wildcard with the labelled https://*.example.com form, or list exact origins.

Projects granted the allow_insecure_origins entitlement (issued by Ory for a time-boxed migration window) keep honoring their existing unbounded wildcards — return URLs, CORS origins, and existing custom domains — until they migrate to the labelled form. Creating a new custom domain always requires the labelled form.

Enforce a DNS-label boundary on wildcard return URLs and CORS origins

A wildcard in a return URL or CORS origin is now honored only when the * is confined to a subdomain label and the host part after it is a registrable domain (an eTLD+1, such as https://*.example.com or https://*.example.co.uk). The wildcard then matches only hosts under that one customer-owned domain.

These forms are no longer honored, because each can match an attacker-registrable host:

  • dot-less, e.g. https://*foo.com (matches https://evilfoo.com);

  • public-suffix base, e.g. https://*.com, https://*.co.uk, https://*.vercel.app;

  • trailing or bare, e.g. https://www.example.*, https://*.

Only the host is checked: wildcards in the URL path are unaffected. Exact origins, the catch-all *, and Hydra's https://* ("all hosts for a scheme") are unchanged.

What enforces it

  • Return URLs: Kratos drops unsafe wildcard allowed_return_urls entries when it loads its config, and they never match.

  • CORS origins: matching across Kratos, Hydra, Keto, Oathkeeper, and Talos enforces the same boundary at request time.

Breaking changes

Replace any unsafe wildcard with the labelled https://*.example.com form, or list exact origins. Update serve.*.cors.allowed_origins and Kratos allowed_return_urls before upgrading; otherwise cross-origin requests and post-flow redirects from those hosts will be blocked.

This is now available on Ory Network, for the Ory Enterprise License, and will be part of the next Ory Open Source release.

Ory Kratos

Enforce a DNS-label boundary on wildcard return URLs and CORS origins

A wildcard in a return URL or CORS origin is now honored only when the * is confined to a subdomain label and the host part after it is a registrable domain (an eTLD+1, such as https://*.example.com or https://*.example.co.uk). The wildcard then matches only hosts under that one customer-owned domain.

These forms are no longer honored, because each can match an attacker-registrable host:

  • dot-less, e.g. https://*foo.com (matches https://evilfoo.com);

  • public-suffix base, e.g. https://*.com, https://*.co.uk, https://*.vercel.app;

  • trailing or bare, e.g. https://www.example.*, https://*.

Only the host is checked: wildcards in the URL path are unaffected. Exact origins and the catch-all * are unchanged.

What enforces it

  • Return URLs: unsafe wildcard allowed_return_urls entries never match. In the Console and API, saving a project rejects a newly added unsafe wildcard with an error pointing to the https://*.example.com form; an already-stored one is dropped so the project can still save other changes.

  • CORS origins: matching enforces the same boundary at request time. Saving a custom domain rejects an unsafe wildcard origin at authoring time, and a new custom domain rejects unsafe wildcards even for projects with the allow_insecure_origins entitlement.

Breaking changes

Replace any unsafe wildcard with the labelled https://*.example.com form, or list exact origins.

Projects granted the allow_insecure_origins entitlement (issued by Ory for a time-boxed migration window) keep honoring their existing unbounded wildcards — return URLs, CORS origins, and existing custom domains — until they migrate to the labelled form. Creating a new custom domain always requires the labelled form.

Enforce a DNS-label boundary on wildcard return URLs and CORS origins

A wildcard in a return URL or CORS origin is now honored only when the * is confined to a subdomain label and the host part after it is a registrable domain (an eTLD+1, such as https://*.example.com or https://*.example.co.uk). The wildcard then matches only hosts under that one customer-owned domain.

These forms are no longer honored, because each can match an attacker-registrable host:

  • dot-less, e.g. https://*foo.com (matches https://evilfoo.com);

  • public-suffix base, e.g. https://*.com, https://*.co.uk, https://*.vercel.app;

  • trailing or bare, e.g. https://www.example.*, https://*.

Only the host is checked: wildcards in the URL path are unaffected. Exact origins, the catch-all *, and Hydra's https://* ("all hosts for a scheme") are unchanged.

What enforces it

  • Return URLs: Kratos drops unsafe wildcard allowed_return_urls entries when it loads its config, and they never match.

  • CORS origins: matching across Kratos, Hydra, Keto, Oathkeeper, and Talos enforces the same boundary at request time.

Breaking changes

Replace any unsafe wildcard with the labelled https://*.example.com form, or list exact origins. Update serve.*.cors.allowed_origins and Kratos allowed_return_urls before upgrading; otherwise cross-origin requests and post-flow redirects from those hosts will be blocked.

First-factor device login with an app PIN

Enrolled mobile devices can now complete a full AAL2 login in one step using an app PIN or platform biometrics, without a password or SMS code. The PIN is never transmitted or stored: it unlocks an on-device secret, and the server verifies a proof bound to the device's hardware-backed key. After the configurable number of wrong PIN attempts (default 5) the key locks and the user must recover through the fallback login.

New selfservice.methods.deviceauthn.config options:

  • first_factor — enable first-factor device login (default false).

  • pin_max_attempts — number of wrong PIN attempts before the key locks (default 5).

  • ios_biometric_first_factor — allow platform biometrics as a first-factor credential on iOS (default false). iOS needs this explicit opt-in because App Attest cannot prove that the key is biometric-gated; Android platform keys are attestation-verified and need no opt-in.

Breaking change: device keys enrolled before this release carry no user_verification and can no longer authenticate. Step-up login rejects them with a dedicated "enroll your device again" message, and they no longer count as active second factors, so affected accounts keep their first-factor login and can re-enroll the device in settings.

Faster conflict detection during OIDC login and registration

Ory Kratos now runs identity conflict lookups concurrently when checking whether an OIDC login or registration matches an existing account. Previously each credential identifier, verifiable address, and recovery address was checked one after another; now Kratos checks all candidates at once with bounded concurrency. This cuts sign-in latency, especially in multi-region deployments where each lookup crosses regions.

This is now available on Ory Network, for the Ory Enterprise License, and will be part of the next Ory Open Source release.

Ory Keto

Enforce a DNS-label boundary on wildcard return URLs and CORS origins

A wildcard in a return URL or CORS origin is now honored only when the * is confined to a subdomain label and the host part after it is a registrable domain (an eTLD+1, such as https://*.example.com or https://*.example.co.uk). The wildcard then matches only hosts under that one customer-owned domain.

These forms are no longer honored, because each can match an attacker-registrable host:

  • dot-less, e.g. https://*foo.com (matches https://evilfoo.com);

  • public-suffix base, e.g. https://*.com, https://*.co.uk, https://*.vercel.app;

  • trailing or bare, e.g. https://www.example.*, https://*.

Only the host is checked: wildcards in the URL path are unaffected. Exact origins and the catch-all * are unchanged.

What enforces it

  • Return URLs: unsafe wildcard allowed_return_urls entries never match. In the Console and API, saving a project rejects a newly added unsafe wildcard with an error pointing to the https://*.example.com form; an already-stored one is dropped so the project can still save other changes.

  • CORS origins: matching enforces the same boundary at request time. Saving a custom domain rejects an unsafe wildcard origin at authoring time, and a new custom domain rejects unsafe wildcards even for projects with the allow_insecure_origins entitlement.

Breaking changes

Replace any unsafe wildcard with the labelled https://*.example.com form, or list exact origins.

Projects granted the allow_insecure_origins entitlement (issued by Ory for a time-boxed migration window) keep honoring their existing unbounded wildcards — return URLs, CORS origins, and existing custom domains — until they migrate to the labelled form. Creating a new custom domain always requires the labelled form.

Enforce a DNS-label boundary on wildcard return URLs and CORS origins

A wildcard in a return URL or CORS origin is now honored only when the * is confined to a subdomain label and the host part after it is a registrable domain (an eTLD+1, such as https://*.example.com or https://*.example.co.uk). The wildcard then matches only hosts under that one customer-owned domain.

These forms are no longer honored, because each can match an attacker-registrable host:

  • dot-less, e.g. https://*foo.com (matches https://evilfoo.com);

  • public-suffix base, e.g. https://*.com, https://*.co.uk, https://*.vercel.app;

  • trailing or bare, e.g. https://www.example.*, https://*.

Only the host is checked: wildcards in the URL path are unaffected. Exact origins, the catch-all *, and Hydra's https://* ("all hosts for a scheme") are unchanged.

What enforces it

  • Return URLs: Kratos drops unsafe wildcard allowed_return_urls entries when it loads its config, and they never match.

  • CORS origins: matching across Kratos, Hydra, Keto, Oathkeeper, and Talos enforces the same boundary at request time.

Breaking changes

Replace any unsafe wildcard with the labelled https://*.example.com form, or list exact origins. Update serve.*.cors.allowed_origins and Kratos allowed_return_urls before upgrading; otherwise cross-origin requests and post-flow redirects from those hosts will be blocked.

This is now available on Ory Network, for the Ory Enterprise License, and will be part of the next Ory Open Source release.

Ory Oathkeeper

Enforce a DNS-label boundary on wildcard return URLs and CORS origins

A wildcard in a return URL or CORS origin is now honored only when the * is confined to a subdomain label and the host part after it is a registrable domain (an eTLD+1, such as https://*.example.com or https://*.example.co.uk). The wildcard then matches only hosts under that one customer-owned domain.

These forms are no longer honored, because each can match an attacker-registrable host:

  • dot-less, e.g. https://*foo.com (matches https://evilfoo.com);

  • public-suffix base, e.g. https://*.com, https://*.co.uk, https://*.vercel.app;

  • trailing or bare, e.g. https://www.example.*, https://*.

Only the host is checked: wildcards in the URL path are unaffected. Exact origins and the catch-all * are unchanged.

What enforces it

  • Return URLs: unsafe wildcard allowed_return_urls entries never match. In the Console and API, saving a project rejects a newly added unsafe wildcard with an error pointing to the https://*.example.com form; an already-stored one is dropped so the project can still save other changes.

  • CORS origins: matching enforces the same boundary at request time. Saving a custom domain rejects an unsafe wildcard origin at authoring time, and a new custom domain rejects unsafe wildcards even for projects with the allow_insecure_origins entitlement.

Breaking changes

Replace any unsafe wildcard with the labelled https://*.example.com form, or list exact origins.

Projects granted the allow_insecure_origins entitlement (issued by Ory for a time-boxed migration window) keep honoring their existing unbounded wildcards — return URLs, CORS origins, and existing custom domains — until they migrate to the labelled form. Creating a new custom domain always requires the labelled form.

Enforce a DNS-label boundary on wildcard return URLs and CORS origins

A wildcard in a return URL or CORS origin is now honored only when the * is confined to a subdomain label and the host part after it is a registrable domain (an eTLD+1, such as https://*.example.com or https://*.example.co.uk). The wildcard then matches only hosts under that one customer-owned domain.

These forms are no longer honored, because each can match an attacker-registrable host:

  • dot-less, e.g. https://*foo.com (matches https://evilfoo.com);

  • public-suffix base, e.g. https://*.com, https://*.co.uk, https://*.vercel.app;

  • trailing or bare, e.g. https://www.example.*, https://*.

Only the host is checked: wildcards in the URL path are unaffected. Exact origins, the catch-all *, and Hydra's https://* ("all hosts for a scheme") are unchanged.

What enforces it

  • Return URLs: Kratos drops unsafe wildcard allowed_return_urls entries when it loads its config, and they never match.

  • CORS origins: matching across Kratos, Hydra, Keto, Oathkeeper, and Talos enforces the same boundary at request time.

Breaking changes

Replace any unsafe wildcard with the labelled https://*.example.com form, or list exact origins. Update serve.*.cors.allowed_origins and Kratos allowed_return_urls before upgrading; otherwise cross-origin requests and post-flow redirects from those hosts will be blocked.

This is now available on Ory Network, for the Ory Enterprise License, and will be part of the next Ory Open Source release.

Ory Polis, Ory Elements, and Ory Terraform

No significant changes in this release.

Powered by LaunchNotes