CVE-2024-6844

What it actually does

The flaw is an improper input validation/path normalization issue in corydolphin/flask-cors 4.0.1 where request paths containing the plus character are processed through unquote_plus, converting '+' into a space. Because CORS rules are matched against the incorrectly normalized path, an application may apply the wrong CORS policy to an endpoint. Depending on the application’s configuration, this can unintentionally allow cross-origin browser access to endpoints that should be restricted, or incorrectly block legitimate cross-origin traffic.

Why it matters to the business

Applications relying on path-specific CORS rules may expose browser-accessible API responses to unauthorized websites or experience service disruption for legitimate web clients. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but the issue has been public for an extended period, so internet-facing applications using vulnerable versions should still be reviewed and patched during normal vulnerability remediation cycles. If Debian 13 packaging is in scope, update to the fixed package version 6.12.5-1 or later as identified by the vendor data.

How an attack unfolds

An attacker identifies a web application using the vulnerable CORS handling behavior and reviews or probes endpoints whose CORS configuration differs by path. They then craft requests to paths containing '+' or encoded variants that are normalized inconsistently by the vulnerable code. If the altered path causes the application to match a more permissive CORS rule than intended, the attacker can host malicious JavaScript on an attacker-controlled origin and cause a victim’s browser to send cross-origin requests to the target application. If the victim is authenticated and the application allows credentials or exposes sensitive response headers, the attacker may be able to read data that should have been protected by the intended CORS policy. In other cases, exploitation may result in availability or usability issues by causing valid browser requests to be denied due to incorrect CORS matching.

How to fix it

Upgrade affected flask-cors deployments to a version containing the corrected path handling behavior. If using distribution packages, apply the vendor-fixed package; for Debian 13 data provided here, update to version 6.12.5-1 or later where applicable. Review dependency manifests, container images, virtual environments, and base images for corydolphin/flask-cors 4.0.1. As a mitigation until upgrade, avoid relying on ambiguous path patterns involving '+', use explicit allowlists for trusted origins, avoid wildcard origins on sensitive endpoints, do not enable credentialed CORS unless strictly required, and validate CORS behavior with paths containing '+', '%2B', and spaces. Ensure sensitive API endpoints require authorization server-side and do not rely on CORS as the primary access-control boundary.

How to confirm the fix worked

Confirm the vulnerable package version is no longer present in application dependency inventories, build artifacts, containers, and deployed runtime environments. For Python deployments, check package metadata with tools such as pip show flask-cors, pip freeze, poetry show, pipenv graph, or SBOM/dependency scanners. For Debian-managed deployments, verify the installed package version with dpkg-query or apt-cache policy and confirm it is at the fixed vendor version or later. Functionally test representative endpoints by sending requests with Origin headers and paths containing '+', '%2B', and spaces, then confirm Access-Control-Allow-Origin, Access-Control-Allow-Credentials, and related CORS headers match the intended endpoint-specific policy. Regression-test both allowed and denied origins to ensure unauthorized origins are blocked and legitimate clients continue to work.

Typical attack path

1. Identify an application or API that uses vulnerable flask-cors behavior and path-specific CORS rules.
2. Find endpoints where CORS policy differs based on URL path.
3. Send test requests containing '+' or encoded plus-like path variants and compare CORS response headers.
4. Determine whether the vulnerable normalization causes a restricted endpoint to inherit a more permissive CORS policy.
5. Host malicious browser-based code on an attacker-controlled origin.
6. Trick or lure an authenticated user into visiting the attacker-controlled page.
7. Use the victim’s browser to issue cross-origin requests and read responses if the misapplied CORS policy permits it.

How to detect it

There are no widely reported public exploit artifacts or known threat actor campaigns for this vulnerability based on the supplied data, so detection should focus on evidence of probing and anomalous CORS behavior. Review HTTP access logs, reverse proxy logs, WAF logs, CDN logs, and application logs for requests with Origin headers targeting URL paths containing '+', '%2B', or unusual space/plus transformations. Correlate these requests with response headers such as Access-Control-Allow-Origin and Access-Control-Allow-Credentials to identify cases where untrusted origins received permissive CORS responses. Pay particular attention to requests from unfamiliar external origins, browser-like user agents, repeated status/header comparison probes, and access to sensitive API paths. For possible successful exploitation, look for authenticated cross-origin requests where the Origin is not an approved application domain but the response still included Access-Control-Allow-Origin matching that origin or a wildcard. Also review dependency and deployment logs to determine whether vulnerable versions were present during the suspicious request window.

• flask-cors==4.0.1
• Flask-Cors==4.0.1
• Origin:
• Access-Control-Allow-Origin: *
• Access-Control-Allow-Credentials: true
• %2B
• +
• unquote_plus
• request.path

What your security team should do

• Inventory applications, containers, and images that include flask-cors 4.0.1 or affected distribution packages.
• Prioritize externally exposed APIs and applications with credentialed CORS, sensitive data responses, or path-specific CORS policies.
• Upgrade to the fixed vendor/package version; for Debian 13 package data provided, ensure version 6.12.5-1 or later where applicable.
• Review CORS configurations for wildcard origins, overly broad regular expressions, credentialed CORS, and path rules containing or adjacent to '+' semantics.
• Add regression tests that verify CORS headers for paths containing '+', '%2B', and spaces.
• Review web access logs for unusual cross-origin requests to plus-containing paths, especially where responses included permissive CORS headers.
• Do not treat CORS as authorization; ensure sensitive endpoints enforce authentication and authorization on the server side.