CVE-2021-33026 is a critical-severity (CVSS 9.8) Deserialization of Untrusted Data vulnerability in flask-caching. No vendor fix is recorded yet; mitigation options are listed below.
Deserialization of Untrusted Data in Flask-Caching
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2021-33026.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2021-33026 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 385,987 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
flask-cachingReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Flask-Cache adds easy cache support to Flask. The Flask-Caching extension through 1.10.1 for Flask relies on Pickle for serialization, which may lead to remote code execution or local privilege escalation. If an attacker gains access to cache storage (e.g., filesystem, Memcached, Redis, etc.), they can construct a crafted payload, poison the cache, and execute Python code.
However, this is not a high-severity issue, as for an attack like this to work, an attacker must:
- Be able to write arbitrary values to the cache
- Be able to generate a cache key that will collide with a value being read by the application
- Cause the application to read a maliciously-injected value
Any situation where all 3 of those is true is a situation where the application has larger problems; for example, if someone's able to inject malicious cached rendered pages into a Flask app's cache, then they can make the website say literally anything they want, regardless of whether it involves the execution of remote code. Basically, the Pickle vulnerability follows from a website already being extremely vulnerable (due to conditions 1 and 2 being met).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | flask-caching | all versions | No fix |
Affected Products
flask-cachingflask-caching_projectDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for flask-caching, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
No patched version of flask-caching has shipped for CVE-2021-33026 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
Do not deserialise data from untrusted sources: where the format allows it, restrict deserialisation to an explicit allowlist of expected types, and prefer a data-only format (JSON, Protobuf) over one that can reconstruct arbitrary objects until you can upgrade.
Frequently Asked Questions
Is CVE-2021-33026 in your dependencies?
Find it across PyPI, including transitive dependencies.