Audit Perl Regular Expressions Against the 5.30.3 Security Fixes

You will finish with a quick, evidence-based check for the regular-expression flaws fixed in Perl 5.30.3, a record of the Perl version actually running on your Linux host, and a clear next action for each affected application. Allow about 15 minutes for one host, plus however long your normal package change process takes.

You need a shell and access to the Perl installation. The inspection commands are ordinary user commands. Updating Perl is a separate, privileged change that can affect applications, so this guide does not run an upgrade for you.

1. Read the release note that applies to the problem

Start with the installed copy of perl5303delta(1). It describes the difference between Perl 5.30.2 and 5.30.3, rather than documenting every version of Perl:

$ perldoc -t perl5303delta | sed -n '1,100p'
NAME
    perl5303delta - what is new for perl v5.30.3

DESCRIPTION
    This document describes differences between the 5.30.2 release and the
    5.30.3 release.

Checkpoint: the document should identify the 5.30.2 to 5.30.3 boundary. If perldoc cannot find it, use the man page directly:

$ man perl5303delta

On this host the documentation comes from the Ubuntu perl-doc package version 5.38.2-3.2ubuntu0.6. That package version tells you which copy of the documentation you read; it does not mean that Perl 5.38.2 has the same release history as Perl 5.30.3.

2. Record the interpreter and package versions

Check the interpreter used by your shell, then check the Debian package state if this is a Debian-family system:

$ command -v perl
/usr/bin/perl
$ perl -e 'print "$^V\n"'
v5.38.2
$ perl -V:version
version='5.38.2';
$ 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 output may contain a different patch level. The first command matters because a locally installed Perl, a container interpreter or a virtual environment can be earlier in PATH than the system package you inspected.

Checkpoint: save the full path and version in the host or application maintenance record. Do not infer the Perl version from a module version or from the version of perl-doc.

3. Understand the three affected paths

The release note names three vulnerabilities in Perl's regular-expression compiler: CVE-2020-10543, CVE-2020-10878 and CVE-2020-12723. They involve integer calculations and compiler state while Perl compiles specially crafted expressions. The possible outcomes described by the note include a heap buffer overflow or corruption of the intermediate representation.

This is not a claim that every Perl program is exposed. The same note gives a narrower condition: an application needs to evaluate regular expressions supplied by an attacker. A fixed, developer-written pattern is a different risk from a pattern accepted through an HTTP request, job queue, configuration upload or plugin interface.

That boundary is easy to miss. Taint-style assumptions about the input source do not make an attacker-controlled pattern safe, and a regular expression can also consume excessive CPU even when it does not reach one of these memory-safety bugs.

Search application code and input contracts for dynamic pattern compilation. For a source tree, this is a read-only starting point:

$ rg -n --glob '*.pl' --glob '*.pm' --glob '*.t' \
    'qr\s*[\(\{]|\b(?:m|s|tr)\s*[^[:space:];=]' /path/to/application

Replace /path/to/application with the real source directory. Treat matches as review leads, not proof. Perl permits several regular-expression forms, and wrappers can hide compilation behind a module or an evaluated string.

4. Check the version used by the vulnerable workload

Run the same version check as the service account or deployment image that executes the application. A root shell is not required for this inspection:

$ sudo -u APP_USER command -v perl
$ sudo -u APP_USER perl -e 'print "$^V\n"'

Replace APP_USER with the account that runs the service. If that account cannot use sudo -u in your environment, run the two commands through the service's existing diagnostic or deployment mechanism. Do not add broad sudo access just to perform this check.

If the result is older than 5.30.3, or if you cannot map a vendor package to a patched Perl build, stop treating the host as cleared. Record the result and send it through your normal security update process. The release note covers a historical Perl branch; your vendor's supported package may contain the fix without reporting its version as exactly 5.30.3.

For a Debian-family package, inspect the installed and candidate versions without changing anything:

$ apt-cache policy perl perl-base
perl:
  Installed: 5.38.2-3.2ubuntu0.6
  Candidate: 5.38.2-3.2ubuntu0.6

A candidate is only a repository offer, not evidence that an update has been installed. If it differs from the installed version, follow your organisation's change procedure and check the package changelog or security advisory before scheduling a restart.

5. Verify the related core-module detail

The 5.30.3 note also records a Module::CoreList update, from 5.20200314 to 5.20200601_30. This is release metadata, not a substitute for checking the Perl interpreter's security level. You can see the module installed on the current machine with:

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

The value will vary as the distribution updates its core modules. Do not use it as a proxy for the three regex fixes. The interpreter package and the vendor's security update record are the evidence that matters.

6. Apply the update with a rollback plan

Updating Perl is a service-impacting change when long-running workers, CGI applications, system timers or packaged tools use it. Before an elevated package command, identify those consumers, take the approved backup or image, and arrange a maintenance window if required.

Do not copy an upgrade command from an unrelated distribution. Use the package manager and repository policy already approved for the host, then restart only the affected services. Capture the package transaction and re-run the checks in steps 2 and 4 afterwards.

There is no undo command in this guide because no package state is changed here. If a production update causes a regression, use the package manager's documented version rollback or restore the approved image, then re-test the application. Avoid deleting Perl files by hand: other system tools may depend on them.

7. Check application exposure separately

A patched interpreter does not fix an unsafe interface. If users can submit patterns, add an application-level decision about whether patterns are needed at all. Prefer a constrained search syntax or a fixed set of server-side patterns. If full regular expressions are required, impose input size and execution limits appropriate to the application, reject unexpected constructs where practical, and test failure handling.

Test this in a disposable environment with representative inputs. Do not paste proof-of-concept exploit strings into a production service. The release note explicitly warns that attacker-supplied expressions are also a denial-of-service concern, so a version check and an application review belong in the same ticket.