CVE-2026-56739: Logto SSRF Information Disclosure Vulnerability

CVE-2026-56739 Overview

CVE-2026-56739 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in Logto, an open-source authentication infrastructure for SaaS and AI applications. Prior to version 1.43.0, Logto fetches administrator-controlled outbound destinations without validating the target address. Webhook delivery logic in packages/core/src/libraries/hook/utils.ts can reach special-use and cloud metadata endpoints. Custom OAuth2 connectors can target an attacker-selected userInfoEndpoint and forward the OAuth access token in the Authorization header. OIDC connectors can fetch an attacker-selected jwksUri. The issue is fixed in Logto 1.43.0.

Critical Impact
An authenticated tenant administrator can coerce Logto to make outbound requests to internal services or cloud metadata endpoints, exposing internal data and upstream provider credentials.

Affected Products

Logto (open-source auth infrastructure) versions prior to 1.43.0
Deployments using webhook delivery via packages/core/src/libraries/hook/utils.ts
Deployments using custom OAuth2 or OIDC connectors

Discovery Timeline

2026-09-24 - CVE-2026-56739 published to NVD
2026-09-28 - Last updated in NVD database

Technical Details for CVE-2026-56739

Vulnerability Analysis

Logto issues outbound HTTP(S) requests on behalf of tenant administrators across three distinct code paths: webhook delivery, custom OAuth2 connector user info retrieval, and OIDC connector JWKS fetching. None of these paths validated whether the destination address resolved to a special-use range, loopback interface, link-local address, or cloud instance metadata endpoint such as 169.254.169.254.

An administrator attacker configures a webhook URL, userInfoEndpoint, or jwksUri that points to an internal resource. Logto then issues the request from inside the server's network boundary. For OAuth2 user info calls, the server attaches the upstream access token in the Authorization header, forwarding valid credentials to the attacker-chosen host. Responses can leak internal service data or cloud metadata, including temporary IAM credentials in managed cloud deployments.

Root Cause

The outbound HTTP client used by webhook and SSO flows relied on standard ky/fetch behavior without an address allowlist or SSRF guard. The patch introduces an ssrfProtectedFetch helper and reuses the upstream oidc-providerisSpecialUseIP check to reject special-purpose IPv4 and IPv6 addresses, including IPv4-mapped IPv6 forms, before completing the connection.

Attack Vector

Exploitation requires tenant administrative configuration access over the network. The attacker does not need user interaction. Because the request originates server-side, it crosses network trust boundaries that external callers cannot reach directly.

typescript

// Patch: packages/core/src/libraries/hook/utils.ts
 import { type IRouterParamContext } from 'koa-router';
 import ky, { HTTPError, type KyResponse } from 'ky';

+import { ssrfProtectedFetch } from '#src/utils/outbound-request.js';
 import { sign } from '#src/utils/sign.js';

 export const parseResponse = async (response: KyResponse) => {
// Source: https://github.com/logto-io/logto/commit/16f4b2e732d5114ac98646c9370ec6ab61d6ed26

typescript

// Patch: type declaration exposing isSpecialUseIP from oidc-provider
+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;
+}
// Source: https://github.com/logto-io/logto/commit/16f4b2e732d5114ac98646c9370ec6ab61d6ed26

Detection Methods for CVE-2026-56739

Indicators of Compromise

Logto application logs showing outbound webhook, userInfoEndpoint, or jwksUri requests to RFC1918 ranges, loopback (127.0.0.0/8), link-local (169.254.0.0/16), or IPv6 special-use prefixes.
Requests from the Logto host to cloud instance metadata services such as http://169.254.169.254/latest/meta-data/ or http://metadata.google.internal/.
Administrator audit entries modifying webhook destinations or SSO connector endpoints to unexpected hostnames or raw IP literals.

Detection Strategies

Alert on egress traffic from the Logto container or host targeting internal address space when such traffic is not part of normal operation.
Correlate Logto admin API changes to connector configuration with subsequent outbound HTTP activity to new destinations.
Review packages/core logs for failed TLS or HTTP connections to private addresses, which can indicate reconnaissance attempts.

Monitoring Recommendations

Enable egress filtering at the network layer to block Logto from reaching metadata IPs and internal management ranges.
Centralize Logto audit logs and tenant admin configuration changes in a SIEM for retrospective analysis.
Track changes to OIDC jwksUri and OAuth2 userInfoEndpoint fields and flag any pointing to non-public hosts.

How to Mitigate CVE-2026-56739

Immediate Actions Required

Upgrade Logto to version 1.43.0 or later, which introduces the ssrfProtectedFetch outbound request wrapper.
Audit all existing webhook URLs, OAuth2 userInfoEndpoint values, and OIDC jwksUri values across tenants for suspicious or internal targets.
Rotate any upstream OAuth client secrets or access tokens that may have been forwarded to attacker-controlled endpoints.

Patch Information

The fix is delivered in Logto v1.43.0 via pull request #9501 and commit 16f4b2e. Full technical details are documented in the GitHub Security Advisory GHSA-3556-624q-c5w3.

Workarounds

Restrict tenant administrator access to a minimum set of trusted operators until the upgrade is deployed.
Enforce egress network policies that block the Logto service from reaching RFC1918, loopback, link-local, and cloud metadata addresses.
Place Logto behind an outbound HTTP proxy that validates destination hostnames against an allowlist of expected webhook and SSO provider domains.

bash

# Example: block cloud metadata and private ranges from the Logto container
# (iptables egress policy applied on the 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 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
iptables -A OUTPUT -m owner --uid-owner logto -d 127.0.0.0/8 -j REJECT