Check Whether a Perl Runtime Includes the 5.34.3 Security Fixes

You will finish with a small inventory check for the Perl interpreter that a Linux command actually runs, plus a clear way to act on the two security issues documented for Perl 5.34.3. Allow about ten minutes. You need a shell account and access to the host you are checking. The commands below read version information only and do not alter Perl, packages or running services.

The local perl5343delta(1) page is installed by the perl-doc package. Here it is a historical release note for the change from Perl 5.34.1 to 5.34.3. It is not a claim that this host is running Perl 5.34.3, and reading it does not prove that a fix is installed.

1. Read what the 5.34.3 delta covers

The document names two security fixes. CVE-2023-47038 describes a crafted regular expression that could cause a one-byte, attacker-controlled heap-buffer overflow when compiled by affected Perl versions from 5.30.0 through 5.38.0. CVE-2023-47039 concerns Perl for Windows: its search for cmd.exe could look in the current working directory before safer locations, allowing executable hijacking in the wrong conditions.

These are different checks. The first concerns Perl's regular-expression compiler and can matter to Linux workloads. The second is explicitly a Windows Perl issue, so do not turn its description into a Linux-specific finding. Neither entry gives you a command that can safely reproduce the bug. Do not test a production interpreter with a guessed proof-of-concept.

2. Check the interpreter on the PATH

Start with the executable that an ordinary shell would select:

$ command -v perl
/usr/bin/perl
$ perl -v

This is perl 5, version 38, subversion 2 (v5.38.2) built for x86_64-linux-gnu-thread-multi
...

The important part is the version line, not the copyright text. This host reports Perl 5.38.2, while the manpage describes a 5.34 maintenance release. A manpage named perl5343delta can therefore be useful reference material without describing the interpreter currently selected by PATH.

For a short value that is easier to capture in a script, ask Perl for its version variable:

$ perl -e 'print $^V, "\n"'
v5.38.2

Run the check as the same user, inside the same service account or deployment environment that will execute the application. A shell on your workstation can select a different Perl from a container, virtual environment, application bundle or system service.

3. Check the package that owns the system interpreter

On Debian or Ubuntu, pair the runtime check with the package database:

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

Your distribution may use a different package manager, package name or revision scheme. The key distinction is between perl, which supplies the interpreter in this example, and perl-doc, which supplies documentation. Updating only documentation cannot patch the executable.

Do not compare only the upstream-looking number. Distribution security updates often retain a base Perl version while adding a package revision. Use your distribution's security advisory and package changelog to determine whether its build contains the relevant fix. The local delta page alone cannot tell you how a vendor backported a change.

4. Decide what the result means

If the runtime is older than the vendor's fixed build, schedule an update through the host's normal package process. If it is a vendor build with a later revision, check the vendor advisory before labelling it vulnerable. If you maintain Perl yourself, inspect the source release and its tests, then deploy the resulting interpreter through your normal review and rollback process.

Do not replace /usr/bin/perl by hand and do not install a second interpreter over an existing one. System tools may depend on the distribution's Perl and its module paths. A locally built Perl can be kept under an explicit prefix and selected by an application-specific environment or service configuration, but that change needs its own compatibility review.

There is no safe undo command for an unreviewed interpreter replacement. Before an upgrade, record the current executable and package version, preserve the package manager's rollback route, and test the application in a staging environment. If a deployment causes trouble, use the distribution's documented package downgrade or snapshot recovery process rather than copying an old binary over the new one.

5. Keep the check focused on the real execution path

Repeat the version command from the application directory and, where relevant, from the service's execution environment. A useful record contains the path, Perl version and package revision:

printf 'perl=%s\n' "$(command -v perl)"
perl -e 'print "version=$^V\n"'

This does not prove that every Perl process on the machine uses that binary. Search scheduled jobs, service definitions and deployment scripts for explicit interpreter paths, and inspect containers separately. Keep that review read-only until you have identified the owner and change window for each runtime.

For a suspected defect, reduce the report to a small test case and use the Perl project's issue tracker only when the issue is suitable for public discussion. The manpage directs security-sensitive reports to Perl's security contact information rather than a public issue. Do not include credentials, private input or an unredacted production payload in a ticket.