Incomplete Logout in SSCMS v7.4.0 Fails to Revoke JWT Tokens After Administrator Logout

[360AlphaLab]

Summary:

The current SSCMS version v7.4.0 contains a real logout invalidation flaw in the administrator logout flow. The logout endpoint only removes the server-side sessionId cache entry, but it does not invalidate the cached JWT token associated with the administrator. As a result, previously issued Bearer tokens remain usable after logout until they expire or are replaced by a newly issued token from a later login.

Details:

The issue involves the following implementation points:

• src/SSCMS.Web/wwwroot/sitefiles/assets/js/admin/logout.js
• src/SSCMS.Web/Controllers/Admin/LogoutController.Submit.cs
• src/SSCMS.Web/Controllers/V1/AdministratorsController.Logout.cs
• src/SSCMS.Core/Services/AuthManager.cs
• src/SSCMS.Core/Services/AuthManager.Jwt.cs

During administrator login, the application issues a JWT and stores that token in server-side cache. During later requests, the backend reads the supplied access_token and compares it against the currently cached token for that administrator. If the values match, the request is treated as authenticated.

However, during logout, the application only removes the SESSION-ID-{adminId} cache entry and does not remove the cached administrator token. This creates a split behavior:

• entry points that additionally validate sessionId may stop working
• other protected backend APIs that rely on [Authorize] + Bearer JWT remain accessible with the old token

This means the issue is not merely a frontend storage cleanup problem. It is a server-side failure to fully revoke the authenticated session.

Impact:

If an attacker has already obtained a valid administrator JWT, for example through browser extraction, token leakage, traffic capture, shared devices, or another compromise path, that token remains usable even after the administrator logs out. This may lead to:

• authenticated access continuing after logout
• continued use of protected administrative APIs with the old token
• false security assumptions by administrators who believe logout fully terminated access

In practice, the token remains valid until it naturally expires or until the same account logs in again and a newly issued token replaces the cached one.

Reproduction steps:

1. Log in with an administrator account and capture the current Bearer JWT.
2. Use that token to call a protected backend endpoint such as GET /api/admin/dashboard and confirm that the request succeeds.
3. Call the logout endpoint POST /api/admin/logout.
4. After logout completes, reuse the same old Bearer JWT to call GET /api/admin/dashboard again.
5. If the request still succeeds, the logout process did not revoke the JWT and the vulnerability is confirmed.