CVE-2026-92920
MediumCVSS 5.4Summary
admin3 through 3.0.0 fails to invalidate existing sessions when disabling a user account, allowing attackers to retain authenticated access with original permissions. Attackers can continue using bearer tokens issued before account disablement to authenticate requests, as the AuthInterceptor never re-validates the user's locked status and session expiry resets on each request.
Risk Assessment
Former or disabled users can still access the system with full permissions, potentially leading to unauthorized actions and data security breaches.
Recommendation
Implement immediate invalidation of sessions and tokens upon account disablement and re-validate the user's locked status in the AuthInterceptor on every request.
Other vulnerabilities in admin3
See all- CVE-2026-92921Medium
admin3 through 3.0.0 stores account passwords using single-round MD5 with only the username as salt and no key derivation function. Attackers with database access can recover plaintext passwords through offline dictionary or brute-force attacks due to negligible computational effort.
- CVE-2026-92919High
The admin3 application through version 3.0.0 fails to sanitize client-supplied filenames in the upload handler, allowing authenticated users to write files outside the storage root on Windows deployments. Attackers can use dot-dot path segments in filenames to escape the configured storage directory and overwrite arbitrary files accessible to the server process.
- CVE-2026-92918High
The admin3 application through version 3.0.0 persists user session tokens in the audit log event body when publishing UserLoggedIn domain events. Attackers with log:view permission can read the JSON response from the GET /logs endpoint to harvest session tokens and replay them as bearer credentials for full user access.
Original NVD description (English source)
admin3 through 3.0.0 fails to invalidate existing sessions when disabling a user account, allowing attackers to retain authenticated access with original permissions. Attackers can continue using bearer tokens issued before account disablement to authenticate requests, as the AuthInterceptor never re-validates the user's locked status and session expiry resets on each request.