Audit a Perl 5.36.3 Upgrade with perl5363delta

Perl 5.36.2 was broken and briefly pulled, which makes perl5363delta an odd document to read cold. This guide turns it into a short upgrade audit instead: identify the release range it actually covers, check the interpreter and documentation installed on this Linux host, and decide whether its two security fixes are relevant to your deployment. Allow about fifteen minutes. You need a shell and the perl-doc package; reviewing the document needs no elevated privileges.

1. Confirm what the document covers

Start by reading the installed manual page, the primary source for this guide, supplied by perl-doc:

$ man perl5363delta

The document describes differences between Perl 5.36.1 and Perl 5.36.3. It deliberately skips 5.36.2, which the document itself calls a broken release that existed briefly. Coming from 5.36.0? Read perl5361delta as well, this page is not a complete 5.36 upgrade history on its own.

You can find the underlying pod file without opening a pager:

$ perldoc -l perl5363delta
/usr/share/perl/5.38/pod/perl5363delta.pod

Your path can differ; the useful result is a readable path and a matching manual entry. If perldoc cannot find it, install the documentation package through your distribution's approved package source. Do not copy a random pod file into /usr/share.

2. Record the interpreter version separately

The release named by a delta document and the interpreter actually running your application are two different facts. Check both the human-readable version and the package version:

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

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

These exact package values are host-specific: another Debian-family system may show a different revision, and an RPM-based system needs its own package query tool. What matters is whether the interpreter falls in the vulnerable 5.30.0 through 5.38.0 range the manual mentions, or whether your distributor has already backported a fix into a later revision.

$ command -v perl
/usr/bin/perl
$ /usr/bin/perl -MConfig -e 'print "$Config{version}\n"'
5.38.2

3. Understand the security findings

• CVE-2023-47038. A one-byte attacker-controlled heap buffer overflow when a crafted regular expression containing an illegal user-defined Unicode property is compiled, affecting Perl 5.30.0 through 5.38.0. Treat any attacker-supplied regular expression as untrusted input, especially when an application compiles it rather than matching against a fixed pattern.
• CVE-2023-47039. Perl for Windows searches for cmd.exe in the current working directory before the intended system location, letting a malicious executable in a weakly protected location run when an administrator launches a Windows-Perl program. Not a Linux kernel or path-search change, but still worth tracking if the same application or deployment process runs on Windows.

Do not try to reproduce either vulnerability on a production host. A clean regular-expression smoke test only proves your interpreter can compile an ordinary pattern, it does not prove a security fix is present:

$ perl -e 'my $re = qr/\p{IsGreek}/; print "regex compile ok\n"'
regex compile ok

4. Choose the upgrade action

Package manager reporting an older vulnerable Perl? Schedule the vendor's supported update, but identify consumers first since package updates can change the interpreter services actually use:

$ rg -n '(^|[[:space:]/])perl([[:space:]]|$)' /etc/systemd /etc/cron* /usr/local/bin 2>/dev/null

This search is read-only and may report nothing. Also check service unit files and deployment manifests in their actual locations, do not assume every Perl process launches from /usr/local/bin. If a service needs a restart, use its maintenance window and keep the previous package and configuration rollback procedure available.

Updating packages is the point where elevated privileges may be needed. The exact command is distribution-specific, so use your configured security repository rather than an unverified command pasted from elsewhere. Do not remove the old interpreter by hand, another package or service may still depend on it.

After the update, repeat the version checks and run the application's own test suite. A newer number from perl -v alone does not verify a package update, confirm the service is using the intended path and that its dependencies still load.

5. Handle common reading errors

• Confusing documentation with installation. perl5363delta reports changes, it does not select a package, patch a binary or restart a service.
• Checking only the major release. Compare the full version, including subversion and vendor package revision. A distributor can backport a security patch without changing the upstream-looking version the way you expect.
• Assuming Linux scope. The Windows binary-hijacking issue applies to Windows Perl only. The Unicode-property issue concerns the interpreter itself and can affect more than one operating system.
• Testing only from your login shell. Services and scheduled jobs can resolve a different interpreter. Check the executable in the actual unit, wrapper or container that runs the application.