With all of the security incidents constantly happening, many engineering teams are starting to tighten up on their own security practices. One of the big ones is going through a software-bill-of-materials (SBOM) for your applications and scripts. This means understanding the tools you use might have security vulnerabilities in them and can be mitigated.

That’s why package versions matter so much. Vulnerabilities that have been patched in the latest version might not have been backported to older versions. Those older versions are usually at end-of-life (EOL) for support. EOL means that the package maintainers are no longer pushing any patches to that version so they can focus on new features or keep later versions up to date.

There are some Python packages that get downloaded a lot every day with versions that have vulnerabilities and they might be in your apps and workflows, especially if you use any of these.

‍

Django

Unresolved CVEs in EOL Django versions can lead to serious issues like SQL injection, cross-site scripting (XSS), or authentication bypass. Since Django commonly handles user authentication, sessions, and database interactions, these vulnerabilities can directly expose sensitive user data. If left unpatched, attackers could escalate privileges, access restricted areas, or execute malicious code within the application.

‍

Tensorflow

TensorFlow’s vulnerabilities often involve memory corruption, buffer overflows, or improper input validation within model processing components. In EOL versions, these flaws could allow attackers to execute arbitrary code or crash model-serving infrastructure. For organizations running ML workloads in production, this can mean compromised models, poisoned outputs, or infrastructure-level breaches.

‍

Apache Airflow

Unpatched CVEs in Apache Airflow can expose workflow metadata, credentials, or allow remote code execution through the web UI. Since Airflow orchestrates data pipelines and often integrates with databases and cloud services, a vulnerability can provide attackers with broad access to critical systems. In EOL versions, these risks remain permanently exploitable once they’ve been reported.

‍

urllib3

Vulnerabilities in urllib3 frequently involve improper certificate validation, request smuggling, or header injection. Since many HTTP clients in the Python ecosystem are built on top of this, unresolved issues can silently affect multiple upstream dependencies. An attacker exploiting an EOL version could intercept secure communications or manipulate outbound requests.

‍

Pillow

Pillow CVEs usually involve malformed image parsing that can trigger denial-of-service (DoS) or memory corruption. Applications that process user-uploaded images are especially vulnerable, since crafted files can crash services or potentially enable code execution. In unsupported versions, these attack vectors remain open with no official remediation.

‍

Salt

Salt has historically had high-severity vulnerabilities involving authentication bypass and remote code execution. Since it is used for infrastructure automation and remote command execution, a single exploit can grant attackers control over entire fleets of servers. Running an EOL version significantly increases the blast radius of any disclosed vulnerability.

‍

Werkzeug

Werkzeug vulnerabilities usually affect development servers, debugging consoles, or request handling mechanisms. If improperly exposed in production, unresolved CVEs can allow attackers to access interactive consoles or manipulate request data. EOL versions leave these pathways open without patches to close them.

‍

aiohttp

aiohttp vulnerabilities commonly relate to HTTP request parsing errors, header handling, or denial-of-service conditions. Since it powers async APIs and microservices, a flaw can disrupt high-concurrency systems or enable request smuggling attacks. Unsupported versions mean performance-critical services remain exposed to known exploits.

‍

Zope

Zope CVEs usually involve privilege escalation, authentication weaknesses, or object traversal flaws. As a web application server and content management framework, vulnerabilities can expose sensitive administrative functionality. EOL versions can leave legacy enterprise systems permanently exposed to exploitation.

‍

pypdf

Vulnerabilities in pypdf typically come from improper parsing of malicious PDF files. Attackers can craft PDFs that cause DoS or trigger unsafe memory behavior when processed. Applications that automatically analyze or extract data from PDFs are especially at risk when running unpatched versions because the library directly parses and processes the internal structure of PDF files, which can be controlled by an attacker.

‍

MLFlow

MLFlow vulnerabilities can expose experiment tracking data, model artifacts, or allow unauthorized access to model registries. Since it usually integrates with cloud storage and CI/CD pipelines, a compromised MLFlow instance can become a pivot point into the larger infrastructure. EOL versions mean newly disclosed security flaws remain exploitable without mitigation.

‍

Conclusion

These are just a few of the hundreds of Python packages that have vulnerabilities ranging from low to critical severity. If you’re using any of the affected package versions, you should take the time to address them because there are already people who know how to exploit these vulnerabilities.

You have a few options for handling EOL versions. You can fork the OSS repo, patch, and maintain your own version. That can take time away from new feature development or bug fixes in the actual product. Something else that is sorely overlooked is the security expertise and deep knowledge of a project to patch vulnerabilities correctly, especially when there's no OSS patch to backport or it doesn’t backport cleanly.

Or you can partner with an EOL service like HeroDevs and just upgrade to the patched version that you’re already familiar with and you won’t have to worry about any of that.