CVE-2026-111642 in FastapiAdmin
Summary
by MITRE • 10/16/2026
FastapiAdmin through 3.0 contains a hard-coded JWT signing secret in backend/app/config/setting.py that allows low-privileged users to forge tokens impersonating the superuser. Attackers can register via the unauthenticated /api/v1/system/user/register endpoint, log in, and forge an HS256 token keeping their session_id but naming the superuser in user_name to gain superuser privileges.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in FastapiAdmin versions through 3.0 represents a critical authentication bypass resulting from improper security configuration of cryptographic keys. Specifically, the application utilizes a hard-coded JSON Web Token signing secret located within the backend/app/config/setting.py file. This static credential is embedded directly into the source code rather than being managed via secure environment variables or external secrets management systems. The use of a predictable and publicly accessible signing key for HS256 HMAC-based token generation fundamentally undermines the integrity of the authentication mechanism, as it allows any actor with access to the application's configuration files or source code repository to derive the secret required to sign arbitrary tokens.
The operational impact of this flaw is severe, enabling privilege escalation from a low-privileged user account to that of an administrator without requiring password guessing or other complex exploitation techniques. An attacker can initiate the attack by registering a new account through the unauthenticated registration endpoint at /api/v1/system/user/register. Upon successful authentication with these newly created credentials, the attacker obtains a valid session identifier and a legitimate JWT signed with the compromised secret. By manipulating the payload of this token to change the user_name field to that of an existing superuser while retaining their own session_id or generating a new one, the application fails to validate whether the token was legitimately issued for that specific identity. This logic error allows the forged token to be accepted by the server as valid administrative credentials.
This vulnerability aligns with CWE-798: Use of Hard-coded Credentials and CWE-287: Improper Authentication, specifically illustrating a failure in verifying the binding between the session state and the user identity claims within the JWT payload. From an ATT&CK perspective, this behavior facilitates Account Manipulation via T1098.4 (SSH Authorized Keys) or more accurately Token Forgery under Initial Access or Persistence depending on usage, but primarily it is a classic case of Broken Authentication leading to Privilege Escalation. The ability to impersonate the superuser grants unrestricted access to all system functions, potentially allowing data exfiltration, modification of critical configurations, installation of backdoors, and complete compromise of the underlying infrastructure protected by this application layer.
Mitigation strategies must prioritize the immediate rotation of any exposed secrets and the implementation of robust key management practices. The hard-coded JWT secret in setting.py should be removed entirely and replaced with a strong, randomly generated secret stored securely via environment variables or a dedicated secrets manager such as HashiCorp Vault or AWS Secrets Manager. Furthermore, developers should implement strict validation logic to ensure that the user identity claims within a JWT match the authenticated session context, preventing token forgery attacks where users attempt to alter their role or username fields. Regular security audits and static application security testing (SAST) scans configured to detect hard-coded credentials are essential to prevent similar misconfigurations in future development cycles.