Check Your Perl Against the 5.34.3 Security Fixes

The perl5343delta manpage names two real CVEs, but reading it will not tell you whether your live Perl is actually patched. This guide closes that gap with a ten-minute inventory check: find the interpreter a command really runs, match it to its package, and work out whether either fix applies to you. You need a shell account and read access to the host. Nothing here changes Perl, packages or running services.

One thing to get straight first: the local perl5343delta(1) page, installed by perl-doc, is a historical release note for the jump from Perl 5.34.1 to 5.34.3. It is not a claim that this host runs 5.34.3, and reading it proves nothing about what is actually installed.

1. Read what the 5.34.3 delta covers

• CVE-2023-47038. A crafted regular expression could trigger 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. A Windows-only issue: Perl's search for cmd.exe could check the current working directory before safer locations, opening the door to executable hijacking.

These are two different checks. The first is about Perl's regular-expression compiler and can matter to Linux workloads. The second is a Windows Perl issue only, so do not let its description creep into a Linux-specific finding. Neither entry gives you a command that safely reproduces the bug, and there is no safe way to test a production interpreter with a guessed proof-of-concept.

2. Check the interpreter on the PATH

Start with the executable an ordinary shell would pick:

$ 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
...

Look at the version line, not the copyright text underneath it. This host reports Perl 5.38.2 while the manpage describes a 5.34 maintenance release, and that is fine: a page named perl5343delta can be useful reference material without describing the interpreter your PATH currently selects.

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

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

Run this as the same user, inside the same service account or deployment environment that actually runs the application. Your workstation shell can happily 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, name or revision scheme, but the key distinction stays the same: perl supplies the interpreter, perl-doc supplies documentation. Updating only the docs cannot patch the executable.

Do not stop at the upstream-looking version number. Distribution security updates often keep a base Perl version while bumping the package revision, so use your distribution's security advisory and changelog to find out whether the fix is actually backported. The local delta page cannot tell you that on its own.

4. Decide what the result means

• Older than the vendor's fixed build? Schedule an update through the host's normal package process.
• A vendor build with a later revision? Check the vendor advisory before calling it vulnerable.
• Maintain Perl yourself? Inspect the source release and its tests, then deploy through your normal review and rollback process.

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 has the path, the Perl version and the package revision together:

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

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

Found something that looks like a genuine defect? Reduce it to a small test case and use Perl's public issue tracker only when the issue is suitable for public discussion. For anything security-sensitive, the manpage points to Perl's security contact instead of a public issue. Never put credentials, private input or an unredacted production payload in a ticket.