Audit a Perl 5.16.3 Upgrade for Security Fixes

A security scanner flags an old Perl and someone needs to know, in fifteen minutes, whether it is actually below 5.16.3 and what that means. This guide is that check: whether the installation predates the fix, what it fixed, and which module versions the release notes mention. The local manpage is rendered by Perl 5.38.2, but its subject is the historical upgrade from Perl 5.16.2 to 5.16.3.

You need a shell and a Perl interpreter. The inspection steps are read-only; installing or upgrading Perl changes system state and may affect applications, so take a package-manager backup or use your normal maintenance window before doing that part.

1. Record the Perl version in use

Start with the interpreter your application or shell will actually run. Do not infer the version from a distribution name or a module directory:

$ command -v perl
/usr/bin/perl
$ perl -e 'printf "%vd\n", $^V'
v5.38.2

$^V is the Perl interpreter version. This host reports 5.38.2, newer than 5.16.3, which answers the narrow version question but does not prove an application is using this interpreter. A service may have its own Perl in a virtual environment, a container or a separately configured path.

2. Compare the result with the release boundary

Use a numeric comparison instead of sorting version strings as text. This command exits successfully when the running interpreter is at least 5.16.3:

if perl -e 'exit $^V ge v5.16.3 ? 0 : 1'; then
    printf '%s\n' 'Perl is at least 5.16.3'
else
    printf '%s\n' 'Perl is older than 5.16.3'
fi

Perl's version objects compare numeric by component, so 5.16.10 is never mistaken for older than 5.16.3. This is a decision aid, not a vulnerability scanner: it does not identify backported distribution fixes, vendor patches or application-specific dependencies. Ask the package maintainer for that when the version comes from an operating system.

3. Understand what 5.16.3 fixed

perl5163delta describes differences from 5.16.2: no new core enhancements, no intentional incompatibilities with 5.16.0, no new deprecations, no known problems. The part worth your attention is security and the bundled module versions.

• CVE-2013-1667: carefully crafted hash keys, such as URL arguments, could consume excessive memory and CPU. Described as a possible denial-of-service condition, and fixed.
• Integer wrap-around: input or output strings larger than 2**31 bytes could segfault. Fixed.
• A memory leak in the UTF-8 implementation in Encode was fixed.

These are historical release notes, not permission to treat every Perl 5.16.3-or-newer interpreter as current. A modern supported Perl release and a current operating system package are the safer target. If a legacy application must stay on 5.16, record why and keep its exposure, input limits and patch source under review.

4. Check the named module versions

The release notes list three updated components. Inspect the first two directly with the interpreter you recorded:

$ perl -MEncode -e 'print "$Encode::VERSION\n"'
3.19
$ perl -MModule::CoreList -e 'print "$Module::CoreList::VERSION\n"'
5.20231129

On this host those versions are much newer than the 5.16.3 module versions, which were Encode 2.44_01 and Module::CoreList 2.76_02. The third entry, XS::APItest 0.39, is a test module rather than a normal application dependency, and may not be installed at all:

$ perl -MXS::APItest -e 'print "$XS::APItest::VERSION\n"'
Can't locate XS/APItest.pm in @INC ...

A missing XS::APItest is not evidence the Perl interpreter lacks the 5.16.3 fixes. Do not install it just to make this audit look complete; install test modules only when a build or test suite explicitly requires them.

5. Check the application boundary

Repeat the version check in the account and environment that launch the application. For a systemd service, inspect its configured executable and environment before changing anything:

$ systemctl cat YOUR_SERVICE.service
$ sudo -u YOUR_SERVICE_USER command -v perl
$ sudo -u YOUR_SERVICE_USER perl -e 'printf "%vd\n", $^V'

Replace the two uppercase placeholders with real values. The first command is read-only; the last two use sudo only if the service account cannot be selected without it. Do not copy a service name from an example, and do not restart the service as part of this audit.

Compare this result with the interactive shell result. If they differ, the service may use an absolute interpreter path, a wrapper or a different container image. Fix the deployment source that actually controls the process, then rerun the check: /usr/bin/perl alone is not enough.

6. Plan and verify the change

If a host is below 5.16.3, use the operating system's supported package or a reviewed, reproducible build. Do not replace /usr/bin/perl by hand while services are running. Before an upgrade, capture package state and run the application's tests; after it, run the same version command under the application account and verify the service's health checks.