/ 
perl-5.34.0-RC1
⭐ Starred 2013 / XSLoader
Security Advisories (10)
CVE-2024-56406 (2025-04-13)

A heap buffer overflow vulnerability was discovered in Perl. Release branches 5.34, 5.36, 5.38 and 5.40 are affected, including development versions from 5.33.1 through 5.41.10. When there are non-ASCII bytes in the left-hand-side of the `tr` operator, `S_do_trans_invmap` can overflow the destination pointer `d`.    $ perl -e '$_ = "\x{FF}" x 1000000; tr/\xFF/\x{100}/;'    Segmentation fault (core dumped) It is believed that this vulnerability can enable Denial of Service and possibly Code Execution attacks on platforms that lack sufficient defenses.

CVE-2022-48522 (2023-08-22)

In Perl 5.34.0, function S_find_uninit_var in sv.c has a stack-based crash that can lead to remote code execution or local privilege escalation.

CVE-2023-47038 (2023-10-30)

A crafted regular expression when compiled by perl 5.30.0 through 5.38.0 can cause a one attacker controlled byte buffer overflow in a heap allocated buffer

CVE-2026-57432 (2026-07-13)

Perl versions through 5.43.10 have an integer overflow in S_measure_struct leading to an out-of-bounds heap read in pack and unpack. S_measure_struct adds each item's size times its repeat count to a running total with no overflow check, so a large repeat count in a pack or unpack template wraps the signed SSize_t total negative. The @, X, and x position codes then guard their moves with a signed length comparison that passes when the length is negative, advancing the buffer pointer out of bounds. A template derived from untrusted input can read heap memory past the buffer and return it to the caller.

CVE-2025-40909 (2025-05-30)

Perl threads have a working directory race condition where file operations may target unintended paths. If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running. This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit. The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6

CVE-2026-13221 (2026-07-13)

Perl versions through 5.43.9 produce silently incorrect regular expression matches when an alternation of more than 65535 fixed string branches is compiled into a trie in Perl_study_chunk. When such branches are combined into a trie, the delta between the first branch and the shared tail is stored in a 16-bit field. A branch count above 65535 overflows the field, and the trie's match decision table is truncated with no warning or error. A pattern of this shape produces false positive matches (matching strings it should not) and false negative matches (failing to match strings it should). When such a pattern gates an access or filtering decision, the result is wrong.

CVE-2026-4176 (2026-03-29)

Perl versions from 5.9.4 before 5.40.4-RC1, from 5.41.0 before 5.42.2-RC1, from 5.43.0 before 5.43.9 contain a vulnerable version of Compress::Raw::Zlib. Compress::Raw::Zlib is included in the Perl package as a dual-life core module, and is vulnerable to CVE-2026-3381 due to a vendored version of zlib which has several vulnerabilities, including CVE-2026-27171. The bundled Compress::Raw::Zlib was updated to version 2.221 in Perl blead commit c75ae9cc164205e1b6d6dbd57bd2c65c8593fe94.

CVE-2026-8376 (2026-05-25)

Perl versions through 5.43.10 have a heap buffer overflow when compiling regular expressions with a repeated fixed string on 32-bit builds. Perl_study_chunk in regcomp_study.c checked the size of the joined substring buffer in characters rather than bytes. For a quantified fixed substring with a large minimum count, the byte length mincount * l could overflow SSize_t, producing an undersized SvGROW allocation; the subsequent copy writes past the end of the buffer. A caller that compiles an attacker-controlled regular expression on a 32-bit perl build triggers a heap buffer overflow at compile time.

CVE-2023-47039 (2023-10-30)

Perl for Windows relies on the system path environment variable to find the shell (cmd.exe). When running an executable which uses Windows Perl interpreter, Perl attempts to find and execute cmd.exe within the operating system. However, due to path search order issues, Perl initially looks for cmd.exe in the current working directory. An attacker with limited privileges can exploit this behavior by placing cmd.exe in locations with weak permissions, such as C:\ProgramData. By doing so, when an administrator attempts to use this executable from these compromised locations, arbitrary code can be executed.

CVE-2023-47100

In Perl before 5.38.2, S_parse_uniprop_string in regcomp.c can write to unallocated space because a property name associated with a \p{...} regular expression construct is mishandled. The earliest affected version is 5.30.0.

NAME

XSLoader - Dynamically load C libraries into Perl code

VERSION

Version 0.30

SYNOPSIS

package YourPackage;
require XSLoader;

XSLoader::load(__PACKAGE__, $VERSION);

DESCRIPTION

This module defines a standard simplified interface to the dynamic linking mechanisms available on many platforms. Its primary purpose is to implement cheap automatic dynamic loading of Perl modules.

For a more complicated interface, see DynaLoader. Many (most) features of DynaLoader are not implemented in XSLoader, like for example the dl_load_flags, not honored by XSLoader.

Migration from DynaLoader

A typical module using DynaLoader starts like this:

package YourPackage;
require DynaLoader;

our @ISA = qw( OnePackage OtherPackage DynaLoader );
our $VERSION = '0.01';
__PACKAGE__->bootstrap($VERSION);

Change this to

package YourPackage;
use XSLoader;

our @ISA = qw( OnePackage OtherPackage );
our $VERSION = '0.01';
XSLoader::load(__PACKAGE__, $VERSION);

