CVE-2026-82263: Logto OIDC SSO SSRF Vulnerability

CVE-2026-82263 Overview

CVE-2026-82263 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] affecting Logto through version 1.42.0. The flaw resides in the OpenID Connect (OIDC) Single Sign-On (SSO) connector creation endpoint, which fails to validate the issuer URL parameter before dispatching outbound HTTP requests. Tenant administrators holding Management API credentials can submit arbitrary internal URLs, forcing the Logto server to issue HTTP GET requests against private network services. Response content from those requests is reflected back through the API, exposing internal metadata endpoints, cloud provider instance metadata services, and other unreachable resources.

Critical Impact
Authenticated tenant administrators can pivot from the Management API into internal networks, reading sensitive responses from otherwise unreachable services and potentially harvesting cloud credentials from metadata endpoints.

Affected Products

Logto versions up to and including 1.42.0
Self-hosted Logto deployments exposing the Management API
Logto instances configured with OIDC SSO connectors

Discovery Timeline

2026-08-28 - CVE-2026-82263 published to NVD
2026-08-28 - Last updated in NVD database

Technical Details for CVE-2026-82263

Vulnerability Analysis

Logto is an open-source identity and access management platform that supports federated authentication through OIDC SSO connectors. When a tenant administrator creates or updates an OIDC SSO connector, Logto fetches the identity provider's OIDC discovery document from the supplied issuer URL. The connector logic located in packages/core/src/sso/OidcConnector/utils.ts performs an HTTP GET against the issuer without filtering destination hosts, IP address ranges, or address families.

Because the outbound fetch executes with the network reachability of the Logto server, an administrator can direct the request to loopback interfaces, RFC1918 private ranges, link-local addresses such as 169.254.169.254, or internal service hostnames. The response body is returned in the Management API response, converting the connector creation flow into a full-read SSRF primitive.

Root Cause

The root cause is missing validation of user-supplied URLs before invoking outbound HTTP clients. The OIDC connector utility resolves the issuer parameter and issues a fetch without checking whether the resolved address belongs to a special-use IANA range. IPv4-mapped IPv6 addresses and DNS-based bypass techniques are also unhandled.

Attack Vector

An attacker requires valid Management API credentials for a Logto tenant. The attacker submits a connector creation request specifying an issuer URL that points to an internal target such as a cloud instance metadata endpoint or an internal admin service. The Logto backend fetches the target URL over HTTPS or HTTP and returns the response payload in the API response, disclosing internal data.

typescript

// Patch: block SSRF in webhook and SSO outbound requests (#9501)
// Source: https://github.com/logto-io/logto/commit/16f4b2e732d5114ac98646c9370ec6ab61d6ed26

// packages/core/src/include.d/oidc-provider/lib-keep/helpers/fetch_request.d.ts
declare module 'oidc-provider/lib/helpers/fetch_request.js' {
  /**
   * Whether the address belongs to the IANA special-purpose address registries
   * (loopback, private-use, link-local, shared address space, ...).
   * IPv4-mapped IPv6 addresses are unwrapped and judged as IPv4.
   */
  export function isSpecialUseIP(address: string): boolean;
}

// packages/core/src/libraries/hook/utils.ts
import { ssrfProtectedFetch } from '#src/utils/outbound-request.js';
import { sign } from '#src/utils/sign.js';

The patch introduces isSpecialUseIP for address classification and routes outbound webhook and SSO fetches through ssrfProtectedFetch, which rejects requests that resolve to special-use address ranges.

Detection Methods for CVE-2026-82263

Indicators of Compromise

Management API calls to OIDC SSO connector creation or update endpoints containing issuer values that resolve to 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, or 169.254.0.0/16.
Outbound HTTP GET requests from the Logto server process targeting cloud metadata endpoints such as 169.254.169.254 or metadata.google.internal.
Unusually large or unexpected response bodies returned from OIDC connector configuration APIs.

Detection Strategies

Inspect Logto application and reverse-proxy logs for POST or PATCH requests to SSO connector endpoints containing internal hostnames or private IPs in the issuer field.
Correlate Management API activity with egress network flows from the Logto host to non-public destinations.
Alert on any Logto process connection attempts to link-local metadata IPs.

Monitoring Recommendations

Deploy egress filtering and log DNS resolutions from the Logto backend to identify lookups of internal-only hostnames.
Enable audit logging on the Management API and forward events to a centralized analytics platform for correlation.
Track version inventories to identify Logto instances running 1.42.0 or earlier.

How to Mitigate CVE-2026-82263

Immediate Actions Required

Upgrade Logto to a release containing commit 16f4b2e732d5114ac98646c9370ec6ab61d6ed26 or later, which introduces ssrfProtectedFetch for SSO and webhook requests.
Restrict Management API access to trusted administrative networks and rotate any Management API credentials that may have been exposed.
Review recent SSO connector creation and update events for suspicious issuer values.

Patch Information

The fix is delivered in the upstream commit logto-io/logto @ 16f4b2e via pull request #9501, which blocks SSRF in webhook and SSO outbound requests. The patch adds an isSpecialUseIP helper and wraps outbound fetches with an SSRF-aware client that rejects loopback, private-use, link-local, and shared address ranges. See the VulnCheck Advisory and Logto Issue #9465 for additional context.

Workarounds

Enforce network-layer egress controls that block the Logto backend from reaching cloud metadata services and internal management interfaces.
Limit tenant administrator provisioning and require multi-party approval for creating new SSO connectors until the patched version is deployed.
Place the Logto backend behind an outbound proxy that filters destinations by allow-list of federated identity provider domains.

bash

# Example iptables egress rule to block cloud metadata access from Logto host
iptables -A OUTPUT -m owner --uid-owner logto -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner logto -d 127.0.0.0/8 ! -o lo -j REJECT
iptables -A OUTPUT -m owner --uid-owner logto -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner logto -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner logto -d 192.168.0.0/16 -j REJECT