CVE-2021-33026 Overview
The Flask-Caching extension through version 1.10.1 for Flask contains an insecure deserialization vulnerability due to its reliance on Python's Pickle module for serialization. This design flaw may lead to remote code execution or local privilege escalation when an attacker gains access to cache storage backends such as filesystem, Memcached, or Redis. By constructing a crafted payload and poisoning the cache, attackers can execute arbitrary Python code on the target system.
It is important to note that a third party has indicated exploitation is extremely unlikely unless the machine is already compromised. In other scenarios, the attacker would need write access to the cache storage and the ability to generate the required collision to successfully exploit this vulnerability.
Critical Impact
Successful exploitation allows attackers to execute arbitrary Python code, potentially leading to complete system compromise, data exfiltration, or lateral movement within the network.
Affected Products
- Flask-Caching versions through 1.10.1
- Applications using Flask-Caching with accessible cache backends (filesystem, Memcached, Redis)
- Python web applications leveraging Flask framework with caching extensions
Discovery Timeline
- 2021-05-13 - CVE-2021-33026 published to NVD
- 2024-11-21 - Last updated in NVD database
Technical Details for CVE-2021-33026
Vulnerability Analysis
This vulnerability stems from Flask-Caching's use of Python's Pickle module for serializing and deserializing cached data. Pickle is known to be inherently insecure when processing untrusted data because it can execute arbitrary code during the deserialization process. When cache data is retrieved and unpickled, any malicious payload embedded in the serialized data will be executed with the privileges of the application.
The attack requires the adversary to have write access to the cache storage backend. Once access is obtained, the attacker can inject a maliciously crafted Pickle payload into the cache. When the application subsequently retrieves and deserializes this poisoned cache entry, the embedded Python code executes automatically.
Root Cause
The root cause is the use of Python's pickle module for cache serialization without implementing proper safeguards. Pickle's __reduce__ method allows objects to define how they should be reconstructed during deserialization, which can be abused to execute arbitrary code. Flask-Caching does not provide alternative serialization methods or implement deserialization filters to prevent malicious object instantiation.
Attack Vector
The attack leverages network-accessible cache backends to poison cached data. The exploitation process involves:
- Gaining write access to the cache storage (Redis, Memcached, filesystem)
- Identifying cache keys used by the target Flask application
- Crafting a malicious Pickle payload containing arbitrary Python code
- Injecting the payload into the cache storage under a known or predictable key
- Waiting for or triggering the application to retrieve the poisoned cache entry
When the Flask application calls the cache retrieval function, the malicious payload is deserialized, causing the embedded code to execute. A typical malicious Pickle payload exploits the __reduce__ method to invoke functions like os.system or subprocess.Popen during deserialization.
For technical details on the vulnerability and proposed mitigations, see the GitHub Pull Request #209 and related discussion comments.
Detection Methods for CVE-2021-33026
Indicators of Compromise
- Unexpected or malformed entries in cache storage backends (Redis, Memcached, filesystem cache directories)
- Unusual process spawning from the Flask application worker processes
- Suspicious Python Pickle signatures in cache data containing __reduce__ references
- Unauthorized write operations to cache storage from external sources
Detection Strategies
- Monitor cache storage access patterns for unauthorized write operations from unexpected IP addresses or processes
- Implement application-level logging for cache operations to detect anomalous get/set patterns
- Use network intrusion detection systems to identify suspicious traffic to Memcached or Redis ports
- Deploy file integrity monitoring on filesystem cache directories to detect unauthorized modifications
Monitoring Recommendations
- Enable Redis/Memcached authentication and audit logging to track all cache operations
- Implement network segmentation to isolate cache backends from untrusted networks
- Configure SentinelOne Singularity Platform to monitor for suspicious child process creation from Python web application processes
- Regularly audit cache storage contents for signs of payload injection
How to Mitigate CVE-2021-33026
Immediate Actions Required
- Audit cache storage access controls to ensure only authorized application components can write to the cache
- Implement network segmentation to prevent external access to cache backends
- Consider migrating to alternative caching solutions that use safer serialization formats (JSON, MessagePack)
- Review and restrict Redis/Memcached authentication and network binding configurations
Patch Information
The Flask-Caching project has discussed this vulnerability in GitHub Pull Request #209. Organizations should review the discussion comments for guidance on implementing safer serialization alternatives or additional security controls.
Workarounds
- Implement network-level access controls (firewalls, security groups) to restrict cache backend access to trusted application hosts only
- Enable authentication on Redis using requirepass or Memcached with SASL authentication
- Consider implementing a custom serializer using JSON or other safe formats instead of Pickle
- Deploy application-level validation to verify cache entry integrity before deserialization
# Redis configuration hardening example
# Add to redis.conf to restrict network access and enable authentication
# Bind Redis to localhost only
bind 127.0.0.1
# Require password authentication
requirepass your_strong_password_here
# Disable dangerous commands
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.


