CVE-2026-111622 in smart-sso
Summary
by MITRE • 10/16/2026
smart-sso through 2.1.1 contains an open redirect vulnerability in the /login handler that allows unauthenticated attackers to steal OAuth2 authorization codes by supplying an unvalidated redirectUri parameter. Attackers can send crafted /login links to users with active SSO sessions, then redeem stolen codes at /oauth2/access_token with any valid client credentials to obtain victims' access tokens.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in smart-sso versions up to 2.1.1 represents a critical security flaw within the authentication flow, specifically located in the login handler's handling of redirect parameters. This open redirect vulnerability stems from an insufficient validation mechanism for the redirectUri parameter supplied by clients during the OAuth2 authorization code grant process. In standard OAuth2 implementations, the identity provider must strictly validate that the requested redirection URI matches a pre-registered and trusted list to prevent attackers from manipulating the post-authentication flow. However, in this implementation, the system fails to enforce such constraints, allowing an unauthenticated attacker to inject arbitrary URLs into the redirectUri field. This lack of validation creates a pathway for malicious actors to hijack the user's authentication session by controlling where they are directed after successful login credentials are submitted or when existing sessions are leveraged.
The operational impact of this flaw is severe because it facilitates the theft of OAuth2 authorization codes, which serve as temporary tokens used to exchange for long-lived access tokens. An attacker can craft a malicious link containing the compromised redirectUri and distribute it to users who possess active single sign-on sessions with the smart-sso provider. When these victims click the link or are redirected through social engineering tactics, their browsers will follow the unvalidated URI to a destination controlled by the attacker. This process effectively bypasses the need for the victim's password at that specific moment if they already have an active session, allowing the attacker to capture the authorization code generated during this interaction. The stolen code is not merely informational; it is a functional credential that grants access to further resources.
Once the authorization code is obtained, the attacker proceeds to redeem it at the /oauth2/access_token endpoint using any valid client credentials associated with the application. This step completes the OAuth2 flow from the perspective of the token server, resulting in the issuance of an access token for the victim's account. With this access token, the attacker gains full authenticated access to the resources protected by smart-sso on behalf of the victim. This compromise allows for unauthorized data exfiltration, privilege escalation within the application context, and potential lateral movement if the compromised tokens have broad permissions. The ability to steal these codes without prior authentication makes this vulnerability particularly dangerous in enterprise environments where single sign-on is widely deployed.
From a classification standpoint, this issue aligns with CWE-601, which defines URL Redirection to Untrusted Site (Open Redirect). Furthermore, within the MITRE ATT&CK framework, this technique corresponds to T1534, known as Internal Spearphishing, where attackers use trusted internal systems or services like SSO providers to deliver malicious payloads or steal credentials. The exploitation also touches upon CWE-287, Improper Authentication, because it allows an attacker to impersonate a user by stealing their session-based authorization artifacts without directly authenticating themselves against the primary identity provider's password database.
Mitigation strategies must focus on strict input validation and secure configuration of OAuth2 flows. Developers should implement allowlisting for redirect URIs, ensuring that only pre-registered domains are accepted as valid targets for redirection after authentication. Additionally, implementing PKCE (Proof Key for Code Exchange) is highly recommended to mitigate authorization code interception attacks, although it does not directly fix the open redirect itself but adds a layer of defense against token theft. The smart-sso project must release an updated version that enforces rigorous validation on all URI parameters involved in the authentication handshake. Until patches are applied, administrators should monitor logs for unusual redirection patterns and consider restricting access to sensitive endpoints based on IP reputation or behavioral anomalies if possible.