Changelog for Ory Polis OEL
v26.3.6
Harden OIDC discovery URL fetching against SSRF
Creating or updating an OIDC SSO connection with an oidcDiscoveryUrl now validates the fetch target, and the value is
re-validated whenever it is fetched during an authorize or callback flow.
Previously the discovery URL was stored verbatim with no scheme, host or address validation and fetched on every authorize and callback. A caller with an SSO setup link or the deployment API key could point it at an internal address — such as the cloud instance metadata service or an in-cluster service — and read a reachability and response oracle from the resulting SSO trace and error redirect.
The discovery URL now must be an HTTPS URL that does not resolve to a non-public address (loopback, link-local, carrier-grade NAT, private, unique-local, reserved and unspecified ranges for both IPv4 and IPv6, and IPv4-mapped IPv6 literals). Every outbound OIDC request — discovery, token, userinfo and JWKS — is validated at connection time, so a hostname that resolves to an internal address, or one that changes its answer between validation and the request (DNS rebinding), is blocked.
The localhost hostname is now blocked by default, so a connection owner cannot reach services on the loopback interface of the
host or pod. Local development against an IdP on localhost is enabled automatically in a Node development environment, or
explicitly by setting POLIS_ALLOW_LOCALHOST_OUTBOUND=true.
The in-cluster federation tunnel — which rewrites a <slug>.projects.oryapis:8080 discovery URL to the internal hydra-public
service — keeps working unchanged; its rewrite target is a fixed, code-controlled in-cluster service, never taken from the
request. A self-hosted deployment that does not use Ory federation can turn the tunnel off with
POLIS_DISABLE_INTERNAL_ORY_FEDERATION=true, after which a *.projects.oryapis discovery URL is validated like any other host.
Upgrade impact
Because the discovery URL is re-validated on every authorize and callback, an existing OIDC connection whose discovery, token,
userinfo or JWKS endpoint is plain HTTP, localhost, or a private, loopback, link-local or other non-public address will start
failing those flows immediately after upgrading. On Ory Network this is not expected — providers are public HTTPS hosts.
Self-hosted (OEL/OSS) deployments should audit existing OIDC connections before upgrading and re-point any such connection at a
public HTTPS endpoint.
For a self-hosted deployment whose identity provider legitimately runs on an internal network, set
POLIS_ALLOW_PRIVATE_IP_OUTBOUND=true to allow HTTPS fetches to RFC1918 and IPv6 unique-local addresses. The opt-in is narrow:
HTTPS is still required, and link-local (including the cloud metadata address), loopback, carrier-grade NAT and reserved ranges
stay blocked. An IdP on the loopback interface uses POLIS_ALLOW_LOCALHOST_OUTBOUND=true instead.
This path is not exposed through the Ory Network gateway.
Harden SAML metadata URL fetching against SSRF
Creating or updating a SAML SSO connection with a metadataUrl now validates the fetch target against a strict allow list before
and during the request.
The previous check only rejected RFC1918 private IPv4 literals and IPv6 unique-local literals. It let through loopback, link-local
(including the cloud metadata address 169.254.169.254), carrier-grade NAT, reserved and unspecified addresses, every IPv6
literal, and every DNS hostname, and the fetch followed HTTP redirects without re-validating the target. A caller with an SSO
setup link or the SSO API key could use this to read internal endpoints such as the cloud instance metadata service.
The fetch now requires an HTTPS URL, resolves the hostname and rejects any address that is not a public unicast address (covering loopback, link-local, carrier-grade NAT, private, unique-local, reserved and unspecified ranges for both IPv4 and IPv6, and IPv4-mapped IPv6 literals). Resolution happens at connection time, so a hostname that resolves to an internal address — or one that changes its answer between validation and the request (DNS rebinding) — is blocked. Redirects are no longer followed, so a public host cannot redirect the request into an internal address. Unparseable input fails closed.
The localhost hostname is blocked by default so a connection owner cannot reach services on the loopback interface of the host
or pod. Local development against an IdP on localhost is enabled automatically in a Node development environment, or
explicitly by setting POLIS_ALLOW_LOCALHOST_OUTBOUND=true.
Upgrade impact
The previous check allowed localhost and every non-RFC1918 address, so a SAML connection configured with a metadataUrl over
plain HTTP, on localhost, or on a private, loopback or link-local address may now be rejected when its metadata is fetched or
refreshed. On Ory Network this is not expected. Self- hosted (OEL/OSS) deployments should audit existing SAML connections before
upgrading and re-point any such metadataUrl at a public HTTPS endpoint.
For a self-hosted identity provider on an internal network, set POLIS_ALLOW_PRIVATE_IP_OUTBOUND=true to allow HTTPS fetches to
RFC1918 and IPv6 unique-local addresses; HTTPS is still required and link-local (including the cloud metadata address), loopback,
carrier-grade NAT and reserved ranges stay blocked. An IdP on the loopback interface uses POLIS_ALLOW_LOCALHOST_OUTBOUND=true
instead.
This path is not exposed through the Ory Network gateway.
Add YugabyteDB support to Ory Polis
Ory Polis can now use YugabyteDB as its backing database. YugabyteDB is PostgreSQL wire-compatible, so it reuses the existing PostgreSQL driver and needs no additional dependencies. This gives self-hosted and enterprise deployments a distributed, horizontally scalable storage option alongside the existing engines (PostgreSQL, MySQL, MariaDB, Microsoft SQL Server, SQLite, CockroachDB, MongoDB, Redis, PlanetScale, and DynamoDB).
Configuration
Select YugabyteDB by setting the SQL engine and the yugabytedb type, then point the connection URL at your YugabyteDB YSQL
endpoint (default port 5433):
DB_ENGINE=sql
DB_TYPE=yugabytedb
DB_URL=postgresql://yugabyte@localhost:5433/yugabyte
Fix cross-tenant admin takeover through SAML admin-portal login
The Polis Admin Portal SAML login now accepts a login only when it went through the Admin Portal's own SSO connection. Previously
both the IdP-initiated (boxyhq-saml-idplogin) and SP-initiated (boxyhq-saml) flows trusted a login completed against any
tenant's SSO connection in the deployment. An attacker could complete a SAML login against a connection they control and receive
an Admin Portal session with read and write access to every tenant's SSO connections and secrets.
The fix pins the resolved connection's tenant and product to the Admin Portal defaults (_jackson_boxyhq /
_jackson_admin_portal) and rejects anything else — in the IdP-initiated provider's authorize() and in the sign-in callback for
the SP-initiated provider.
This affects self-hosted Polis (OSS) and the polis-oel chart. It is not reachable on the Ory Network, where the gateway does not
route /api/auth/** to Polis.
Fix cross-tenant data leak in concurrent SCIM directory-sync requests
SCIM directory-sync requests could leak users and groups across tenants when two requests for different directories were processed at the same time.
The request handler bound the directory's tenant and product onto a single, process-wide store instance that every request shared.
Because that binding was read again at each database call after intervening awaits, a second request for a different directory
could overwrite it mid-flight. A user or group created for directory A could then be written into directory B's namespace:
directory B's directory-sync APIs would return directory A's data, while directory A's own read returned nothing even though it
received 201 Created.
The handler now binds a request-scoped copy of the store per request, so concurrent requests can never observe one another's
tenant and product. The directory-sync admin and management API routes (/api/v1/dsync/*, /api/admin/directory-sync/*) were
bound the same way and are migrated too, which closes a related window where a concurrent read could redirect a "delete all
webhook events" request to another tenant's namespace. This affects self-hosted Polis; SCIM is not routed through the Ory Network
gateway.
Reject SAML responses that declare a DTD and stop leaking parser errors
The SAML assertion consumer service (POST /api/oauth/saml) parsed the base64-decoded SAMLResponse with document type
definition (DTD) processing enabled. Because a SAML response never legitimately contains a DTD, this exposed the XML parser to
XXE-class attacks: a crafted DOCTYPE with a SYSTEM entity produced different parser errors depending on whether a referenced
path existed, giving an unauthenticated caller a file-existence oracle. Internal parser error text was also returned to the caller
through the polis_error cookie, which made the differential observable.
Polis now rejects any SAML response that declares a DOCTYPE/DTD before it reaches the parser, and returns a generic error to the
client. Internal error detail is logged server-side only and is no longer disclosed to the caller: the polis_error cookie
returns a generic message for server errors, and the OAuth error_description returned on the redirect no longer includes raw
parser or exception text. Standard OAuth error codes and OIDC provider error descriptions are still forwarded.
Reject invalid magic-link tokens in the Polis admin portal
The admin-portal magic-link (email) sign-in accepted any token value. The next-auth adapter looked up the stored verification
token by email but returned the record without checking that the presented token matched it. Because next-auth treats any non-null
adapter result as valid and the portal grants the admin role to every address, an unauthenticated attacker could complete the
email callback for any address — including an administrator's — with an arbitrary token and receive an authenticated admin
session. This required magic-link login to be enabled (NEXTAUTH_ACL set together with an SMTP host); a default install with
NEXTAUTH_ACL unset was not affected.
Polis now returns the verification token only when the presented value matches the stored one, and consumes it on that single successful use. Non-matching or missing tokens are rejected, closing the bypass (GHSA-j4rr-hrm4-hx4j).
Validate SAML SingleLogout URLs to prevent stored XSS and open redirect
SAML connection metadata is now scheme-checked on its SingleLogout (SLO) bindings, not just its login (SSO) bindings. Previously,
the SingleLogoutService Location from an identity provider's metadata was stored without validation and later written into the
auto-submitting form and redirect served by the unauthenticated /api/logout endpoint. A javascript: URL placed in that field
executed in the browser of anyone who opened the tenant's logout link (stored cross-site scripting), and a crafted redirect
binding could send that visitor to an arbitrary host (open redirect).
Creating or updating a SAML connection now rejects any SLO Location that does not use an http or https scheme, matching the
check already applied to SSO bindings. The localhost allowance in that check now also requires an http/https scheme:
previously it inspected only the host, so a javascript://localhost/... URL parsed with hostname localhost and slipped through.
As defense in depth, the logout request builder re-checks the SLO scheme at the point of use, so a connection that already carries
a malicious SLO URL can never emit it into the /api/logout form or redirect. Existing connections that carry a malicious SLO URL
should still be recreated or updated so the stored value is revalidated.
Validate the post-logout redirect URL in SAML Single Logout
The unauthenticated GET /api/logout endpoint accepted a redirectUrl query parameter and, after the identity provider completed
Single Logout, redirected the browser to it without checking it against the connection's configured redirect URL allow-list. An
attacker could send a victim a logout link with an arbitrary redirectUrl and have Polis redirect them to an external origin
(open redirect, CWE-601).
Polis now validates redirectUrl against the connection's allow-list when the logout request is created and rejects a disallowed
or malformed value with 403 Redirect URL is not allowed. — the same check the OAuth authorize flow applies to redirect_uri. If
a stored value no longer matches the connection resolved from the logout response, the callback falls back to the connection's
defaultRedirectUrl.
This affects self-hosted Polis (OSS and OEL). The Ory Network gateway does not expose /saml/api/logout and is not affected.
26.3.5
This version contains only minor changes and improvements such as dependency updates.
26.3.4
This version contains only minor changes and improvements such as dependency updates.
26.3.3
This version contains only minor changes and improvements such as dependency updates.
26.3.2
This version contains only minor changes and improvements such as dependency updates.
v26.3.1
Serve Polis over HTTPS with a built-in TLS sidecar
The Polis Helm chart can now terminate TLS in front of Polis without an external ingress. Set tlsSidecar.enabled: true and point
tlsSidecar.tls.secretName at an existing Secret that holds tls.crt and tls.key (managed by you or cert-manager):
tlsSidecar:
enabled: true
tls:
secretName: polis-tls
The chart then runs an nginx sidecar that terminates HTTPS and proxies to Polis in the same pod. The Service keeps the same port
and name; when the sidecar is enabled the Service routes to it (HTTPS) instead of the plain-HTTP Polis listener, so plain HTTP is
no longer served. The sidecar image defaults to docker.io/nginxinc/nginx-unprivileged:stable and is overridable via
tlsSidecar.image.
The feature is off by default, so existing deployments are unchanged and continue to serve plain HTTP.
For advanced cases, the chart also exposes deployment.extraContainers, deployment.extraVolumes,
deployment.extraVolumeMounts, and deployment.extraEnvs to add arbitrary sidecars or volumes.
26.3.0
This version contains only minor changes and improvements such as dependency updates.
v26.2.22
Fix cross-tenant identity provider selection via idp_hint in Polis
The idp_hint parameter on the SAML Identity Federation and SSO endpoints selected an upstream identity provider connection by id
without checking that the connection belonged to the requesting tenant and product. On a multi-tenant deployment, a co-tenant
could supply the id of a connection in their own tenant as idp_hint for another tenant's federation app, routing the login to an
identity provider they control and obtaining a Polis-signed assertion audienced to the victim's downstream service provider.
Polis now scopes the hinted connection to the requesting flow. A hint is accepted only when the connection belongs to the
requested tenant and product, to one of a multi-tenant federation app's tenants, or — for IdP-initiated SSO — to the identity
provider that issued the response. Out-of-scope hints are rejected with 403. The upstream-response callback re-checks that the
selected connection is within the session's tenant scope.
In-scope use of idp_hint, including for multi-tenant federation apps, is unchanged.
26.2.21
This version contains only minor changes and improvements such as dependency updates.
26.2.20
This version contains only minor changes and improvements such as dependency updates.
v26.2.19
Optionally return group members in the SCIM Groups API
The SCIM Groups API can now return a group's members. Reading a group with GET /api/scim/v2.0/{directoryId}/Groups/{groupId} or
listing groups with GET /api/scim/v2.0/{directoryId}/Groups returns an empty members list by default. Add
includeMembers=true to the request to include the current members instead.
Members stay omitted by default to avoid loading very large memberships into a single response. When includeMembers=true is set
and a group has more than 500 members, the request returns a 400 error and directs you to the paginated group members endpoint,
rather than returning a partial or oversized response.
The 500-member limit is configurable. Set the DSYNC_MAX_INLINE_GROUP_MEMBERS environment variable (or the
dsync.maxInlineGroupMembers option when embedding the library) to raise or lower it.
v26.2.18
Configurable retention for SCIM webhook event logs
You can now set how long SCIM (directory sync) webhook event logs are kept, using the DSYNC_WEBHOOK_LOGS_TTL environment
variable. Set it to a duration such as 720h or 30d.
If you leave the variable unset, logs keep the existing 7-day retention. Set it to an empty string to keep logs indefinitely. An unrecognized value falls back to the 7-day default and logs a warning, so a typo never disables retention.
26.2.17
This version contains only minor changes and improvements such as dependency updates.
26.2.16
This version contains only minor changes and improvements such as dependency updates.
26.2.15
This version contains only minor changes and improvements such as dependency updates.
26.2.14
This version contains only minor changes and improvements such as dependency updates.
26.2.13
This version contains only minor changes and improvements such as dependency updates.
26.2.12
This version contains only minor changes and improvements such as dependency updates.
26.2.11
This version contains only minor changes and improvements such as dependency updates.
26.2.10
This version contains only minor changes and improvements such as dependency updates.
v26.2.9
Patch security vulnerabilities in dependencies
Bump several dependencies to patched versions to address security advisories reported by Dependabot.
Notable updates:
github.com/jackc/pgx/v5tov5.9.2across all Go modules (SQL injection via placeholder confusion in dollar-quoted string literals).github.com/moby/spdystreamtov0.5.1(denial of service on container runtime interface).go.opentelemetry.io/oteltov1.41.0(remote DoS amplification via multi-value baggage header).postcssto>=8.5.10(XSS via unescaped</style>in CSS stringify output).uuidto>=14.0.0(missing buffer bounds check in v3/v5/v6 generators).@xmldom/xmldomto>=0.8.13(XML node injection and uncontrolled recursion).axios,follow-redirects,lodash,picomatch,brace-expansion,serialize-javascript,yaml,file-type,i18next-fs-backend,@nestjs/coreto their respective patched versions.
26.2.8
This version contains only minor changes and improvements such as dependency updates.
26.2.7
This version contains only minor changes and improvements such as dependency updates.
26.2.6
This version contains only minor changes and improvements such as dependency updates.
26.2.5
This version contains only minor changes and improvements such as dependency updates.
26.2.4
This version contains only minor changes and improvements such as dependency updates.
26.2.3
This version contains only minor changes and improvements such as dependency updates.
26.2.2
This version contains only minor changes and improvements such as dependency updates.
26.2.1
This version contains only minor changes and improvements such as dependency updates.
26.2.0
This version contains only minor changes and improvements such as dependency updates.
v26.1.18
Fixed a security issue
This release includes a fix for a security issue. Additional details will be shared with customers directly.
26.1.17
This version contains only minor changes and improvements such as dependency updates.
26.1.16
This version contains only minor changes and improvements such as dependency updates.
26.1.15
This version contains only minor changes and improvements such as dependency updates.
26.1.14
This version contains only minor changes and improvements such as dependency updates.
26.1.13
This version contains only minor changes and improvements such as dependency updates.
26.1.12
This version contains only minor changes and improvements such as dependency updates.
26.1.11
This version contains only minor changes and improvements such as dependency updates.
26.1.10
This version contains only minor changes and improvements such as dependency updates.
26.1.9
This version contains only minor changes and improvements such as dependency updates.
26.1.8
This version contains only minor changes and improvements such as dependency updates.
v26.1.7
Switched to better-sqlite3
We have replaced the unmaintained sqlite3 dependency with better-sqlite3 to ensure ongoing maintenance and stability.
Breaking changes
Turso is no longer supported due to the removal of the sqlite3 library.
Identity Federation: Support for including OIDC tokens in SAML responses
When creating an Identity Federation app, you can now include OIDC tokens in the SAML Response by setting the
includeOidcTokensInAssertion attribute. This allows downstream applications to access the original OIDC tokens issued by the
provider when using SAML federation.
26.1.6
This version contains only minor changes and improvements such as dependency updates.
26.1.5
This version contains only minor changes and improvements such as dependency updates.
26.1.4
This version contains only minor changes and improvements such as dependency updates.
26.1.3
This version contains only minor changes and improvements such as dependency updates.
v26.1.2
Identity Federation: SAML Response expiry is now configurable
When creating an Identity Federation app, you can now control how long a SAML Response remains valid by setting the ttlInMinutes attribute. The default expiry remains 10 minutes.
26.1.1
This version contains only minor changes and improvements such as dependency updates.
26.1.0
This version contains only minor changes and improvements such as dependency updates.
25.4.12
This version contains only minor changes and improvements such as dependency updates.
25.4.11
This version contains only minor changes and improvements such as dependency updates.
25.4.10
This version contains only minor changes and improvements such as dependency updates.
25.4.9
This version contains only minor changes and improvements such as dependency updates.
25.4.8
This version contains only minor changes and improvements such as dependency updates.
25.4.7
This version contains only minor changes and improvements such as dependency updates.
25.4.6
This version contains only minor changes and improvements such as dependency updates.
25.4.5
This version contains only minor changes and improvements such as dependency updates.
25.4.4
This version contains only minor changes and improvements such as dependency updates.
25.4.3
This version contains only minor changes and improvements such as dependency updates.
25.4.2
This version contains only minor changes and improvements such as dependency updates.
25.4.1
This version contains only minor changes and improvements such as dependency updates.
25.4.0
This version contains only minor changes and improvements such as dependency updates.
25.3.9
This version contains only minor changes and improvements such as dependency updates.
25.3.8
This version contains only minor changes and improvements such as dependency updates.
25.3.7
This version contains only minor changes and improvements such as dependency updates.
25.3.6
This version contains only minor changes and improvements such as dependency updates.
25.3.5
This version contains only minor changes and improvements such as dependency updates.
25.3.4
This version contains only minor changes and improvements such as dependency updates.
25.3.3
This version contains only minor changes and improvements such as dependency updates.
2025-07-28
Tag: c2370d3c35c060459b46f1c77b2241a23a1b04eb
No specific upgrade steps are required for this release. The Ory Polis OEL image is now available in the Ory Enterprise Docker Registry.