Check Perl 5.38.2 and Verify Your Upgrade

Perl 5.38.1 was a short-lived broken release, so perl5382delta is the note that actually matters for its two documented security fixes. This guide gives you a quick, reproducible check that your Linux host's interpreter is at 5.38.2 or later, and makes sure you understand what both fixes actually cover. The local reference is perl5382delta, the release note for the change from 5.38.0 to 5.38.2.

Allow about ten minutes. You need a shell and permission to read the installed package database. Updating packages normally needs elevated privileges, but every check in this guide is unprivileged. The examples were checked on a Debian-family system with Perl 5.38.2 and the perl-doc package installed.

1. Check the interpreter you will actually run

Start with the executable your shell selects, so you do not check one Perl binary and run another later:

$ command -v perl
/usr/bin/perl
$ perl -e 'print "$^V\n"'
v5.38.2

The version has to come from the interpreter itself, never from a directory name or an assumption about the distribution. If command -v prints a user-managed path, check that installation separately before calling the host patched.

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

Package revisions vary, so your output will not necessarily match. The facts that matter are the package name, the distribution revision and the interpreter version. If the package database reports 5.38.0 while perl -e reports something else, stop and resolve the path or package mismatch before you update anything.

2. Read the local release note

Read the installed copy rather than trusting a search result. It is supplied by perl-doc and describes Perl 5.38.2 as the change from 5.38.0, explicitly skipping 5.38.1:

$ man perl5382delta
$ zcat /usr/share/man/man1/perl5382delta.1.gz | sed -n '/^\.SH Security/,/^\.SH Acknowledgements/p'

The first command is easier to read interactively, the second gives you a plain-text extract for an audit note. The compressed file is documentation, not an executable script, so do not pipe it to a shell or treat any text from it as a command.

3. Understand what 5.38.2 fixes

• CVE-2023-47038. A crafted regular expression with an illegal user-defined Unicode property could write one attacker-controlled byte beyond a heap buffer, in Perl 5.30.0 through 5.38.0. Worth patching even if your application does not deliberately use custom Unicode properties: regular expressions get reached through input-processing code and third-party modules all the time.
• CVE-2023-47039. Perl for Windows could search for cmd.exe in the current working directory before safer locations. An attacker who plants a malicious file in a weakly protected location could get arbitrary code run when an administrator launches Perl from there. Not a Linux execution path, but still relevant if the same software estate includes Windows workstations, build agents or administrators' laptops.

Do not try to reproduce either vulnerability on a production host. The point of this guide is verifying the installed version and package state, not compiling hostile regular expressions or dropping executables into searched directories.

4. Update through the package manager when needed

Interpreter older than 5.38.2, or your distribution marks the installed package vulnerable? Use the normal security-update workflow for that distribution. On Ubuntu or Debian, review available updates like this:

$ apt-cache policy perl perl-doc
$ apt list --upgradable 2>/dev/null | grep -E '^(perl|perl-doc)/'

These commands only inspect package metadata. Applying an update changes system files and may affect services that embed Perl, so schedule it through your host's maintenance process and keep a tested recovery path. Do not paste a version copied from another distribution into an apt command, let the configured repositories select the supported revision.

Once an update is approved, the administrative form is distribution-specific. For a Debian-family host it is commonly:

$ sudo apt update
$ sudo apt install --only-upgrade perl perl-doc

5. Verify after the change

Open a new shell or use the service's real execution context, then repeat the interpreter check:

$ command -v perl
/usr/bin/perl
$ perl -e 'printf "perl=%s\n", $^V'
perl=v5.38.2
$ perl -MConfig -e 'printf "arch=%s\n", $Config{archname}'
arch=x86_64-linux-gnu

The architecture line is a useful sanity check on a host with multiple Perl installations, but it does not replace the version check. For an application or service, verify the command it actually starts: a virtual environment, wrapper or hard-coded interpreter path can select a different binary entirely.

Confirm the documentation now agrees with the interpreter:

$ perldoc -l perl5382delta
/usr/share/perl/5.38/pod/perl5382delta.pod
$ perl -e 'die "old Perl\n" if $] < 5.038002; print "Perl version is in range\n"'
Perl version is in range

That numeric comparison is a local gate for Perl 5.38.2 and later. It does not claim every later Perl release behaves identically, and it does not replace your distribution's security advisory process.

6. Keep the result auditable

Save the command output, package revision and update transaction identifier in the host's normal change record, including which Perl paths you checked and whether Windows systems were in scope. If you find an older copy later, remove it from the relevant service or shell configuration through your normal change process, then repeat the checks. Do not delete a Perl installation while another application may depend on it.