Perl 5.42.2 updates the zlib bundled inside its compression module

Perl 5.42.2 and 5.40.4 were released today, March 29, as recorded in the Perl release history. Both update Compress::Raw::Zlib to 2.222. The security issue is a dependency inside a dependency, since the module included with Perl carries a vendored zlib implementation. For an operator, the resulting question is which copy of that code the running program uses.

The 5.42.2 release notes identify CVE-2026-4176 as the Perl packaging issue. They connect it to CVE-2026-3381 in the compression module and to vulnerabilities in its bundled zlib, including CVE-2026-27171. These identifiers refer to related levels of distribution. Treating them as unrelated upgrade tasks would obscure why one bundled-module update appears in several security records.

I still reach for Perl for one-off text transformations. That preference makes dependency boundaries relevant even when the program itself is short. A few lines of Perl can load native code through a module, and the interpreter version alone may not explain the final dependency selection. I would use this release to verify that selection before deciding the update is complete.

A core module can have an independent release life

The release notes call Compress::Raw::Zlib a dual-life core module. It ships with Perl and also has a separate module distribution. That arrangement gives users more than one route to an updated implementation. It also means a copy installed separately can affect what an application loads, so inspecting only the interpreter package leaves part of the answer unresolved.

In the 5.42 maintenance line, the bundled module changes from 2.213 to 2.222. The 5.40.4 notes record a change from 2.212 to the same replacement. Both notes state that the releases contain no intentionally incompatible changes relative to their immediate predecessors. That is useful maintenance intent, although I would still test the compression behavior an application depends on.

The CPANSec portion of the CVE record, published today, recommends the two stable releases or later versions containing the updated module. It also describes a module-level workaround through the include path. That workaround makes the resolution order operationally relevant. Installing a corrected module somewhere on disk is insufficient unless the application actually selects it.

I would prefer an update whose ownership is clear. If the operating-system package owns Perl and its modules, its packaging guidance should establish the supported repair. If an application carries its own module installation, that installation needs its own verification. Mixing these responsibilities without recording them makes the next security review harder because nobody can tell which update mechanism controls the loaded code.

Inspect the loaded module and native library

The module source shipped with 5.42.2 defines version 2.222 and loads its XS implementation. Its documentation exposes zlib_version() for inspecting the library version. A small diagnostic can retain the interpreter version and selected module path alongside those values.

use strict;
use warnings;
use Compress::Raw::Zlib ();

print "perl=$^V\n";
print "module=$Compress::Raw::Zlib::VERSION\n";
print "path=$INC{q(Compress/Raw/Zlib.pm)}\n";
print "zlib=", Compress::Raw::Zlib::zlib_version(), "\n";

I would run that probe through the same interpreter and environment as the application. Running it from a different login environment can establish something about that shell while leaving the service unresolved. The useful evidence is the selected implementation under the conditions that matter, including any application-specific include path.

The probe is an inventory aid. It does not exercise a vulnerability and does not prove that a supplier has applied every relevant patch. A package can carry backported fixes, and the supplier must document what its package contains. I would attach that documentation to the observed module and library information before assigning a final status.

This distinction avoids another common inference error. A successful compression round trip demonstrates ordinary functionality for the selected inputs. It cannot establish that a vulnerable boundary condition has been repaired. Functional tests and security patch provenance answer different questions, so I would keep both forms of evidence when accepting the update.

System zlib can change the applicability decision

CPANSec notes that some operating-system distributions patch Perl to build the module against system zlib instead of its vendored copy. Its advisory says such users may be unaffected if that system library is sufficiently updated or has the relevant backported fixes. This is a qualification that needs confirmation for the actual package being deployed.

Updating a system library therefore cannot be assumed to repair every Perl installation. A module using its own bundled copy has a different dependency relationship. Conversely, the presence of an older-looking interpreter version does not by itself establish the state of a distribution-patched package. The build choice and patch record need to accompany the version information.

I would ask the package supplier to identify that build choice if its advisory is unclear. Guessing from the machine-wide zlib package list risks confusing an available library with the one linked into the selected module. The same reasoning applies to an application image whose runtime includes only part of the build environment. The relevant copy is the one the final program uses.

For regression testing, I would retain representative compressed inputs and check the application-level outputs after the update. If an application handles malformed input, its tests should also establish the expected failure behavior without relying on an unverified exploit example. This release does not require inventing a new format or changing an application interface to justify maintenance work.

My acceptance record would identify the selected interpreter, module location, and compression implementation, then link the supplier evidence for the repair. I would keep that record with the application deployment configuration. That gives the next maintainer enough information to distinguish an updated package from an application still loading an older separately installed module. It also makes the same review possible on the older maintained Perl line without requiring a move to a different language release series.