Smart Sso
Monthly
Incorrect authorization in smart-sso through 2.0.1 lets any registered low-privilege user reach admin console APIs, because PermissionFilter only enforces permissions on request paths that are explicitly registered in sso_permission.code and allows every unlisted path by default. The built-in admin console registers page paths such as xxx.html rather than the backend servlet paths, so a default deployment leaves endpoints like /admin/user-role/save reachable; calling it lets an attacker grant themselves the administrator role, reset passwords, and manage users, roles, and applications across integrated systems. Exploitation requires a valid authenticated session (PR:L) and is not possible for a fully anonymous attacker; the vendor has published an upstream fix (commit 9bccabaa5ec5 plus a second commit) and a fixed release version is not stated in the available data. A public PoC reference exists; it is not verified as working exploit code, and no confirmed active exploitation (CISA KEV) was identified at time of analysis.
Unauthenticated remote attackers can steal OAuth2 authorization codes from smart-sso deployments running version 2.1.1 or earlier by abusing an unvalidated redirectUri parameter in the /login handler (CWE-601). A victim who already holds an active SSO session must be induced into opening a crafted /login link, after which the attacker - who must additionally hold any valid OAuth2 client credentials - redeems the leaked code at /oauth2/access_token to obtain the victim's access token, giving both high confidentiality and integrity impact (CVSS 7.6 v4.0: AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N; independent assessment CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N). Exploitation is conditional rather than trivial: it fails if the victim has no active session, does not click the link, or if the attacker lacks valid client credentials, though no authentication to the SSO server itself is required (PR:N). No public exploit identified at time of analysis, although a public technical writeup describing the authorization-code leak path has been published; this is a genuine but conditional risk rather than a drop-everything emergency.
A vulnerability was determined in a466350665 Smart-SSO up to 2.1.1. This affects the function Save of the file smart-sso-server/src/main/java/openjoe/smart/sso/server/controller/admin/UserController.java of the component Role Edit Page. [CVSS 2.4 LOW]
Smart SSO up to version 2.1.1 contains a reflected cross-site scripting vulnerability in the login page's redirectUri parameter that allows unauthenticated remote attackers to execute arbitrary JavaScript in users' browsers. Public exploit code exists for this vulnerability, and the vendor has not released a patch despite early disclosure notification.
Incorrect authorization in smart-sso through 2.0.1 lets any registered low-privilege user reach admin console APIs, because PermissionFilter only enforces permissions on request paths that are explicitly registered in sso_permission.code and allows every unlisted path by default. The built-in admin console registers page paths such as xxx.html rather than the backend servlet paths, so a default deployment leaves endpoints like /admin/user-role/save reachable; calling it lets an attacker grant themselves the administrator role, reset passwords, and manage users, roles, and applications across integrated systems. Exploitation requires a valid authenticated session (PR:L) and is not possible for a fully anonymous attacker; the vendor has published an upstream fix (commit 9bccabaa5ec5 plus a second commit) and a fixed release version is not stated in the available data. A public PoC reference exists; it is not verified as working exploit code, and no confirmed active exploitation (CISA KEV) was identified at time of analysis.
Unauthenticated remote attackers can steal OAuth2 authorization codes from smart-sso deployments running version 2.1.1 or earlier by abusing an unvalidated redirectUri parameter in the /login handler (CWE-601). A victim who already holds an active SSO session must be induced into opening a crafted /login link, after which the attacker - who must additionally hold any valid OAuth2 client credentials - redeems the leaked code at /oauth2/access_token to obtain the victim's access token, giving both high confidentiality and integrity impact (CVSS 7.6 v4.0: AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N; independent assessment CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N). Exploitation is conditional rather than trivial: it fails if the victim has no active session, does not click the link, or if the attacker lacks valid client credentials, though no authentication to the SSO server itself is required (PR:N). No public exploit identified at time of analysis, although a public technical writeup describing the authorization-code leak path has been published; this is a genuine but conditional risk rather than a drop-everything emergency.
A vulnerability was determined in a466350665 Smart-SSO up to 2.1.1. This affects the function Save of the file smart-sso-server/src/main/java/openjoe/smart/sso/server/controller/admin/UserController.java of the component Role Edit Page. [CVSS 2.4 LOW]
Smart SSO up to version 2.1.1 contains a reflected cross-site scripting vulnerability in the login page's redirectUri parameter that allows unauthenticated remote attackers to execute arbitrary JavaScript in users' browsers. Public exploit code exists for this vulnerability, and the vendor has not released a patch despite early disclosure notification.