Logto is the modern, open-source auth infrastructure for SaaS and AI apps. Prior to 1.43.0, Logto fetches administrator-controlled outbound destinations without validating the address used for the connection. Webhook delivery in packages/core/src/libraries/hook/utils.ts can reach special-use and cloud metadata addresses. Custom OAuth2 connectors can use an attacker-selected userInfoEndpoint and forward the OAuth access token in the Authorization header, while OIDC connectors can fetch an attacker-selected jwksUri. The affected operations require tenant administrative configuration access, but they cross the server's network boundary and can expose internal data or upstream provider credentials. This issue is fixed in version 1.43.0.
Logto is the modern, open-source auth infrastructure for SaaS and AI apps. From 1.31.0 until 1.42.0, the Account API handlers in packages/core/src/routes/account/third-party-tokens.ts allow a caller holding a same-user access token with only the openid scope to retrieve stored social or enterprise SSO provider access tokens through GET /api/my-account/identities/{target}/access-token or GET /api/my-account/sso-identities/{connectorId}/access-token. The handlers authenticate the user but do not require the identities scope that protects neighboring identity-detail operations, bypassing the intended Account API consent boundary. Exploitation requires federated token-set storage to be enabled and the affected user to have authenticated through a supported connector. A low-trust application can use the disclosed provider token against upstream APIs within that token's granted scopes. This issue is fixed in version 1.42.0.
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.
Logto through 1.42.0 contains a server-side request forgery vulnerability in the POST /api/hooks/:id/test endpoint that accepts arbitrary URLs without host validation. Tenant administrators with Management API tokens can make the server issue HTTP POST requests to internal URLs and retrieve response bodies from services on the private network.
CVE-2026-63187 is a code injection vulnerability in logto-io's logto product affecting versions from 1.40.1 up to but not including 1.41.0. The issue arises from unsafe interpolation of the GitHub pull request title into a shell command within a GitHub Actions workflow, allowing an attacker to inject arbitrary shell commands. The vulnerability is mitigated by the use of a read-only GITHUB_TOKEN that does not expose repository secrets, limiting impact to disruption or alteration of the ephemeral workflow execution. This vulnerability is fixed in version 1.41.0.
CVE-2026-63188 is a path traversal vulnerability in the logto-io logto Tunnel npm package prior to version 0.3.9. It allows unauthenticated attackers to read arbitrary files outside the intended static directory by sending crafted requests with path traversal sequences. This occurs because the package improperly joins paths without normalization or containment checks. The vulnerability is fixed in version 0.3.9.
CVE-2026-62317 is a high-severity vulnerability in logto-io's Logto authentication infrastructure prior to version 1.41.0. It involves inefficient regular expression complexity in the email subaddressing blocklist logic, which can cause catastrophic backtracking and stall the event loop. This denial-of-service condition affects authentication, token issuance, SSO, and the administrative console availability. The issue is fixed in version 1.41.0.
Logto is the modern, open-source auth infrastructure for SaaS and AI apps. Prior to 1.41.0, Logto's Account Center step-up check accepted any active verification record that belonged to the current user and had isVerified === true. A WebAuthn registration verification record for binding a new passkey could be created and verified with only an existing Account API bearer token, then sent in the logto-verification-id header and treated as identityVerified=true by Account Center routes, allowing MFA factor management without proving possession of an existing password, identifier, or MFA factor. This issue is fixed in version 1.41.0.
Logto is the modern, open-source auth infrastructure for SaaS and AI apps. Prior to 1.41.0, Logto's existing TOTP verification accepted a successfully used TOTP code again while the code remained inside the RFC 6238 acceptance window because the verifier used otplib's stateless check with window = 1 and did not persist or compare the accepted TOTP time-step counter. An attacker who has the victim's first factor and captures a live TOTP value can replay that value to satisfy MFA during the same acceptance window. This issue is fixed in version 1.41.0.
Logto is the modern, open-source auth infrastructure for SaaS and AI apps. Prior to 1.41.0, Logto's self-hosted SAML application IdP built the signed SAML response and assertion by string-substituting user-controlled profile attributes such as name, email, and custom attribute-mapping values into element-text placeholders of a SAML XML template using samlify 2.10.0, which left those placeholders unescaped. An authenticated low-privilege user could place XML markup in a profile attribute so Logto signed a forged SAML attribute, such as an arbitrary role, allowing privilege escalation at relying Service Providers that authorize on SAML attributes. This issue is fixed in version 1.41.0.
Logto is the modern, open-source auth infrastructure for SaaS and AI apps. Prior to 1.41.0, @logto/core reflected the SAML RelayState, SAMLResponse, and actionUrl into a Logto-origin auto-submit HTML form in packages/core/src/saml-application/SamlApplication/utils.ts without HTML-attribute escaping. A SAML application flow with a crafted RelayState from GET or POST /api/saml/:id/authn could inject script that runs on the Logto tenant origin after the user completes login. This issue is fixed in version 1.41.0.