CVE-2026-82263 in Logto
Summary
by MITRE • 08/28/2026
Logto through 1.42.0 contains a server-side request forgery vulnerability in the OIDC SSO connector creation endpoint that fails to validate the issuer URL parameter. Tenant administrators with Management API credentials can supply arbitrary internal URLs to trigger HTTP GET requests to private network services, with response content returned in API responses.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/29/2026
The identified security flaw resides within Logto versions up to 1.42.0 and specifically affects the OpenID Connect single sign-on connector creation endpoint. This vulnerability is classified as a Server-Side Request Forgery, commonly referred to by its CWE identifier CWE-918. The core technical deficiency lies in the application's failure to perform adequate validation or sanitization of the issuer URL parameter provided during the configuration of an OIDC SSO connector. In standard authentication flows, this parameter is intended to point to a legitimate external identity provider. However, due to the lack of strict input filtering, the server processes user-supplied values without verifying whether they correspond to authorized public domains or if they attempt to access internal network resources.
This architectural oversight allows authenticated tenant administrators who possess Management API credentials to exploit the flaw by injecting arbitrary URLs into the request payload. By specifying an issuer URL that points to private IP addresses, loopback interfaces, or other non-routable internal services, an attacker can force the vulnerable server to initiate HTTP GET requests on their behalf. The severity of this issue is compounded by the fact that the response content from these internal services is returned directly within the API's response body. This behavior transforms a simple misconfiguration into a potent data exfiltration vector, as it enables the retrieval of sensitive information hosted on internal infrastructure that would otherwise be inaccessible to external actors or even other tenants within the same multi-tenant environment.
From an operational perspective, this vulnerability poses significant risks related to confidentiality and integrity. An attacker can use this mechanism for network reconnaissance by probing various ports and services within the private network to identify running applications, versions, and potential secondary vulnerabilities. Furthermore, if internal services are susceptible to other attacks such as SQL injection or command execution via HTTP parameters, the SSRF vulnerability serves as a critical pivot point. The attacker could potentially manipulate requests to these internal endpoints, leading to broader system compromise. This aligns with MITRE ATT&CK technique T1598, specifically Phishing for Information within Multi-Tenant Environments, and T1046, Network Service Discovery, highlighting the potential for lateral movement and information gathering against cloud-native architectures.
To mitigate this risk, immediate action is required to upgrade Logto to a version later than 1.42.0 where these input validation checks have been implemented. In environments where upgrading is not immediately feasible, network-level controls should be enforced. This includes configuring firewalls or reverse proxies to block outbound HTTP requests from the application server to private IP ranges and loopback addresses. Additionally, implementing strict allow-listing for issuer URLs in the configuration management interface can prevent arbitrary URL injection at the application layer. Regular security audits of API endpoints that handle external resource references are also recommended to ensure similar SSRF vectors do not exist elsewhere in the platform.