Every week, someone asks us where to download ActivePerl 5.24, or whether their 32-bit build will survive a move to Windows Server 2022. The question sounds like a download problem. It's a support problem. Perl itself is actively maintained, but the version most of these teams run stopped getting security patches years ago, and every CPAN module sitting on top of it inherited that risk the day it happened.

Key Takeaways

• Perl isn't end of life. Perl 5.44 shipped in July 2026, and the community officially supports the two most recent stable series.
• Older series like 5.18, 5.24, and 5.28 no longer receive community security patches, and neither do the module stacks you've built on them.
• The risk lives in your CPAN dependencies as much as the interpreter, especially XS modules compiled against libraries like OpenSSL and libxml2.
• A standalone ActivePerl install gives you an interpreter. It doesn't give you provenance, an SBOM, or anyone accountable when a CVE lands.
• ActiveState's Curated Catalog for Perl delivers modules built from source with a build-time SBOM, signed provenance, and a contractual remediation SLA, and your cpanm or carton workflow barely changes.

The language is maintained. The version you run is another story.

"Is Perl end of life?" is one of the most common questions we hear, and the honest answer is no. The Perl 5 porters released 5.44 on July 15, 2026. The project's own maintenance policy says it officially supports the two most recent stable release series and provides critical security patches, on a best-effort basis, for any series whose 5.x.0 release landed within the past three years.

Run that policy against a real estate. Perl 5.38 stopped receiving critical security patches in July 2026. Perl 5.24 shipped in 2016. Perl 5.18 shipped in 2013. If your production systems run either one, you aren't a little behind. You're running an interpreter the community stopped patching years ago, most likely installed by someone who has since left the company, on a server that's about to get an operating system upgrade.

That's the misdiagnosis worth naming. Teams hear "Perl is old" and conclude the language is the risk. The language is fine. Running it unsupported is the risk, and that risk compounds quietly because nothing breaks until something does.

End of life doesn't stop at the interpreter

Most conversations about an end-of-life Perl version focus on the perl binary. That's the smallest part of the problem.

A typical production Perl application pulls in dozens of CPAN modules, and each of those pulls in more. Some are pure Perl. Many aren't. XS modules like the ones behind SSL connections, XML parsing, and database drivers compile against native libraries such as OpenSSL and libxml2. When a CVE lands in one of those libraries, you need a version of the module built against the patched library, for your Perl version, on your platform. On a community-EOL interpreter, nobody is producing that build for you.

Here's what that looks like in practice. A scanner flags a vulnerable module. The patched release requires a newer Perl than the one you run. Upgrading Perl breaks two other modules your billing job depends on. The ticket sits in the backlog while everyone agrees it's important. Across the industry, high and critical application vulnerabilities take an average of 54.8 days to remediate, and that figure assumes someone is actively working the problem. For an unowned Perl stack, the clock often never starts.

The question to ask isn't "is my Perl version supported?" It's "who is accountable for every module on top of it?"

Why a standalone ActivePerl install isn't enough anymore

For a long time, ActivePerl solved exactly the problem teams had: getting a working, tested Perl onto Windows and Linux machines without compiling anything. ActiveState has supported Perl continuously since 1997, and for years that meant a solid installer and a set of pre-verified modules.

The requirements changed. Security teams now ask where each component came from and how it was built. Auditors ask for an SBOM. Engineering leaders need documented justification for any end-of-life software still in production. A standalone installer answers none of those questions. It gives you an interpreter and a snapshot of modules frozen at the moment you downloaded them.

That's why many of the people writing in to ask for an ActivePerl download are asking for the wrong thing, through no fault of their own. They want the tool that worked in 2016. What their environment needs in 2026 is a governed source of Perl components that stays current after the download.

What changes when you move to the Curated Catalog for Perl, and what doesn't

We built the Curated Catalog for Perl to extend the vetted-build model ActivePerl started into something a security team can actually govern. Every module is built from source by ActiveState. Every build ships with an SBOM generated at build time and signed provenance, so you can show exactly where a component came from and how it was produced. And when a critical CVE lands, a team is contractually accountable for delivering the remediated component: within 5 business days for critical vulnerabilities and 10 days for high, with the clock starting once an upstream community fix exists.

The coverage matches the /perl page: built, tested, and maintained releases across the versions enterprises actually run in production, including versions no longer supported by the community, for Windows and Linux, with security patching that extends to CPAN module dependencies.

Here's the part most teams worry about, and the good news. For most builds, very little changes on your end. Pure Perl and self-contained modules install the same way they always have. You point cpanm or carton at the catalog index and keep working. Your developers don't learn a new toolchain.

The exception is XS modules compiled against native libraries. Some of those move over as is. Others need to be built against a current version of OpenSSL, libxml2, or a similar library, which can affect your upgrade timeline. That's worth knowing up front, and it's the first thing we'll look at with you.

Five steps to get off an end-of-life Perl build

1. Inventory your interpreters. Run perl -v on every host that matters. Record the version, 32-bit or 64-bit, the OS, and whether an OS upgrade is scheduled. The upcoming server migration is usually what forces the question.
2. Inventory your modules. Export what's actually installed, not what you think is installed. A cpanfile or carton snapshot is ideal. If you don't have one, generating it is the first win.
3. Separate pure Perl from XS. Flag every module that compiles against a native library. Those are where CVEs and upgrade friction concentrate.
4. Pick a target series and a timeline. Decide whether you're moving to a current supported series now, or holding a legacy version under a support contract while you plan the move. Both are defensible. Running it unowned isn't.
5. Point your toolchain at a governed source and test in staging. Switch cpanm or carton to the catalog index, run your test suite, and compare the SBOM against your inventory from step 2.

How ActiveState Helps

ActiveState gives your Perl estate what a standalone install can't: supported distributions for the versions you actually run, modules built from source with a build-time SBOM and signed provenance, and a contractual remediation SLA that covers your CPAN dependencies. If you're deciding whether to maintain, modernize, or move off Perl entirely, our team helps with both: keeping current deployments secure and planning the transition when you're ready.

The fastest way to find out where your build stands is a 30-minute conversation. Send us your module list, or just tell us your Perl version and platform, and we'll tell you whether it moves over as is or needs work, and what that means for your timeline.

Jonny Rivera is Senior Director, Product Management at ActiveState, where he leads product strategy for the ActiveState Curated Catalog and the company's software supply chain security roadmap. He writes regularly about open source governance, dependency security, and the architecture decisions that determine whether a vulnerability reaches production in the first place.