CVE-2026-82560

What it actually does

Pod::Text before 6.1.1 can enter a non-terminating wrap() loop when formatting POD whose nested =over directives grow the indent until remaining line width is zero. The line-splitting substitution then matches the empty string, consumes no input, and appends margin padding on every iteration, driving unbounded CPU use and output growth until the process is OOM-killed or otherwise stopped. Confidentiality and integrity are not affected; impact is availability of the formatter process and, if unconstrained, the host.

Why it matters to the business

Any service, CI job, or documentation pipeline that formats untrusted POD with a vulnerable Pod::Text can be hung or memory-exhausted, causing request timeouts, failed builds, worker starvation, and possible node-level outages. The issue is a high-availability DoS (CVSS 7.5), published about two weeks ago, not listed in CISA KEV, not associated with ransomware, and has no reported in-the-wild exploitation—so urgency is driven by exposure of internet-facing or multi-tenant POD formatters rather than active campaigns.

How an attack unfolds

An attacker who can supply a POD document to a consumer of Pod::Text (web upload, ticket/docs pipeline, CPAN-style renderer, or automated pod2text) crafts excessive =over nesting so accumulated indent equals the output width. Formatting never returns: wrap() loops on a zero-width line, CPU pegs, and the growing padded output fills memory until the process or host fails. No authentication or user interaction is required when the formatter is network-reachable, and no code execution or data theft follows—only denial of service.

How to fix it

Upgrade Pod::Text to 6.1.1 or later everywhere it is installed (system Perl, perlbrew/plenv, vendored lib, containers, and CI images). Until upgraded, do not format untrusted POD; isolate remaining formatters with CPU/memory cgroups, process timeouts, and output-size caps; reject or pre-scan POD that uses extreme =over nesting; and prefer running pod2text/Pod::Text in a disposable sandbox rather than in the main application process.

How to confirm the fix worked

Inventory Perl installs and confirm the Pod::Text (podlators) package reports 6.1.1 or newer (e.g., cpan, OS package manager, or `perl -MPod::Text -e 'print $Pod::Text::VERSION'`). Re-run documentation and CI jobs that previously formatted POD and confirm they complete within normal time and memory. After change control, watch formatter latency, worker restarts, and OOM events to ensure the hang class is gone. Do not use production traffic or unbounded documents as the sole test.

Typical attack path

1. Locate an application, CI renderer, or CLI wrapper that formats caller-controlled POD with Pod::Text older than 6.1.1.
2. Submit or fetch a POD document whose =over nesting drives remaining wrap width to zero.
3. Trigger formatting (HTTP handler, worker, pod2text, or equivalent).
4. Wait for the formatter to loop, exhaust CPU/RAM, and become unresponsive or be OOM-killed.
5. Repeat or fan out against multiple workers to amplify outage if no request timeouts or cgroups are in place.

How to detect it

There is no public exploit campaign or named actor for this issue, so hunt for symptoms of a hung formatter rather than a unique payload signature. Review application and web logs for POD upload or render requests that never complete; process accounting and container metrics for perl or pod2text with sustained 100% CPU and climbing RSS; kernel/journal OOM killer events targeting perl; worker/orchestrator restarts and 502/504 spikes on documentation endpoints; and CI logs where POD formatting steps hang until timeout. Preserve the input document associated with a hung job for offline analysis in an isolated environment. Absence of these signals does not prove the bug was never triggered if logging is sparse.

• pod2text
• Pod::Text
• perl process OOM
• =over

What your security team should do

• Patch Pod::Text to 6.1.1+ on all hosts, images, and developer toolchains that format POD, treating internet-facing and CI renderers as first priority.
• Identify and inventory every path that accepts external POD (uploads, webhooks, ticket systems, doc sites, CPAN mirrors) and disable or sandbox those paths until patched.
• Enforce CPU, memory, wall-clock, and output-size limits on remaining Perl documentation workers.
• Add WAF/app checks that reject or quarantine POD with pathological =over depth rather than passing it to the formatter.
• Monitor for hung perl/pod2text processes and OOM kills as a stopgap detection control while patches roll out.