CVE-2024-6221 is a high severity access control flaw in corydolphin/flask-cors 4.0.1, scored 7.5. The library sets the Access-Control-Allow-Private-Network CORS header to true by default, which can expose private network resources. The project changed the default in a commit titled as a breaking change for version 5.
What's affected
The record lists flask-cors version 4.0.1 as affected. The weakness is CWE-284, improper access control. The vector in the record is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, so the impact is confidentiality only.
The fix is the upstream commit 03aa3f8, whose title reads "V5: Breaking: Change default to disable private network access". I did not confirm a release number from the pages I could read, so check the flask-cors release notes and PyPI page for the exact fixed version before you pin it. The record also references a huntr bounty page, which was not readable.
Because the change is marked as breaking, upgrading can alter behavior. Apps that relied on the old default for private network access will stop receiving the permissive header after the update, and that is the intended outcome.
The record does not say this is exploited in the wild, and it is not a KEV entry.
How to check if you're exposed
Find out which version your application resolves:
pip show flask-cors
pip list | grep -i flask-cors
For a project with a lockfile, search it for the package name, for example grep -i flask-cors requirements.txt poetry.lock Pipfile.lock. Do the same for container images, since the library is often pulled in as a transitive dependency of an API framework.
Then look at the behavior. Private Network Access is the browser mechanism where a public site asks permission, through a preflight request, to reach a device on a private address. A server that answers that preflight with the allow header set to true tells the browser to go ahead. Look at the response headers from your own API for Access-Control-Allow-Private-Network and see whether the value was set by your code or by the library default.
What to do now
- Upgrade flask-cors to the release that includes the default change, after confirming its number in the release notes.
- Rebuild images and redeploy so the new version is the one running, not just the one in the lockfile.
- Decide whether any of your endpoints really should answer private network preflights. Most do not.
- If one does, set the option explicitly in your CORS configuration rather than relying on a default, and restrict allowed origins.
- Pin the version in your lockfile and let your dependency tooling alert you to the next change.
Why it matters
Browsers added Private Network Access to stop public web pages from quietly reaching routers, printers and internal services. The server gets to decide whether it will answer. A library that says yes by default hands that decision to every developer who never read the setting.
This is a secure default problem. The code did what it was told, but the instruction was the wrong one for most users. The consequence in the record is data exposure from private network resources to unauthorized external pages.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is the issue a code bug or a configuration choice?
It is a default. Version 4.0.1 enabled the header out of the box, and the fix flips the default so you opt in.
Which version should I pin?
Confirm it in the flask-cors release notes. The fix commit is labelled as part of version 5, but check the notes before you pin.
Sources
- flask-cors commit 03aa3f8
- NVD record for CVE-2024-6221, as held in the batch record file
Last reviewed: 19 October 2026.