In other words: replace require DynaLoader by use XSLoader, remove DynaLoader from @ISA, change bootstrap by XSLoader::load. Do not forget to quote the name of your package on the XSLoader::load line, and add comma (,) before the arguments ($VERSION above).

Of course, if @ISA contained only DynaLoader, there is no need to have the @ISA assignment at all; moreover, if instead of our one uses the more backward-compatible

use vars qw($VERSION @ISA);

one can remove this reference to @ISA together with the @ISA assignment.

If no $VERSION was specified on the bootstrap line, the last line becomes

XSLoader::load(__PACKAGE__);

in which case it can be further simplified to

XSLoader::load();

as load will use caller to determine the package.

Backward compatible boilerplate

If you want to have your cake and eat it too, you need a more complicated boilerplate.

    package YourPackage;

    our @ISA = qw( OnePackage OtherPackage );
    our $VERSION = '0.01';
    eval {
       require XSLoader;
	XSLoader::load(__PACKAGE__, $VERSION);
       1;
    } or do {
       require DynaLoader;
       push @ISA, 'DynaLoader';
       __PACKAGE__->bootstrap($VERSION);
    };

The parentheses about XSLoader::load() arguments are needed since we replaced use XSLoader by require, so the compiler does not know that a function XSLoader::load() is present.

This boilerplate uses the low-overhead XSLoader if present; if used with an antique Perl which has no XSLoader, it falls back to using DynaLoader.

Order of initialization: early load()

Skip this section if the XSUB functions are supposed to be called from other modules only; read it only if you call your XSUBs from the code in your module, or have a BOOT: section in your XS file (see "The BOOT: Keyword" in perlxs). What is described here is equally applicable to the DynaLoader interface.

A sufficiently complicated module using XS would have both Perl code (defined in YourPackage.pm) and XS code (defined in YourPackage.xs). If this Perl code makes calls into this XS code, and/or this XS code makes calls to the Perl code, one should be careful with the order of initialization.

The call to XSLoader::load() (or bootstrap()) calls the module's bootstrap code. For modules build by xsubpp (nearly all modules) this has three side effects:

  • A sanity check is done to ensure that the versions of the .pm and the (compiled) .xs parts are compatible. If $VERSION was specified, this is used for the check. If not specified, it defaults to $XS_VERSION // $VERSION (in the module's namespace)

  • the XSUBs are made accessible from Perl

  • if a BOOT: section was present in the .xs file, the code there is called.

Consequently, if the code in the .pm file makes calls to these XSUBs, it is convenient to have XSUBs installed before the Perl code is defined; for example, this makes prototypes for XSUBs visible to this Perl code. Alternatively, if the BOOT: section makes calls to Perl functions (or uses Perl variables) defined in the .pm file, they must be defined prior to the call to XSLoader::load() (or bootstrap()).

The first situation being much more frequent, it makes sense to rewrite the boilerplate as

package YourPackage;
use XSLoader;
our ($VERSION, @ISA);

BEGIN {
   @ISA = qw( OnePackage OtherPackage );
   $VERSION = '0.01';

   # Put Perl code used in the BOOT: section here

   XSLoader::load(__PACKAGE__, $VERSION);
}

# Put Perl code making calls into XSUBs here

The most hairy case

If the interdependence of your BOOT: section and Perl code is more complicated than this (e.g., the BOOT: section makes calls to Perl functions which make calls to XSUBs with prototypes), get rid of the BOOT: section altogether. Replace it with a function onBOOT(), and call it like this:

package YourPackage;
use XSLoader;
our ($VERSION, @ISA);

BEGIN {
   @ISA = qw( OnePackage OtherPackage );
   $VERSION = '0.01';
   XSLoader::load(__PACKAGE__, $VERSION);
}

# Put Perl code used in onBOOT() function here; calls to XSUBs are
# prototype-checked.

onBOOT;

# Put Perl initialization code assuming that XS is initialized here

DIAGNOSTICS

Can't find '%s' symbol in %s

(F) The bootstrap symbol could not be found in the extension module.

Can't load '%s' for module %s: %s

(F) The loading or initialisation of the extension module failed. The detailed error follows.

Undefined symbols present after loading %s: %s

(W) As the message says, some symbols stay undefined although the extension module was correctly loaded and initialised. The list of undefined symbols follows.

LIMITATIONS

To reduce the overhead as much as possible, only one possible location is checked to find the extension DLL (this location is where make install would put the DLL). If not found, the search for the DLL is transparently delegated to DynaLoader, which looks for the DLL along the @INC list.

In particular, this is applicable to the structure of @INC used for testing not-yet-installed extensions. This means that running uninstalled extensions may have much more overhead than running the same extensions after make install.

KNOWN BUGS

The new simpler way to call XSLoader::load() with no arguments at all does not work on Perl 5.8.4 and 5.8.5.

BUGS

Please report any bugs or feature requests via the perlbug(1) utility.

SEE ALSO

DynaLoader

AUTHORS

Ilya Zakharevich originally extracted XSLoader from DynaLoader.

CPAN version is currently maintained by Sébastien Aperghis-Tramoni <sebastien@aperghis.net>.

Previous maintainer was Michael G Schwern <schwern@pobox.com>.

COPYRIGHT & LICENSE

Copyright (C) 1990-2011 by Larry Wall and others.

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.