CVE-2024-6866

What it actually does

CVE-2024-6866 is an authorization-bypass weakness in corydolphin/flask-cors 4.0.1 caused by case-insensitive request path matching. URL paths are normally case-sensitive, but the vulnerable matching logic uses behavior intended for host matching, causing CORS policy rules to match paths that should not be covered. If an application relies on Flask-CORS path patterns to restrict which origins may access sensitive routes, an attacker may access differently cased path variants that incorrectly receive permissive CORS headers. This can allow browser-based cross-origin reads of protected API responses when a victim’s browser has valid credentials or tokens available to the target application.

Why it matters to the business

Applications using affected Flask-CORS configurations may unintentionally expose sensitive API responses to unauthorized websites. The most likely consequence is data leakage from browser-accessible endpoints, especially where cookies, bearer tokens, or session credentials are automatically included or otherwise available to the browser. The CVSS score is moderate and EPSS is currently low, with no CISA KEV listing or known ransomware association, but the issue has been public for a long period, so exposed applications should still be reviewed and patched during normal vulnerability remediation cycles. The provided affected-product metadata references Debian 12 fixed in 6.1.123-1; however, the vulnerability description is specific to Flask-CORS 4.0.1, so teams should verify both OS package status and application dependency versions rather than relying only on host patch state.

How an attack unfolds

An attacker first identifies a Flask application that uses Flask-CORS and has route-specific CORS rules intended to allow only certain origins for sensitive paths. The attacker then compares behavior across path capitalization variants, such as requesting a protected route with altered uppercase or lowercase characters. Because the vulnerable version performs case-insensitive path matching, a path variant that should not receive permissive CORS treatment may still match a CORS rule. The attacker hosts malicious JavaScript on an attacker-controlled origin and lures an authenticated user to visit it. The script sends cross-origin requests to the vulnerable application using the altered path casing. If the application returns sensitive data and the vulnerable CORS policy reflects or permits the attacker’s origin, the browser allows the malicious page to read the response, enabling data theft. Exploitation generally depends on application-specific CORS configuration, sensitive browser-accessible endpoints, and the presence of usable user credentials or tokens.

How to fix it

Upgrade corydolphin/flask-cors from version 4.0.1 to a fixed, non-vulnerable release as provided by the upstream project or distribution maintainers. Review application dependency lockfiles, container images, virtual environments, and transitive dependency sources to ensure the vulnerable version is not still present. If relying on Debian 12 package remediation data, verify that relevant packages are updated to the stated fixed version, linux 6.1.123-1, while separately confirming that Python application dependencies are also remediated. As a mitigation, avoid using broad or regex-based CORS rules for sensitive paths, explicitly enumerate trusted origins, do not reflect arbitrary Origin values, avoid combining wildcard origins with credentials, and enforce authorization on the server side independent of CORS behavior. Sensitive endpoints should validate authentication and authorization regardless of path casing and should normalize or reject unexpected path case variants consistently.

How to confirm the fix worked

Confirm remediation by checking dependency inventories and runtime environments for Flask-CORS versions and ensuring version 4.0.1 is no longer deployed. Run application-level tests that send requests to sensitive endpoints using multiple path capitalization variants and untrusted Origin headers. A fixed or properly mitigated application should not return permissive Access-Control-Allow-Origin headers for unauthorized origins, regardless of path casing. Validate that Access-Control-Allow-Credentials is not enabled for untrusted origins and that server-side authorization decisions remain consistent across path variants. For Debian-managed systems, confirm the relevant package level is at or above 6.1.123-1 where applicable, but do not treat OS patch validation as a substitute for checking Python package versions in application deployments.

Typical attack path

1. Identify a web application using Flask-CORS with route-specific CORS restrictions.
2. Enumerate API paths and test capitalization variants of protected routes.
3. Send requests with attacker-controlled Origin headers and observe whether Access-Control-Allow-Origin is incorrectly returned.
4. Build a malicious web page that issues cross-origin requests to the vulnerable path variant.
5. Convince or cause an authenticated user to visit the malicious page.
6. Use the victim browser’s authenticated context to request sensitive data from the vulnerable application.
7. Read and exfiltrate the response if the browser permits access due to the incorrect CORS headers.

How to detect it

To assess whether exploitation may already have occurred, review web server, reverse proxy, application, CDN, and WAF logs for requests that include an Origin header from an untrusted domain and target sensitive API paths using unusual capitalization. Focus on requests where the response included Access-Control-Allow-Origin matching the untrusted Origin or a wildcard value, especially if Access-Control-Allow-Credentials was also present. Compare normal path casing used by legitimate clients against observed variants such as uppercase letters inserted into otherwise lowercase API paths. Investigate sequences where a single source tests many capitalization variants, followed by successful authenticated requests from browsers with external Origin headers. Because exploitation occurs through normal HTTP requests and depends on application configuration, there may be no malware artifact or universal IOC; detection is primarily behavioral and log-based.

• flask-cors==4.0.1
• Flask-Cors==4.0.1
• Origin: http://
• Origin: https://
• Access-Control-Allow-Origin: *
• Access-Control-Allow-Credentials: true
• Access-Control-Request-Method:
• Access-Control-Request-Headers:
• OPTIONS /
• Access-Control-Allow-Origin: http://
• Access-Control-Allow-Origin: https://

What your security team should do

• Inventory applications and containers that include corydolphin/flask-cors, prioritizing internet-facing APIs and applications that use cookie-based authentication.
• Upgrade Flask-CORS from 4.0.1 to a fixed release and rebuild/redeploy affected application artifacts.
• Review CORS configuration for sensitive routes and replace permissive regex or origin reflection patterns with explicit trusted-origin allowlists.
• Test critical API endpoints with mixed-case path variants and untrusted Origin headers to confirm CORS headers are not over-applied.
• Add regression tests for CORS behavior so future dependency or configuration changes do not reintroduce path-matching bypasses.
• Review web access logs for suspicious cross-origin requests using unusual path capitalization, especially where responses included permissive CORS headers.
• Ensure sensitive operations enforce authentication and authorization server-side and do not rely on CORS as the primary security boundary.