CVE-2026-111641 in FastapiAdmin
Summary
by MITRE • 10/16/2026
FastapiAdmin through 3.0 contains an authentication bypass vulnerability that allows unauthenticated attackers to obtain sessions for any user by abusing unprotected auto-login endpoints. Attackers can list users via /api/v1/auth/auto-login/users, mint a superuser auto-login token, and exchange it for a JWT session to gain full administrative control.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in FastAPIAdmin versions through 3.0 represents a critical authentication bypass flaw that fundamentally undermines the security model of the administration interface. This issue stems from the improper implementation of auto-login endpoints which were intended as convenience features for specific operational scenarios but were left exposed without adequate access controls or rate limiting mechanisms. By design, these endpoints are meant to facilitate seamless user transitions under trusted conditions; however, their exposure to unauthenticated actors allows malicious entities to exploit this trust boundary. The core technical flaw lies in the server's failure to validate whether a request originating from an auto-login endpoint is coming from a legitimate, authenticated context or if it is being abused by an external attacker seeking to impersonate any user within the system. This lack of contextual validation enables attackers to bypass standard authentication checks entirely, effectively rendering username and password protections obsolete for those specific API routes.
From a technical perspective, the exploitation path involves interacting with two distinct but related endpoints: /api/v1/auth/auto-login/users and the subsequent token exchange mechanism. An attacker first queries the users endpoint to enumerate valid usernames within the system, leveraging the lack of authorization checks on this listing function. Once a target user is identified, typically prioritizing high-privilege accounts such as superusers due to their elevated permissions, the attacker initiates an auto-login request for that specific account. The server erroneously generates and returns an auto-login token without verifying the identity or intent of the requester. This token serves as proof of authentication for a brief window and can then be exchanged for a standard JSON Web Token (JWT) session cookie. By converting this temporary credential into a persistent JWT, the attacker establishes a fully functional administrative session indistinguishable from one obtained through legitimate login procedures.
The operational impact of this vulnerability is severe, granting unauthenticated attackers complete control over the application's administration panel. With full administrative privileges, an adversary can modify system configurations, access sensitive data stored within the database, create or delete user accounts, and potentially execute arbitrary code if the admin interface provides integration with other vulnerable services. This level of compromise effectively results in a total breach of confidentiality, integrity, and availability for any organization relying on FastAPIAdmin for its backend management needs. The ability to list users exacerbates the risk by allowing attackers to perform targeted attacks against specific high-value accounts rather than guessing credentials blindly, significantly increasing the success rate of such exploits.
This vulnerability aligns with CWE-287, which describes Improper Authentication, as well as CWE-613, Insufficient Session Expiration, given that the auto-login tokens and resulting JWT sessions can be abused indefinitely if not properly rotated or invalidated. In terms of MITRE ATT&CK framework classifications, this behavior corresponds to T1078 Valid Accounts, where attackers use legitimate credentials obtained through abuse rather than theft, and potentially T1528 Steal Application Access Token if the JWT is considered an application access token. The exploitation also touches upon T1621 Multi-Factor Authentication Bypass if multi-factor authentication was expected to protect these endpoints but failed due to the architectural flaw in how auto-login interacts with broader security policies.
Mitigation strategies must focus on immediate remediation of the exposed endpoints and long-term hardening of the authentication architecture. The most effective short-term fix is to restrict access to /api/v1/auth/auto-login/users and related auto-login routes by requiring valid administrative sessions or specific IP whitelisting, ensuring that these convenience features are not accessible from untrusted networks. Developers should also implement strict rate limiting on all authentication-related endpoints to prevent enumeration attacks and brute-force attempts. Long-term solutions involve redesigning the auto-login mechanism to require additional verification steps, such as re-authentication with a password or multi-factor token before issuing any session credentials. Additionally, implementing robust input validation and ensuring that JWTs issued from auto-login flows have significantly shorter lifespans can limit the window of opportunity for attackers. Regular security audits focusing on authentication logic and access control lists are essential to prevent similar misconfigurations in future updates.