CVE-2026-42250

What it actually does

CVE-2026-42250 is an off-by-one memory corruption flaw in the bzip2recover utility, a recovery tool shipped with bzip2. When bzip2recover parses a specially crafted bzip2 file, it can write one byte past the end of a global buffer. The known impact is process memory corruption leading to an application crash and local denial of service. The CVSS vector indicates local attack vector, low attack complexity, no privileges required, and required user interaction; confidentiality and integrity are not impacted, and availability impact is limited.

Why it matters to the business

The likely operational impact is limited disruption of workflows or automated jobs that invoke bzip2recover on untrusted or externally supplied compressed files. Because this affects a utility rather than the primary decompression path, has very low EPSS, no known exploit maturity, and is not in CISA KEV or associated with ransomware, broad business risk is currently low. Organizations with file-processing pipelines, malware sandboxes, support teams, backup recovery workflows, or shared systems where users can submit archives should still patch because crafted files could crash recovery tasks and interrupt processing.

How an attack unfolds

An attacker first creates or obtains a malformed bzip2 file designed to trigger the off-by-one write in bzip2recover. The attacker must then cause a person, script, service, or automated workflow to run bzip2recover against that file. During parsing, bzip2recover writes outside the bounds of a global buffer, corrupting memory and causing the utility to terminate abnormally, typically as a crash or segmentation fault. Current public information supports denial of service as the practical impact; there is no indication of known exploitation, remote code execution, ransomware use, or active exploitation by named threat actors.

How to fix it

Update bzip2 to a version that includes upstream patch 35d122a3df8b0cc4082a4d89fdc6ee99f375fe67, or install the corrected bzip2 package from the operating system or distribution vendor. No specific package fixed versions were provided in the input, so use vendor advisories for exact package names and release numbers. Where immediate patching is not possible, restrict use of bzip2recover on untrusted files, run it in a sandbox or low-privilege isolated environment, disable automated invocation against externally supplied archives, and ensure crash of the utility cannot interrupt critical services.

How to confirm the fix worked

Confirm the installed bzip2 package includes the upstream fix commit 35d122a3df8b0cc4082a4d89fdc6ee99f375fe67 or a vendor backport. Validate package status with the relevant package manager and compare against vendor security advisories. Search systems and container images for bzip2recover binaries and confirm their package provenance. For exposed workflows, verify that untrusted bzip2 files are not automatically passed to bzip2recover without sandboxing. If a regression test is available from the vendor or upstream project, run it against the patched utility and confirm malformed inputs are rejected or handled without crashing.

Typical attack path

1. Craft a malformed bzip2 file that triggers the off-by-one condition in bzip2recover.
2. Deliver the file to a target user, shared location, support channel, file-processing workflow, or recovery process.
3. Induce or wait for bzip2recover to be executed against the malicious file.
4. The utility performs an out-of-bounds write to a global buffer while parsing the file.
5. bzip2recover crashes, causing denial of service for that recovery operation or any dependent automation.

How to detect it

Look for evidence that bzip2recover was executed against untrusted or recently received files, followed by abnormal termination. Relevant sources include shell history, process execution telemetry, EDR events, auditd logs, syslog, systemd journal, application pipeline logs, crash reporters, and core dump directories. Hunt for bzip2recover invocations immediately preceding segmentation faults, core dumps, abnormal exits, or repeated job failures. Review file ingress sources such as email gateways, upload services, ticket attachments, shared folders, sandbox queues, and backup recovery locations for suspicious .bz2 files that were processed shortly before the crash. Because there are no known public exploit campaigns or named actors for this issue, detection should focus on local execution and crash artifacts rather than external network indicators.

• bzip2recover
• segmentation fault.*bzip2recover
• segfault.*bzip2recover
• core dumped.*bzip2recover
• bzip2recover.*core dumped
• bzip2recover.*Segmentation fault
• /usr/bin/bzip2recover
• /bin/bzip2recover
• /usr/local/bin/bzip2recover
• /var/lib/systemd/coredump/.*bzip2recover
• core.bzip2recover
• bzip2recover:

What your security team should do

• Prioritize patching on systems that process untrusted archives, shared file uploads, support attachments, malware samples, backups, or automated recovery jobs.
• Inventory where bzip2recover is installed and where it is invoked by scripts, scheduled jobs, CI pipelines, forensic tooling, or file-processing services.
• Apply distribution or vendor updates for bzip2; confirm the fix includes upstream patch 35d122a3df8b0cc4082a4d89fdc6ee99f375fe67 or an equivalent backport.
• Until patched, avoid running bzip2recover on untrusted files outside a sandboxed, low-privilege environment.
• Monitor for repeated bzip2recover crashes, core dumps, or segmentation faults, especially following processing of externally supplied .bz2 files.
• Treat this as lower urgency than remotely exploitable or KEV-listed issues, but include it in normal patch cycles because the flaw is simple to trigger once a malicious file is processed.