CVE-2026-82262: Logto SSRF Vulnerability in Hooks Endpoint

CVE-2026-82262 Overview

CVE-2026-82262 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in Logto through version 1.42.0. The flaw resides in the POST /api/hooks/:id/test endpoint, which accepts arbitrary URLs without host validation. Tenant administrators holding Management API tokens can coerce the Logto server to issue HTTP POST requests to internal URLs and receive the response bodies back. This exposes services on the private network, including cloud metadata endpoints and internal APIs that assume network-level trust.

Critical Impact
Authenticated tenant administrators can pivot from the Logto Management API into internal networks, retrieving response bodies from services never intended for external exposure.

Affected Products

Logto versions up to and including 1.42.0
Logto Core webhook subsystem (packages/core/src/libraries/hook/utils.ts)
Deployments exposing the Management API to tenant administrators

Discovery Timeline

2026-08-28 - CVE-2026-82262 published to the National Vulnerability Database
2026-08-31 - Last updated in NVD database

Technical Details for CVE-2026-82262

Vulnerability Analysis

Logto exposes a webhook test endpoint that allows tenant administrators to validate outbound webhook configurations. The endpoint accepts a target URL and issues an HTTP POST request from the Logto server to that URL. Because the request originates server-side, the destination is reached with the Logto server's network posture and routing table. The vulnerable implementation performs no filtering against loopback, link-local, private-use, or shared address ranges. Any Management API token holder can therefore direct the server to fetch internal resources.

Root Cause

The root cause is missing destination validation in the webhook dispatch utility packages/core/src/libraries/hook/utils.ts. The pre-patch code passes the user-supplied URL directly into the ky HTTP client with no allowlist or IP category checks. IPv4-mapped IPv6 addresses, DNS names resolving to private ranges, and IANA special-purpose addresses were all reachable. Response bodies were returned to the caller, converting the SSRF into a read-capable primitive rather than a blind side channel.

Attack Vector

An attacker with a valid Management API token issues a POST /api/hooks/:id/test request specifying an internal URL such as a cloud instance metadata service, a Kubernetes API endpoint, or an unauthenticated internal admin panel. The Logto server sends the POST and returns the parsed response to the attacker. This is exploitable over the network without user interaction, but requires high privileges (tenant administrator) on the Logto tenant.

typescript

// Security 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

The fix routes outbound webhook requests through a new ssrfProtectedFetch wrapper. A companion type declaration re-exports isSpecialUseIP from oidc-provider/lib/helpers/fetch_request.js, which detects loopback, private-use, link-local, and shared address space, and unwraps IPv4-mapped IPv6 addresses before evaluation.

Detection Methods for CVE-2026-82262

Indicators of Compromise

HTTP requests to POST /api/hooks/:id/test where the request body's target URL resolves to RFC1918, loopback (127.0.0.0/8), link-local (169.254.0.0/16), or cloud metadata addresses such as 169.254.169.254.
Outbound connections from the Logto server process to internal service ports (for example 6443, 2379, 8500, 9200) that have no legitimate business purpose.
Management API token usage patterns showing repeated hooks/*/test calls with varying host targets, indicative of internal reconnaissance.

Detection Strategies

Inspect Logto application logs for hooks/:id/test invocations and correlate the submitted URL against a private-address blocklist.
Monitor egress from Logto containers or hosts; alert when destinations fall inside the internal network or cloud metadata CIDRs.
Audit Management API token issuance and correlate token usage with anomalous webhook test volume per tenant.

Monitoring Recommendations

Enable structured request logging on the Logto reverse proxy to capture the target URL parameter of webhook test calls.
Forward Logto and network flow logs to a centralized analytics platform for cross-source correlation of internal fetches originating from the authentication server.
Baseline normal webhook test destinations per tenant and alert on deviations to private or metadata ranges.

How to Mitigate CVE-2026-82262

Immediate Actions Required

Upgrade Logto to the version containing commit 16f4b2e732d5114ac98646c9370ec6ab61d6ed26, which introduces ssrfProtectedFetch for webhook and SSO outbound requests.
Rotate all Management API tokens after patching to invalidate credentials that may have been used to probe internal services.
Review Logto audit logs for prior use of POST /api/hooks/:id/test against non-public URLs and treat matching tenants as compromised until reviewed.

Patch Information

The upstream fix is tracked in Logto issue #9465 and delivered via commit 16f4b2e with the message "fix(core,shared): block SSRF in webhook and SSO outbound requests (#9501)". The patch adds the ssrfProtectedFetch helper and enforces isSpecialUseIP checks across webhook and SSO outbound paths. Additional context is available in the VulnCheck SSRF Advisory.

Workarounds

Restrict egress from the Logto server at the network layer, blocking traffic to RFC1918 ranges, loopback, link-local, and cloud metadata IPs such as 169.254.169.254.
Place Logto behind an outbound HTTP proxy that enforces a destination allowlist for webhook and SSO callbacks.
Limit issuance of Management API tokens to trusted operators and enforce short token lifetimes until upgrade is complete.

bash

# Example egress hardening with iptables on the 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 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