CVE-2026-8376

What it actually does

Perl versions through 5.43.10 on 32-bit builds can corrupt heap memory while compiling certain regular expressions. The vulnerable code calculates the size of a repeated fixed-string buffer in characters instead of bytes; with a large quantifier, the multiplication can overflow an internal signed size type, causing Perl to allocate too small a buffer and then copy data past its end. If an application compiles attacker-controlled regular expressions, exploitation occurs at regex compile time and can lead to process crash, memory corruption, and potentially arbitrary code execution in the context of the Perl process.

Why it matters to the business

Applications, automation, security tooling, or services that run 32-bit Perl and accept user-supplied regular expressions may be remotely crashed or potentially taken over. Successful exploitation could interrupt business services, corrupt application state, expose sensitive data processed by the Perl application, or provide a foothold for further compromise. Although the CVSS score is critical, the current EPSS is low, it is not listed in CISA KEV, and no public exploit maturity is reported, so urgency should be driven by whether 32-bit Perl is used in externally reachable or multi-tenant workflows that compile untrusted regex input.

How an attack unfolds

An attacker first identifies an application, API, search feature, filter builder, validation rule, log-processing interface, or administrative tool that passes user-controlled regular expressions to Perl. They submit a crafted regular expression containing a repeated fixed string with a very large minimum repetition count. On a vulnerable 32-bit Perl build, regex compilation reaches Perl_study_chunk in regcomp_study.c, where the joined substring length calculation overflows. Perl allocates an undersized heap buffer and then writes beyond the allocation while preparing the compiled regex. The most likely observable result is a crash of the Perl process, but because this is heap memory corruption, a reliable exploit may be able to influence control flow and execute code with the privileges of the affected service account.

How to fix it

Upgrade Perl to a vendor release that contains the fix as soon as one is available from the relevant OS distribution, language runtime vendor, container base image, or appliance supplier. Because no fixed versions were provided in the input, track upstream Perl and downstream distribution advisories for the exact patched package version. Prioritize removal of 32-bit Perl runtimes where possible, since the described overflow is specific to 32-bit builds. As mitigations, do not compile untrusted regular expressions; replace user-supplied regex with allowlisted search operators; enforce strict length and quantifier limits; reject expressions with very large repetition counts; run regex compilation in a sandboxed, low-privilege worker with resource limits; and isolate or disable externally reachable features that accept arbitrary regex input until patched.

How to confirm the fix worked

Inventory Perl versions and architecture across hosts, containers, build images, appliances, and embedded runtimes. Confirm whether any Perl runtime is 32-bit and at or below 5.43.10. Validate that applications do not pass untrusted input directly to regex compilation, especially via eval, qr//, m//, s///, split, grep/map filters, search forms, rule engines, or log-processing pipelines. After patching, verify the runtime reports the expected vendor-fixed package version and rerun a safe negative test using oversized regex quantifiers in a non-production environment to confirm the process no longer crashes. For containers, confirm base images were rebuilt and redeployed rather than only patched on the host.

Typical attack path

1. Find an exposed application or service that uses Perl and accepts user-controlled regular expressions.
2. Confirm or infer that the runtime is a vulnerable 32-bit Perl build through banners, error behavior, package metadata, platform architecture, or testing.
3. Submit a crafted regex containing a fixed substring with an extremely large repetition minimum.
4. Trigger Perl regex compilation in the vulnerable code path.
5. Cause integer-size overflow, undersized heap allocation, and out-of-bounds heap write during compilation.
6. Crash the Perl process or, with a more advanced payload, attempt code execution in the context of the Perl application.

How to detect it

Look for evidence that untrusted regex input caused crashes or memory corruption in Perl processes. Relevant sources include application logs, web/API access logs, reverse proxy logs, systemd journal, syslog, kernel logs, container runtime logs, EDR telemetry, core dump metadata, crash reporters, and package/runtime inventory. Search for Perl processes terminating with SIGSEGV, SIGABRT, heap corruption, allocator errors, or core dumps shortly after requests containing unusually large regex repetition counts such as very large values inside braces. Review request parameters commonly named regex, regexp, pattern, filter, query, search, rule, expression, or match. If core dumps are available, inspect stack traces for Perl regex compilation functions such as Perl_regcomp, Perl_re_op_compile, Perl_study_chunk, or regcomp_study.c. Absence of these artifacts does not prove non-exploitation, because a failed or successful exploit may leave only a process crash or normal-looking application request.

• Perl_study_chunk
• regcomp_study.c
• Perl_regcomp
• Perl_re_op_compile
• perl: segfault
• perl.*SIGSEGV
• perl.*SIGABRT
• malloc(): corrupted top size
• malloc(): invalid size
• corrupted size vs. prev_size
• double free or corruption
• free(): invalid next size
• core dumped
• /var/lib/systemd/coredump/core.perl
• /var/crash/*perl*
• /var/log/apport.log
• AddressSanitizer: heap-buffer-overflow
• heap-buffer-overflow in Perl_study_chunk
• regex
• regexp
• pattern
• filter
• expression

What your security team should do

• Immediately inventory 32-bit Perl installations and prioritize internet-facing, API-facing, multi-tenant, or automation-heavy systems.
• Identify application features that compile user-supplied regular expressions and disable or constrain them until patched.
• Upgrade Perl through official vendor packages once a fixed build is available; rebuild containers and redeploy dependent services.
• If patching is delayed, migrate affected workloads to supported 64-bit Perl builds where feasible and apply regex length, quantifier, and complexity limits.
• Run affected Perl services with least privilege, memory-safety hardening where available, process supervision, crash isolation, and sandboxing.
• Add monitoring for Perl process crashes, segmentation faults, allocator corruption messages, and unusual regex-heavy request patterns.
• Because this is not currently KEV-listed and EPSS is low, prioritize based on exposure: externally reachable untrusted regex compilation should be treated as urgent, while internal-only trusted regex use is lower risk.