CVE-2024-25128: 
Python vulnerability analysis and mitigation

Flask-AppBuilder, an application development framework built on top of Flask, contains a vulnerability (CVE-2024-25128) when configured with AUTH_TYPE AUTH_OID. The vulnerability was discovered and disclosed on February 28, 2024, affecting versions prior to 4.3.11. This security issue specifically impacts applications using the OpenID 2.0 authorization protocol, which is a legacy protocol deprecated about 10 years ago and distinct from the modern OIDC (OpenID Connect) protocol (GitHub Advisory).

The vulnerability allows an attacker to forge HTTP requests that could deceive the backend into using any requested OpenID service. When Flask-AppBuilder is set to AUTH_TYPE AUTH_OID, the application fails to properly validate the OpenID provider, potentially allowing unauthorized access. The issue has been assigned a CVSS v3.1 base score of 9.1 (CRITICAL) with the vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, indicating high severity with potential for unauthorized privilege access (NVD).

If successfully exploited, this vulnerability could grant an attacker unauthorized privilege access to the application. The impact is particularly severe if a custom OpenID service is deployed by the attacker and accessible by the backend. However, the scope of impact is limited to applications specifically using the legacy OpenID 2.0 authorization protocol, which has significantly reduced usage and is no longer supported by major authorization providers (GitHub Advisory).

The vulnerability is exploitable through forged HTTP requests when the application uses the OpenID 2.0 authorization protocol. The attack requires no special privileges or user interaction, as indicated by the CVSS metrics (PR:N/UI:N). However, exploitation is limited to environments specifically configured to use the deprecated OpenID 2.0 protocol (NVD).

The primary mitigation is to upgrade to Flask-AppBuilder version 4.3.11 or later. For cases where immediate upgrade is not possible, a workaround involves implementing a custom security manager class that adds proper validation for OpenID providers. This can be done by extending the SecurityManager class and implementing additional validation checks in the authentication flow (GitHub Advisory).