Audit a Perl 5.26.3 Upgrade with perl5263delta

You will finish with a short, evidence-based check of what Perl 5.26.3 changed, whether the host is running that release, and which local applications need follow-up. perl5263delta is a release-note document, not a command that upgrades Perl or repairs an application.

Allow about fifteen minutes for one host. You need a shell and the perl-doc package for the full local document. The examples are read-only apart from the deliberately malformed regular-expression test, which only starts a short Perl process and leaves no files behind. Do not run untrusted Perl code while investigating a security issue.

1. Confirm the interpreter and documentation

Start with ordinary, read-only checks. They do not need sudo or another elevated account:

$ command -v perl
/usr/bin/perl
$ perl -v | sed -n '1,3p'

This is perl 5, version 38, subversion 2 (v5.38.2) built for x86_64-linux-gnu-thread-multi
(with 67 registered patches, see perl -V for more detail)
$ command -v perldoc
/usr/bin/perldoc
$ perldoc -l perl5263delta
/usr/share/perl/5.38/pod/perl5263delta.pod

Your version and documentation path will differ. The installed manpage on this host is generated from Perl v5.38.2 documentation, but it describes the historical change from 5.26.2 to 5.26.3. That distinction matters: reading the page does not prove that Perl 5.26.3 is installed.

2. Read the release delta locally

Use either the manpage or perldoc to inspect the document that belongs to this host:

$ man perl5263delta
$ perldoc perl5263delta

The useful scope is narrow. Perl 5.26.3 contains security fixes for an Archive::Tar extraction bypass involving a symlink and a regular file with the same name, an integer-overflow buffer overflow in Perl_my_setenv(), and three regular-expression parser or buffer-overflow issues. It also records two updated core modules and three new fatal diagnostics for malformed extended character classes.

There are no intentionally incompatible changes from 5.26.2. That does not mean every application is risk-free after an upgrade. A changed bug may expose an application that depended on unsafe behaviour, and a module outside the core may have its own compatibility requirements.

3. Check the affected module versions

The release notes say that Archive::Tar moved from 2.24 to 2.24_01 and Module::CoreList moved from 5.20180414_26 to 5.20181129_26. Inspect the modules actually selected by the current interpreter:

$ perl -MArchive::Tar -e 'print "$Archive::Tar::VERSION\n"'
2.40
$ perl -MModule::CoreList -e 'print "$Module::CoreList::VERSION\n"'
5.20231129

The numbers above are examples from a newer Ubuntu Perl installation; your output is authoritative for this host. A module version newer than the release-note value is not by itself a complete security assessment, because packaging may backport fixes or change the module independently. Capture the distribution and package as well if you are preparing a change record:

$ dpkg-query -W -f='${Package} ${Version}\n' perl perl-base perl-modules-5.38 perl-doc
perl 5.38.2-3.2ubuntu0.6
perl-base 5.38.2-3.2ubuntu0.6
perl-modules-5.38 5.38.2-3.2ubuntu0.6
perl-doc 5.38.2-3.2ubuntu0.6

If a package name is not installed, dpkg-query reports an error and the rest of the check can still be useful. On an RPM-based system, use the equivalent query command supplied by that distribution.

4. Reproduce the diagnostic change safely

The new diagnostics concern extended regular-expression character classes. Compile a tiny expression that is intentionally incomplete and capture the non-zero status:

$ perl -e '"x" =~ /(?[[a])/;'
Syntax error in (?[...]) in regex; marked by <-- HERE in m/(?[[a]) <-- HERE / at -e line 1.
$ printf 'exit status: %s\n' "$?"
exit status: 255

Exact wording and exit status can vary with the installed Perl release. The point of this check is to confirm that the interpreter reports a compile-time regular-expression error, not to prove that it is specifically the 5.26.3 diagnostic. Stop if your shell reports an unexpected syntax error in the command itself.

Do not turn this into a test harness that feeds production input to a live service. The issues in the release notes concern crafted inputs; testing an application requires a controlled staging copy, resource limits and a rollback plan.

5. Decide what needs privileged follow-up

All inspection commands above run as an ordinary user. Installing a vendor Perl update, restarting a service or changing a system package requires the privileges and maintenance process for that host. Those actions can affect every Perl application, so identify the owning service before changing anything:

$ ps -eo user,pid,comm,args | awk '$3 == "perl" || $3 == "perl5.38.2"'
$ systemctl list-units --type=service --state=running | grep -i perl

These commands may produce no output, and that is useful: Perl may be invoked by a differently named service, a scheduler or a web server. Search deployment files and service definitions before assuming that a package upgrade is enough. Do not remove an old interpreter or restart production merely because perl5263delta lists security fixes.

Before a real change, save the package versions, run the application's existing tests under the candidate interpreter, and arrange a rollback to the previous package set. A package downgrade or service restart is operationally disruptive; it is not part of this read-only audit.