Audit a Perl Runtime Against the 5.22.4 Security Fixes

You will finish with a small, repeatable check that tells you what perl5224delta documents, which Perl interpreter is actually being used, and whether you are looking at a release older than Perl 5.22.4. This is an audit workflow, not a patching command. Reading the document does not update Perl, change @INC, or make an old interpreter safe.

Allow about ten minutes. You need a shell and the installed perl-doc package. The examples use the local Ubuntu installation, where perl-doc is version 5.38.2-3.2ubuntu0.6 and the default interpreter is Perl 5.38.2. Your output will differ on another host. No elevated privileges are needed for these checks.

1. Confirm which documentation you are reading

Start with the ordinary, read-only lookup below. It prevents a common mistake: consulting a similarly named document from another Perl installation or an unpacked source tree.

$ command -v perl
/usr/bin/perl
$ man -w perl5224delta
/usr/share/man/man1/perl5224delta.1.gz
$ dpkg-query -W -f='${Package} ${Version}\n' perl-doc
perl-doc 5.38.2-3.2ubuntu0.6

The last line identifies the Debian package installed here. It does not mean that the document describes Perl 5.38.2. The page is a historical delta document whose subject is the change from Perl 5.22.3 to Perl 5.22.4. Its generated man-page header records the local documentation toolchain, so use the NAME and DESCRIPTION sections to identify the release being described.

2. Read the release boundary

Open the page and read the introductory text before looking at individual fixes:

$ man perl5224delta
$ man perl5223delta

The first command describes the 5.22.3 to 5.22.4 jump. The second is needed when the host is upgrading from 5.22.2, because the 5.22.4 page explicitly points backwards to the previous delta. Do not treat one delta page as a complete history of every earlier release.

The useful security entries are narrow. They cover improved removal of . from @INC in base.pm, and a fix for escaped colons and relative paths in PATH on Unix. The page also records a crash fix for s///l, module updates, and release bookkeeping. That is enough to guide an audit, but not enough to claim that every Perl security issue is fixed.

3. Record the interpreter version

Now ask the interpreter, rather than the documentation package, for its version:

$ perl -V:version
version='5.38.2';
$ perl -e 'print "$^V\n"'
v5.38.2

Compare the result with the release discussed by the page. A version newer than 5.22.4 is not automatically equivalent to a vendor-supported security state, but it is not the 5.22.3 to 5.22.4 boundary either. A result of 5.22.3 or earlier should be treated as needing a planned upgrade or a distribution security update. If the version is reported by a wrapper, container, build directory, or language manager, check the full path with command -v perl again in the same shell that runs the application.

This step is deliberately separate from the man-page lookup. Documentation can remain installed after an interpreter has been replaced, and a host can have several Perl binaries. Neither situation is unusual.

4. Inspect the two security-sensitive areas

For the @INC item, print the search path used by the same interpreter:

$ perl -e 'print join("\n", @INC), "\n"'
/etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.38.2
/usr/local/share/perl/5.38.2
/usr/lib/x86_64-linux-gnu/perl5/5.38
/usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl-base
/usr/lib/x86_64-linux-gnu/perl/5.38
/usr/share/perl/5.38
/usr/local/lib/site_perl

These entries are host-specific. The command shows the effective list; it does not prove that an application never adds another entry at runtime. Search application launchers, service units, and wrapper scripts for -I, PERL5LIB, and code that modifies @INC. Treat an explicit current-directory entry as a review item, especially for programs that load modules while working in a writable directory.

For the PATH item, inspect the environment that launches the application:

$ printf '%s\n' "$PATH"
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ command -v perl
/usr/bin/perl

Relative components such as . are easy to miss in a long value. The 5.22.4 document specifically calls out the old handling of a backslash before a colon, where a value such as /\:. could make a relative path appear safe. Do not "fix" a production environment by editing it during this read-only audit. Instead, report the exact value to the owner and arrange a controlled change.

5. Decide what needs action

If the interpreter is old, upgrade through the operating system or the approved Perl distribution process. That is a state-changing operation and may affect modules, shebangs, services, and application behaviour. Take a package and configuration backup first, test in a matching environment, and schedule a service restart if the running process must load the new interpreter. Do not replace /usr/bin/perl by hand.

If the interpreter is current but an application adds unsafe module paths or inherits a relative PATH, fix the launcher or service definition through its normal change process. After the change, repeat every command in this guide as the application user. A root shell can hide permission and environment differences, so elevated privileges are not a substitute for testing the real launch path.

If you only needed to inspect the release notes, recovery is simple: there is nothing to undo. The commands above read version and environment data only. If you performed a separate package upgrade, use the package manager's documented downgrade or rollback process rather than trying to restore Perl files manually.