Security Advisories (7)
CVE-2020-10878 (2020-06-05)

Perl before 5.30.3 has an integer overflow related to mishandling of a "PL_regkind[OP(n)] == NOTHING" situation. A crafted regular expression could lead to malformed bytecode with a possibility of instruction injection.

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.

CVE-2020-12723 (2020-06-05)

regcomp.c in Perl before 5.30.3 allows a buffer overflow via a crafted regular expression because of recursive S_study_chunk calls.

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-2020-10543 (2020-06-05)

Perl before 5.30.3 on 32-bit platforms allows a heap-based buffer overflow because nested regular expression quantifiers have an integer overflow.

CVE-2018-6798 (2018-04-17)

An issue was discovered in Perl 5.22 through 5.26. Matching a crafted locale dependent regular expression can cause a heap-based buffer over-read and potentially information disclosure.

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.

NAME

TAP::Parser::Multiplexer - Multiplex multiple TAP::Parsers

VERSION

Version 3.42

SYNOPSIS

use TAP::Parser::Multiplexer;

my $mux = TAP::Parser::Multiplexer->new;
$mux->add( $parser1, $stash1 );
$mux->add( $parser2, $stash2 );
while ( my ( $parser, $stash, $result ) = $mux->next ) {
    # do stuff
}

DESCRIPTION

TAP::Parser::Multiplexer gathers input from multiple TAP::Parsers. Internally it calls select on the input file handles for those parsers to wait for one or more of them to have input available.

See TAP::Harness for an example of its use.

METHODS

Class Methods

new

my $mux = TAP::Parser::Multiplexer->new;

Returns a new TAP::Parser::Multiplexer object.

Instance Methods

add

$mux->add( $parser, $stash );

Add a TAP::Parser to the multiplexer. $stash is an optional opaque reference that will be returned from next along with the parser and the next result.

parsers

my $count   = $mux->parsers;

Returns the number of parsers. Parsers are removed from the multiplexer when their input is exhausted.

next

Return a result from the next available parser. Returns a list containing the parser from which the result came, the stash that corresponds with that parser and the result.

my ( $parser, $stash, $result ) = $mux->next;

If $result is undefined the corresponding parser has reached the end of its input (and will automatically be removed from the multiplexer).

When all parsers are exhausted an empty list will be returned.

if ( my ( $parser, $stash, $result ) = $mux->next ) {
    if ( ! defined $result ) {
        # End of this parser
    }
    else {
        # Process result
    }
}
else {
    # All parsers finished
}

See Also

TAP::Parser

TAP::Harness