smart-sso EUVD-2026-103044

Exploitation requires: (1) a target smart-sso server at or below version 2.1.1 whose /login handler accepts an unvalidated redirectUri parameter; (2) a victim who already holds an ACTIVE authenticated SSO session; (3) that victim being induced to open an attacker-crafted /login link (passive user interaction); and (4) the attacker possessing ANY set of valid OAuth2 client credentials to redeem the leaked authorization code at /oauth2/access_token. These are the concrete limiting factors reflected by AC:H, AT:P, and UI:P - the attack fails against users with no active session, if the victim never clicks the link, or if the attacker lacks valid client credentials; no attacker authentication to the SSO server itself is needed (PR:N).

This is a genuine but conditional risk rather than a drop-everything emergency. The CVSS 4.0 base score of 7.6 (HIGH) is driven by network attack vector (AV:N), no privileges required (PR:N), and high confidentiality and integrity impact (VC:H/VI:H) reflecting theft of victims' OAuth2 access tokens. However, the same vector embeds significant friction: AC:H (high attack complexity), AT:P (a specific attack requirement), and UI:P (passive user interaction) - meaning successful exploitation depends on a victim who already holds an active SSO session being lured into clicking a crafted /login link, plus the attacker possessing valid client credentials to redeem the stolen code. There is NO CISA KEV listing and NO EPSS score provided in the input, so there is no evidence of active or widespread exploitation; a detailed technical write-up (hackmd) and annotated source references exist, documenting the technique, but no packaged weaponized exploit is confirmed. Signals are internally consistent: the HIGH CVSS is tempered by its own complexity/interaction metrics, and the absence of KEV/EPSS data supports treating this as a real, patch-worthy flaw in affected smart-sso deployments rather than a mass-exploited threat. Key missing data: no EPSS probability and no explicit POC flag were supplied, so exploitation likelihood cannot be quantified from the input alone.

An attacker crafts a /login URL for a vulnerable smart-sso server containing an attacker-controlled redirectUri and sends it (via phishing/email/chat) to a user who already has an active SSO session. When the victim opens the link, the server issues and redirects the OAuth2 authorization code to the attacker's endpoint; the attacker then redeems that code at /oauth2/access_token using any valid client credentials to obtain the victim's access token. A detailed public technical write-up describes the full flow, but no confirmed packaged exploit code was indicated in the input.