NumPy 2.1 Reaches End of Life on August 19, 2026

NumPy 2.1 reaches end of life (EOL) on August 19, 2026. After that date it falls outside NumPy’s support window and receives no further fixes of any kind. The last patch on the line was 2.1.3, released November 2, 2024. Supported versions after August 19 are 2.2, 2.3, 2.4, and 2.5 — but 2.2 expires on December 9, 2026, which matters more than it looks.

The upgrade is usually undramatic. Choosing the wrong target is what creates work.

‍

What ends on August 19, 2026?

Inclusion in NumPy’s supported set. No further bug fixes, no security patches, no new wheels for future Python releases.

Being direct about what this does and does not mean: NumPy 2.1 has not received a patch in 21 months. The branch has been quiet since 2.1.3 in November 2024, so the practical difference on August 20 is narrow. What changes is the commitment. Up to August 19 a serious defect in 2.1 could be fixed on that branch. After it, the answer to any problem is “upgrade.”

The wheels stay on PyPI. Nothing uninstalls itself, and pinned builds keep resolving.

‍

How does NumPy decide what stays supported?

Through SPEC 0, the support policy shared across the Scientific Python ecosystem. It supports every minor version released in the previous 24 months, with a floor of the three most recent minor releases. NumPy follows semantic versioning, and Python support is only dropped in a minor or major release, never in a patch.

SPEC 0 replaced NEP 29 as the governing policy and is used by SciPy, pandas, scikit-learn, Matplotlib, and others. That shared calendar is the reason your whole stack tends to move together — and the reason falling behind on NumPy quietly caps the versions of everything else you can install.

Because the window is a rolling 24 months rather than a designated long-term branch, there is no NumPy equivalent of an LTS release. Every version has roughly two years, and then it does not.

‍

NUMPY SUPPORT STATUS AND PYTHON COMPATIBILITY — AS OF JULY 31, 2026

‍

Why does Python 3.10 make this urgent?

Read the Python column rather than the date column.

NumPy 2.1 and 2.2 are the last releases that support Python 3.10. From 2.3 onward the floor is Python 3.11, and 2.5 requires 3.12. So the upgrade question depends entirely on which Python you are running:

• On Python 3.11 or newer: straightforward. Go to 2.3 or later and you have until at least June 2027. NumPy 2.4 buys you until December 2027.
• On Python 3.10: your only supported NumPy after August 19 is 2.2, and 2.2 expires December 9, 2026. Upgrading 2.1 to 2.2 buys you sixteen weeks. The actual project is upgrading Python.
• On Python 3.9: you are already outside the window — the newest NumPy that supports 3.9 is 2.0, which reached EOL on June 17, 2026.

This is the part teams miss. They treat the August date as a NumPy ticket, move to 2.2 because it is the smallest diff, and rediscover the same problem in December with less runway and a Python interpreter upgrade attached. If you are on 3.10, plan the interpreter move now and skip 2.2 entirely.

‍

What is the actual risk of running EOL NumPy?

Worth being accurate here, because NumPy does not look like a web framework on this question.

NumPy has a thin vulnerability history. The handful of Common Vulnerabilities and Exposures (CVE) identifiers filed against it are mostly from 2021 and earlier, target the 1.x series, and several are formally disputed by the maintainers on the grounds that triggering them requires privileges an attacker would already need. There is no meaningful backlog of unpatched NumPy 2.x CVEs waiting to be exploited, and anyone telling you otherwise is selling something.

The risk is real but differently shaped:

• Compatibility ceilings. The scientific stack pins NumPy ranges aggressively. Staying on 2.1 caps which pandas, SciPy, scikit-learn, and PyTorch versions you can install, and those packages carry their own security exposure.
• No wheels for new Python. EOL NumPy will never gain wheels for future interpreter releases. Building from source against a new Python is where teams lose weeks.
• Binary and ABI coupling. NumPy is a compiled dependency that other compiled packages link against. Version skew surfaces as import errors and segfaults rather than clean dependency-resolver failures.
• Audit findings without a CVE. SOC 2, PCI DSS, HIPAA, FedRAMP, NIS2, and DORA assessments increasingly flag unsupported components as a control gap regardless of whether a specific vulnerability exists. “No known CVE” is not the same as “patchable.”

So the honest framing is operational and compliance risk, not an imminent exploit. That is still a budget line — it is just a different one.

‍

Where is the real exposure in most estates?

Not 2.1. It is 1.26 and 2.0.

NumPy 1.26.x went EOL on September 17, 2025 and 2.0 followed on June 17, 2026. A large number of production environments are still on 1.26 because the 1.x to 2.0 transition broke the C application binary interface (ABI) and changed enough Python-level behavior — scalar promotion rules, copy semantics, the removal of long-deprecated aliases — that it needed real porting work rather than a version bump. Teams that deferred that work in 2024 are now two EOL milestones behind.

If an inventory turns up 1.26 or 2.0 alongside 2.1, sequence that first. The 2.1 deadline is the calendar reminder; the older pins are the actual liability.

‍

What should teams do before August 19?

Four steps, in order.

1. Inventory by interpreter, not just by package. Record the NumPy version and the Python version together for every environment, image, and notebook. The pair determines your options; either number alone does not.
2. Pick the furthest target your Python allows. On 3.11 or newer, go to 2.4 rather than 2.3 — same migration effort, fourteen extra months of support.
3. Run the test suite against the candidate before pinning. NumPy minor upgrades within 2.x are usually clean, but numerical output can shift subtly. Compare results, not just exit codes, and pay attention to anything that depends on dtype promotion.
4. Handle 1.26 and 2.0 as separate projects. They are ABI-breaking migrations with real scope. Do not fold them into the 2.1 ticket and expect the estimate to hold.

‍

Frequently asked questions

When exactly does NumPy 2.1 reach end of life?

August 19, 2026, which is 24 months after the 2.1.0 release on August 18, 2024. NumPy supports every minor version released in the previous 24 months under SPEC 0, so 2.1 simply ages out of the window.

What is the last version of NumPy 2.1?

NumPy 2.1.3, released November 2, 2024. No further patches are planned for the 2.1 branch.

Which NumPy version should I upgrade to?

It depends on your Python version. On Python 3.11 or newer, NumPy 2.4 is the best target — supported until December 21, 2027. On Python 3.10, NumPy 2.2 is your only supported option and it expires December 9, 2026, so the real task is upgrading Python before choosing a NumPy version.

Are there known security vulnerabilities in NumPy 2.1?

No significant ones. NumPy’s CVE history is small, concentrated in the 1.x series, largely from 2021 and earlier, and several entries are disputed by the maintainers. The risk of staying on EOL NumPy is mainly compatibility, build availability, and audit exposure rather than active exploitation.

Does NumPy have long-term support releases?

No. SPEC 0 gives every minor release a rolling 24-month window with no designated long-term branch, which is why NumPy versions expire on a predictable two-year cadence and why planning upgrades on a schedule works better than reacting to each EOL date.

‍

When the upgrade cannot happen on the calendar’s schedule

For teams still on NumPy 1.26.x, HeroDevs provides Never-Ending Support for NumPy — a drop-in replacement that keeps an EOL branch patched and audit-ready while the ABI migration is planned properly rather than rushed. Talk to our team about which versions are covered.