CVE-2026-8594

What it actually does

Text::LineFold (shipped in Unicode-LineBreak) splits input on special line-break controls such as vertical tab and form feed, but still runs the break routine against the entire original string instead of each segment. The full input is therefore duplicated once per segment, causing unbounded growth in memory and CPU and a local denial of service. Confidentiality and integrity are not affected.

Why it matters to the business

Applications that wrap or fold text with this Perl module can hang, exhaust memory, or crash when they process text containing those controls, interrupting local services or batch jobs. The attack requires local input, is not in CISA KEV, is not tied to ransomware, has no known public exploit, and has a low, slightly declining exploitation probability, so urgency is moderate-low unless untrusted local text reaches a critical process.

How an attack unfolds

An attacker who can feed text into a local process that calls Text::LineFold includes multiple special line-break control characters. The library creates one segment per control but still folds the whole string for every segment, emitting the complete input repeatedly. Memory and CPU scale with input length times the number of special breaks until the process is starved or killed and the application becomes unavailable. No named threat actors or campaigns are associated with this issue.

How to fix it

Upgrade the Unicode-LineBreak distribution, which provides Text::LineFold; module versions through 2019.001 are affected and the distribution version may be higher than the module version. If a patched release is not yet deployed, strip or reject seldom-used break controls before folding, cap input length, run folding in a resource-limited worker, and do not pass untrusted local text into the module.

How to confirm the fix worked

Inventory Perl applications and CPAN/vendor trees for Text::LineFold at or below 2019.001 or an older Unicode-LineBreak that vendors that module. After upgrading, fold representative text that includes ordinary newlines plus a few special break characters and confirm output is not duplicated and resident memory stays bounded. Use cpan/cpanm metadata or a software bill of materials to verify the installed module and distribution versions.

Typical attack path

1. Obtain the ability to influence text processed locally by software that uses Text::LineFold (file, pipe, CLI, or local API).
2. Supply input that contains multiple special line-break control characters so many segments are created.
3. Invoke line-folding so the library duplicates the full input for each segment.
4. Drive memory and CPU high enough that the process slows, crashes, or is terminated by the operating system.

How to detect it

This is local resource exhaustion with no reported in-the-wild use. Hunt Perl processes that load Text::LineFold or Unicode::LineBreak for out-of-memory errors, OOM-killer events, core dumps, or unexplained RSS/CPU spikes while wrapping text. Review application logs around mail, reporting, or plain-text formatting that calls the module. Coincidence of those crashes with input containing unusual control characters is the main artifact; absent that, prior exploitation is unlikely.

• Text::LineFold
• Unicode::LineBreak
• Unicode-LineBreak
• perl: out of memory
• Out of memory: Kill process

What your security team should do

• Find hosts and applications that vendor Text::LineFold or Unicode-LineBreak and treat Text::LineFold through 2019.001 as exposed.
• Upgrade Unicode-LineBreak/Text::LineFold in the normal patch cycle unless the module processes untrusted local text on high-availability services; there is no KEV due date.
• Until patched, cap input size and strip special break controls on untrusted local paths.
• Watch Perl processes that perform text wrapping for sudden RSS or CPU spikes and OOM kills.
• Given exploit maturity of none and a declining EPSS, keep remotely exploitable issues ahead of this in the queue.