Perl 5.26.2: Check Security Fixes and Compatibility Changes
You will finish with a short, repeatable review for a Perl 5.26.2 upgrade: identify the installed interpreter, read the local release notes, check the security-relevant fixes, and test the behaviours most likely to affect a deployment. The notes describe the differences between Perl 5.26.1 and 5.26.2, so they are an upgrade aid rather than a general Perl manual.
The route
Jump straight to the step you need, or tick off Done means at the end.
Allow about 20 minutes for a normal host, longer if you need to rebuild applications or investigate a package mismatch. You need a shell and the perl and perl5262delta commands. The examples only inspect files and run small, harmless programs. They do not replace the system interpreter or alter installed packages.
1. Confirm which Perl you are reviewing
Start by checking the executable found through your current PATH and its full version:
$ command -v perl
/usr/bin/perl
$ perl -V:version -V:patchlevel
version='5.38.2';
patchlevel='38';
The output above is from the current machine, where the installed interpreter is Perl 5.38.2. It is not evidence that Perl 5.26.2 is installed. The release note can still be useful when you are checking an older application, a build artefact, or a package change, but keep the version distinction visible in your change record.
Checkpoint: record the path and version before reading the notes. If command -v perl points into a virtual environment or an application directory, inspect that interpreter rather than assuming that /usr/bin/perl is the one in use.
2. Read the local 5.26.2 release note
Use the installed manpage as the primary reference:
$ man perl5262delta
$ zcat /usr/share/man/man1/perl5262delta.1.gz | sed -n '1,80p'
The local page identifies itself as perl5262delta - what is new for perl v5.26.2. It says that 5.26.2 differs from 5.26.1, and directs readers upgrading from 5.26.0 to read perl5261delta first. That sequencing matters: a delta page is not a cumulative list of every change since the first release in the series.
On this machine the compressed source is supplied by the perl-doc package, version 5.38.2-3.2ubuntu0.6. That package version describes the documentation package currently installed, not the Perl release documented by the page.
3. Check the security section first
The 5.26.2 notes list three heap-buffer-overflow fixes and one assertion-failure fix. The affected areas are regular-expression compilation, locale-dependent regular-expression matching, pack() with a large item count, and Unicode property-name handling:
- CVE-2018-6797: a crafted regular expression could cause a heap buffer write overflow in
S_regatom. - CVE-2018-6798: a crafted locale-dependent regular expression could cause a heap buffer read overflow and possible information disclosure in
Perl__byte_dump_string. - CVE-2018-6913:
pack()could cause a heap buffer write overflow with a large item count. - Control characters in a supposed Unicode property name could cause an assertion failure and crash Perl.
These are input-handling issues. A service that accepts regular expressions, locale-sensitive text, or data passed to pack() deserves more attention than a private script that only processes fixed input. Do not try to reproduce the malformed inputs in production just to prove a patch. Instead, check the package changelog or vendor security notice for the host, then run the application's normal test suite after upgrading.
Checkpoint: if a host still runs Perl 5.26.1 or an earlier affected build, treat that as an upgrade decision, not as a reason to weaken input validation. The release note does not claim that every Perl 5.26.2 problem is security-related, nor that upgrading it fixes vulnerabilities in CPAN modules or in the application itself.
4. Check compatibility before scheduling the upgrade
The release note says there are no changes intentionally incompatible with 5.26.1. That is reassuring, but it is not a substitute for testing. It also lists fixes in parsing, regular-expression compilation, reference counting during sort, and the compile-time handling of readpipe(). A program that previously relied on a crash, undefined behaviour, or a parser quirk may behave differently after the fix.
Use a disposable working directory for a small smoke test. This command creates no files outside that directory and needs no elevated privileges:
$ workdir=$(mktemp -d)
$ trap 'rm -rf "$workdir"' EXIT
$ cat > "$workdir/smoke.pl" <<'PERL'
use strict;
use warnings;
my @values = (3, 1, 2);
print join(',', sort { $a <=> $b } @values), "\n";
PERL
$ perl "$workdir/smoke.pl"
1,2,3
The temporary directory is removed when the shell exits. If your project has a test command, run that as the meaningful compatibility check. Preserve failures and logs before the trap removes only this scratch directory.
5. Review the smaller changes that can mislead an audit
Several entries are documentation or packaging details rather than new command-line features. Four core modules are updated: Module::CoreList, PerlIO::via, Term::ReadLine, and Unicode::UCD. The documentation also records that the Unicode Word property includes Join_Control, including U+200C and U+200D. Do not infer from that note that your application has changed its Unicode policy automatically.
Platform notes mention improved Visual C++ compiler detection on non-English Windows systems and a corrected $Config{libpth} for some 64-bit builds using older Visual C++ versions. Those entries are relevant to Windows builds, not a reason to add Linux linker flags or alter a Linux service.
6. Verify the package state and record the result
On Debian or Ubuntu, identify the package owning the interpreter and its installed version:
$ dpkg-query -S /usr/bin/perl
perl-base: /usr/bin/perl
$ 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
Your output will differ on another release. If the paths or package versions do not match the interpreter checked in step 1, stop and resolve that ambiguity before declaring the upgrade complete. Package upgrades require the normal administrator approval and maintenance process; none of the commands in this guide needs sudo.
There is no undo action for the read-only checks or the temporary smoke test. To recover from a real package upgrade, use the distribution's documented package rollback or reinstall process and the application's tested deployment procedure. Do not manually copy an old perl binary over the package-managed one.
Done means
- You recorded the interpreter path and actual Perl version.
- You read the local 5.26.2 delta and checked the preceding delta when upgrading from 5.26.0.
- You reviewed the three named CVEs and the Unicode assertion fix.
- You treated the no-intentional-incompatibility statement as a starting point for tests, not a guarantee.
- Your application's test suite passes on the interpreter that will run in production.
- You kept package changes separate from harmless inspection commands and scratch files.