CVE-2025-58065 in Flask-AppBuilder
Summary
by MITRE • 09/11/2025
Flask-AppBuilder is an application development framework. Prior to version 4.8.1, when Flask-AppBuilder is configured to use OAuth, LDAP, or other non-database authentication methods, the password reset endpoint remains registered and accessible, despite not being displayed in the user interface. This allows an enabled user to reset their password and be able to create JWT tokens even after the user is disabled on the authentication provider. Users should upgrade to Flask-AppBuilder version 4.8.1 or later to receive a fix. If immediate upgrade is not possible, manually disable password reset routes in the application configuration; implement additional access controls at the web server or proxy level to block access to the reset my password URL; and/or monitor for suspicious password reset attempts from disabled accounts.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/12/2025
CVE-2025-58065 represents a critical authentication bypass vulnerability within Flask-AppBuilder version 4.8.0 and earlier, where the password reset endpoint remains accessible even when users are disabled in external authentication systems such as OAuth or LDAP. This flaw stems from improper access control implementation where the framework fails to properly validate user authentication status during password reset operations, creating a persistent security gap that persists beyond the intended user lifecycle. The vulnerability is classified under CWE-639 as Authorization Bypass Through User Control, specifically manifesting as improper authorization validation in authentication flows. When an organization disables a user account in their central authentication system, the user should be effectively denied access to all application resources, yet this flaw allows continued access through the password reset mechanism. The technical implementation defect occurs because the password reset endpoint does not perform proper authentication status checks before processing reset requests, enabling attackers to exploit this functionality even when accounts have been disabled in the underlying authentication provider. This creates a dangerous scenario where compromised or terminated user credentials can continue to function through the password reset mechanism, potentially allowing unauthorized access to sensitive application resources and data.
The operational impact of this vulnerability extends beyond simple authentication bypass, creating potential for privilege escalation and unauthorized data access within applications built on Flask-AppBuilder. Attackers can leverage this vulnerability to reset passwords for disabled accounts and subsequently generate JWT tokens, effectively maintaining access to the application even after the user's legitimate access has been revoked. This represents a significant security risk in environments where user account lifecycle management is critical, particularly in regulated industries where proper access control and audit trails are mandatory. The vulnerability aligns with ATT&CK technique T1566.002 for credential harvesting and T1548.003 for abuse of cloud access tokens, as it enables attackers to harvest credentials and abuse access tokens through the password reset mechanism. Organizations using Flask-AppBuilder with external authentication methods face particular risk, as this vulnerability directly undermines the security controls implemented in their central authentication systems, creating a bypass that allows attackers to circumvent account disablement policies and maintain unauthorized access to protected resources.
The recommended mitigations for this vulnerability encompass both immediate remediation and defensive measures to address the exposure. The primary fix involves upgrading to Flask-AppBuilder version 4.8.1 or later, where the framework properly validates user authentication status before processing password reset requests. When immediate upgrade is not feasible, organizations should manually disable password reset routes through application configuration changes, effectively removing the endpoint from the application's accessible routes. Additional protective measures include implementing web server or proxy level access controls to block access to password reset URLs, which provides an additional layer of defense independent of application-level controls. Network monitoring and anomaly detection should be implemented to identify suspicious password reset attempts from accounts that have been disabled in the authentication provider, as these activities may indicate exploitation attempts. Security teams should also consider implementing rate limiting on password reset endpoints to prevent abuse and establish clear audit trails for all password reset activities. The vulnerability demonstrates the importance of proper access control validation and the necessity of maintaining consistency between application-level authentication state and external authentication provider status, particularly in multi-factor authentication environments where account disablement should propagate across all application components. Organizations should also review their overall authentication architecture to ensure that similar vulnerabilities do not exist in other application components that may interact with external authentication systems.