smart-sso CVE-2026-121543

The attacker must hold a valid authenticated session on the smart-sso server (PR:L) - any registered low-privilege user account suffices; it is not exploitable by a fully anonymous attacker. The decisive condition is PermissionFilter's default-allow behavior: it only enforces authorization on request paths explicitly registered in sso_permission.code, and any unlisted path (including backend admin APIs such as /admin/user-role/save) is permitted by default. This means default deployments are vulnerable out of the box, because the built-in admin console registers page paths (xxx.html) rather than the backend servlet API paths. The primary limiting factor is the account requirement; a deployment is only protected if administrators have manually registered the backend API paths into the permission table (and re-logged in to refresh the permission snapshot), which the vendor documentation indicates is not the default.

This is a genuine priority rather than a CVSS-inflated non-issue, though it is not a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scores 8.7 and is internally consistent with the description: network-reachable, low attack complexity, and crucially PR:L - exploitation requires an existing authenticated (low-privilege) account, not an anonymous attacker. The impact triad VC:H/VI:H/VA:H is well justified because a successful attacker self-assigns the administrator role and can reset passwords and manage users, roles, and applications. Because smart-sso is an identity/SSO broker, the practical blast radius extends to every integrated downstream application, so the real-world impact arguably exceeds what the SC:N/SI:N/SA:N (no subsequent-system) metrics capture. On the exploitation-likelihood side the signals are weaker and partially absent: no EPSS score was provided, and there is no CISA KEV listing, so there is no confirmed-active-exploitation signal - this is no public exploit identified at time of analysis, with the caveat that the vulnerable code path, the exact endpoint (/admin/user-role/save), and the root cause are fully documented in the public VulnCheck advisory, the GitHub issue, and the source/commit references, which makes reliable reproduction trivial for anyone with an account. The vendor's own priority label is 'this_week', consistent with a serious but authentication-gated flaw rather than an emergency. Missing data to note: no EPSS and no KEV status were supplied, so exploitation probability cannot be quantified from the input.

An attacker who holds any ordinary authenticated account on a smart-sso deployment (for example a self-registered or low-privilege user) sends a request directly to the unlisted admin endpoint /admin/user-role/save, which PermissionFilter allows by default because the path was never registered in sso_permission.code. The request binds the administrator role to the attacker's own user, after which they can reset other users' passwords and administer users, roles, and applications across all SSO-integrated systems. No separate exploit tool is required; the technique is documented in the public advisory and source references, so exploitation is straightforward despite no confirmed in-the-wild activity.