CVE-2026-8829

What it actually does

A use-after-free in the XS implementation of HTML::Entities::_decode_entities (versions before 3.84) can read already-freed heap memory and copy it into the decoded output scalar. The decoder caches a pointer (repl) into an entity-value SV obtained from hv_fetch on the entity2char hash. When the input SV is the same object as a hash value and that value contains its own key as an entity reference, a later grow_gap() reallocates the SV PV buffer, freeing the allocation that repl still references. The following copy loop then reads repl_len bytes from freed memory, which may disclose adjacent heap contents (other request data, secrets, or allocator metadata) into the destination string. Impact is confidentiality-only: no integrity or availability effect is indicated.

Why it matters to the business

Any Perl service that decodes untrusted HTML entities (web apps, email/HTML processors, templating, scrapers, CGI/PSGI) can leak in-process secrets to a remote, unauthenticated caller. The issue is 117 days old, is not in CISA KEV, has no reported ransomware use, and has no known public exploit, with a still-low EPSS (~0.51%) that has risen about 24% over 30 days. Residual risk is mainly silent data exposure rather than ransomware or outage, but HTML::Entities is a common Perl dependency, so unpatched interpreters remain a confidentiality concern until upgraded.

How an attack unfolds

An attacker finds an application path that runs Perl HTML::Entities decoding on attacker-controlled text (query bodies, HTML fragments, email, or stored content later echoed). They supply entity-encoded input crafted so the input scalar aliases a value in the entity2char hash and that value embeds its own entity key. Decoding then reallocates the scalar buffer while a stale pointer is still used, causing leftover heap bytes to be copied into the decode result. Those bytes are recovered from the HTTP response, stored artifact, log, or other output the attacker can read. Repeating the request can sample different adjacent heap. No named threat actors or in-the-wild campaigns are associated with this CVE, and exploit maturity is none.

How to fix it

Upgrade the HTML::Entities distribution (oalders/html-entities and downstream Perl packages) to 3.84 or later, which corrects the dangling repl pointer after grow_gap(). Rebuild or reinstall any vendored, fatpacked, or container-copied copies of the XS module, then restart long-lived Perl processes (prefork web workers, daemons, cron-resident interpreters) so they load the new shared object. If an immediate upgrade is impossible, avoid decoding untrusted entity strings with HTML::Entities::_decode_entities and isolate decoding in short-lived processes that do not hold secrets in the same heap. There is no configuration flag that disables the faulty pointer cache.

How to confirm the fix worked

On each host and image, confirm the installed HTML::Entities version is 3.84 or newer (e.g., perl -MHTML::Entities -e 'print $HTML::Entities::VERSION'). Inspect cpanfile/cpanfile.snapshot, carton/local, vendor/lib, OS packages, and container layers for older copies. After upgrade, restart Perl workers and verify the loaded .so/.dll path and version in process maps. Regression-test entity decoding on production-like input and confirm decoded output no longer contains unexpected binary or non-text fragments. Re-scan SBOMs and lockfiles so transitive pins cannot pull a pre-3.84 tarball.

Typical attack path

1. Locate an application or service that decodes untrusted HTML entities with Perl HTML::Entities before 3.84.
2. Submit entity-encoded input that causes the input scalar to alias an entity2char hash value containing a self-referential entity, triggering grow_gap() and a dangling-pointer copy in _decode_entities.
3. Retrieve the decoded output (response body, stored content, or logs) and extract unintended heap bytes mixed into the result.
4. Repeat against the same process to harvest additional adjacent memory and identify secrets (tokens, credentials, other users' data).
5. Abuse leaked secrets against the application or connected systems; this CVE itself does not provide write or code-execution primitives.

How to detect it

There is no public exploit and no associated ransomware or named actor activity, so confirmed in-the-wild use is unlikely but not disprovable from this CVE alone. Review application and access logs around HTML/entity decode endpoints for requests whose decoded results were later stored or returned with unexpected binary, NUL, or high-entropy fragments. Inspect core dumps, Perl croak/warn logs, and allocator diagnostics (e.g., glibc malloc abort, AddressSanitizer, or Perl debug builds) near _decode_entities for use-after-free or heap-corruption symptoms. Compare response bodies from entity-heavy inputs against expected character sets. Network telemetry will not show a unique protocol signature; focus on application-layer decode outputs and process memory artifacts rather than IDS payloads.

What your security team should do

• Patch HTML::Entities to 3.84+ everywhere Perl runs, including containers, serverless layers, and vendored lib trees, then recycle workers.
• Inventory all services that call HTML::Entities::decode or _decode_entities on untrusted input and treat those as high-priority upgrade targets.
• Until patched, restrict entity decoding of attacker-controlled content and keep secrets out of processes that still run the old XS code.
• Hunt historically for decoded output or logs that contain high-entropy binary or non-UTF-8 blobs after entity decode; there is no KEV deadline, but do not defer patching solely because EPSS is low.
• Add a dependency policy/gate that rejects HTML::Entities < 3.84 in CI and image builds.