CVE-2025-58065 is a medium-severity improper authentication vulnerability (CWE-287) affecting versions of the Flask-AppBuilder framework prior to 4.8.1. Flask-AppBuilder is a popular Python-based application development framework that supports multiple authentication methods including OAuth, LDAP, and database authentication. The vulnerability arises when Flask-AppBuilder is configured to use non-database authentication methods such as OAuth or LDAP. In these configurations, the password reset endpoint remains registered and accessible even though it is not presented in the user interface. This endpoint can be exploited by an enabled user to reset their password and generate JWT tokens, thereby maintaining access even after the user has been disabled on the external authentication provider. This flaw allows attackers or unauthorized users to bypass the intended account disablement controls of the authentication provider, effectively undermining the integrity of the authentication process. The vulnerability does not require user interaction and can be exploited remotely with low attack complexity, but it does require the attacker to have some level of privileges (an enabled user account). The impact is primarily on integrity, as unauthorized users can regain or maintain access despite being disabled externally. The vulnerability does not affect confidentiality or availability directly. The issue was addressed in Flask-AppBuilder version 4.8.1 by properly disabling the password reset endpoint when non-database authentication methods are used. Until upgrading, mitigations include manually disabling the password reset routes in the application configuration, implementing access controls at the web server or proxy level to block access to the password reset URL, and monitoring for suspicious password reset attempts from disabled accounts. No known exploits are currently reported in the wild.

For European organizations using Flask-AppBuilder versions prior to 4.8.1 with OAuth, LDAP, or other non-database authentication methods, this vulnerability poses a significant risk to the integrity of user authentication. Attackers or malicious insiders with enabled user accounts could reset their passwords and generate JWT tokens even after their accounts are disabled on the authentication provider, allowing persistent unauthorized access. This could lead to unauthorized actions within applications built on Flask-AppBuilder, potentially compromising sensitive business processes or data integrity. Given the widespread adoption of OAuth and LDAP in enterprise environments across Europe, especially in sectors such as finance, healthcare, and government, the vulnerability could be exploited to bypass access controls and maintain persistence within critical systems. Although the vulnerability does not directly impact confidentiality or availability, the ability to maintain unauthorized access undermines trust in authentication mechanisms and could facilitate further attacks or data manipulation. Organizations relying on centralized authentication providers must be aware that disabling users at the provider level may not be sufficient to revoke access in vulnerable Flask-AppBuilder deployments.

1. Upgrade to Flask-AppBuilder version 4.8.1 or later as soon as possible to apply the official fix that disables the password reset endpoint when using non-database authentication methods. 2. If immediate upgrade is not feasible, manually disable the password reset routes in the Flask-AppBuilder application configuration to prevent access to the vulnerable endpoint. 3. Implement strict access control rules at the web server or reverse proxy level (e.g., using Nginx or Apache) to block or restrict access to the password reset URL, limiting it to trusted administrators or internal networks only. 4. Enhance monitoring and alerting for password reset attempts, especially from accounts that have been disabled on the authentication provider, to detect suspicious activity early. 5. Review and audit user account management processes to ensure that disabling users on the authentication provider is complemented by application-level controls and that no residual access paths remain. 6. Conduct penetration testing or vulnerability scanning focused on authentication flows to verify that the password reset endpoint is properly disabled or protected. 7. Educate development and operations teams about the risks of exposing password reset functionality when using external authentication providers.