Security Advisories (4)
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-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-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-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.

NAME

TAP::Parser::IteratorFactory - Figures out which SourceHandler objects to use for a given Source

VERSION

Version 3.50

SYNOPSIS

use TAP::Parser::IteratorFactory;
my $factory = TAP::Parser::IteratorFactory->new({ %config });
my $iterator  = $factory->make_iterator( $filename );

DESCRIPTION

This is a factory class that takes a TAP::Parser::Source and runs it through all the registered TAP::Parser::SourceHandlers to see which one should handle the source.

If you're a plugin author, you'll be interested in how to "register_handler"s, how "detect_source" works.

METHODS

Class Methods

new

Creates a new factory class:

my $sf = TAP::Parser::IteratorFactory->new( $config );

$config is optional. If given, sets "config" and calls "load_handlers".

register_handler

Registers a new TAP::Parser::SourceHandler with this factory.

__PACKAGE__->register_handler( $handler_class );

handlers

List of handlers that have been registered.

Instance Methods

config

my $cfg = $sf->config;
$sf->config({ Perl => { %config } });

Chaining getter/setter for the configuration of the available source handlers. This is a hashref keyed on handler class whose values contain config to be passed onto the handlers during detection & creation. Class names may be fully qualified or abbreviated, eg:

# these are equivalent
$sf->config({ 'TAP::Parser::SourceHandler::Perl' => { %config } });
$sf->config({ 'Perl' => { %config } });

load_handlers

$sf->load_handlers;

Loads the handler classes defined in "config". For example, given a config:

$sf->config({
  MySourceHandler => { some => 'config' },
});

load_handlers will attempt to load the MySourceHandler class by looking in @INC for it in this order:

TAP::Parser::SourceHandler::MySourceHandler
MySourceHandler

croaks on error.

make_iterator

my $iterator = $src_factory->make_iterator( $source );

Given a TAP::Parser::Source, finds the most suitable TAP::Parser::SourceHandler to use to create a TAP::Parser::Iterator (see "detect_source"). Dies on error.

detect_source

Given a TAP::Parser::Source, detects what kind of source it is and returns one TAP::Parser::SourceHandler (the most confident one). Dies on error.

The detection algorithm works something like this:

for (@registered_handlers) {
  # ask them how confident they are about handling this source
  $confidence{$handler} = $handler->can_handle( $source )
}
# choose the most confident handler

Ties are handled by choosing the first handler.

SUBCLASSING

Please see "SUBCLASSING" in TAP::Parser for a subclassing overview.

Example

If we've done things right, you'll probably want to write a new source, rather than sub-classing this (see TAP::Parser::SourceHandler for that).

But in case you find the need to...

package MyIteratorFactory;

use strict;

use base 'TAP::Parser::IteratorFactory';

# override source detection algorithm
sub detect_source {
  my ($self, $raw_source_ref, $meta) = @_;
  # do detective work, using $meta and whatever else...
}

1;

AUTHORS

Steve Purkis

ATTRIBUTION

Originally ripped off from Test::Harness.

Moved out of TAP::Parser & converted to a factory class to support extensible TAP source detective work by Steve Purkis.

SEE ALSO

TAP::Object, TAP::Parser, TAP::Parser::SourceHandler, TAP::Parser::SourceHandler::File, TAP::Parser::SourceHandler::Perl, TAP::Parser::SourceHandler::RawTAP, TAP::Parser::SourceHandler::Handle, TAP::Parser::SourceHandler::Executable