CVE-2026-42250 · bzip2 bzip2recover off-by-one out-of-bounds write

01 · The Real Story

This is a dented spare tire, not a blown engine

CVE-2026-42250 is an off-by-one out-of-bounds write in bzip2recover, the *recovery* helper used to salvage damaged .bz2 archives, not the normal bzip2/bunzip2 path. CERT Polska says affected versions are all releases through 1.0.8; the public record points to fix commit 35d122a3df8b0cc4082a4d89fdc6ee99f375fe67, and multiple databases map that to bzip2 1.0.9.

If you score the memory corruption in a vacuum, this looks like a mid-tier bug. In the real world it is much smaller: the attacker needs a target to run a rarely used local utility against a malicious archive, and the public impact statement is memory corruption leading to crash/DoS, not demonstrated code execution or privilege escalation. For enterprise patch queues, that makes this a LOW backlog item, not something that should steal time from remotely reachable or actively exploited issues.

"Low-priority bug: crash-only flaw in a niche local recovery utility, not a meaningful enterprise intrusion path"

02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver a malicious recovery target

The attacker needs a specially crafted .bz2 file that will hit the off-by-one path when parsed by bzip2recover. There is no meaningful network service here; delivery is file-based, typically via phishing, shared storage, artifact exchange, or post-compromise file placement. A practical weaponized input would be a custom malformed archive generated with a bespoke mutator or fuzz-derived testcase rather than an off-the-shelf exploit kit.

Conditions required:

Attacker can place a crafted .bz2 file where the victim or a job can access it
Target environment has the bzip2 utilities installed

Where this breaks in practice:

bzip2recover is not an internet-facing daemon
This is not triggered by ordinary decompression with bunzip2 according to the public advisory text

Detection/coverage: Email/web gateways may catch generic malware delivery, but there is no signature-rich network exploit phase. Exposure scanners will mostly just flag package presence.

STEP 02

Convince or cause execution of bzip2recover

The vulnerable code path is in the recovery utility itself, documented by upstream as a tool for damaged archives (manual). The attacker therefore needs a user, script, CI job, forensic workflow, or data-recovery process to invoke bzip2recover <file> on the crafted archive.

Conditions required:

A human or automation actually uses bzip2recover on attacker-controlled input
The utility is callable in the target context

Where this breaks in practice:

Most enterprises never invoke bzip2recover in normal business workflows
Even on hosts with bzip2 installed, the recovery helper is usually dormant

Detection/coverage: Strong EDR/process telemetry can log bzip2recover execution and command-line arguments; traditional vulnerability scanners cannot prove the dangerous workflow exists.

STEP 03

Trigger the off-by-one write

When the crafted file is processed, the utility performs an out-of-bounds write to a global buffer, per CERT Polska and NVD. Publicly documented impact is application instability and a crash, i.e. denial of service of that process or job.

Conditions required:

Vulnerable code version present
Malformed file reaches the exact parser state

Where this breaks in practice:

No public exploit chain currently demonstrates reliable code execution
Crash-only outcomes sharply reduce operational impact compared with a service compromise

Detection/coverage: You may see process crashes, abnormal exit codes, or core dumps. Nessus/Tenable covers package-level detection as a local check, not exploit confirmation.

STEP 04

Convert crash into business impact

The attacker only gets meaningful impact if the crash interrupts a real workflow: archive recovery, evidence handling, batch ingestion, or a scripted salvage process. On a standard workstation or server, that usually means one failed utility run, not a foothold expansion.

Conditions required:

The crashed process matters to production or investigation workflow
Operators depend on recovery output from the affected job

Where this breaks in practice:

Blast radius is typically one process in one user context
No tenant-to-tenant, remote-to-host, or privilege-boundary break is described publicly

Detection/coverage: Job failure monitors, shell history, SIEM process telemetry, and crash reporting are your best indicators; perimeter tools are irrelevant.

03 · Compensating Control

Ban untrusted use of bzip2recover — Treat bzip2recover like a forensic-only helper, not a general ingestion tool. Update analyst runbooks and CI/helper scripts so untrusted .bz2 files are tested with normal decompress/validation paths first; for a LOW verdict there is no mitigation SLA, so handle this as backlog hygiene during the next documentation and script-review cycle.

Constrain archive-recovery jobs — If you truly need automated recovery, run it inside a sandboxed container or tightly confined service account with no sensitive filesystem reach. The point is blast-radius control: a crash stays a disposable worker failure instead of interrupting a privileged pipeline; again, no mitigation SLA applies for LOW, so fold this into routine hardening work.

Inventory scripted invocations — Search repos, cron jobs, CI templates, and admin toolboxes for bzip2recover usage. On 10,000 hosts, the package may be everywhere while the dangerous workflow exists almost nowhere; that inventory tells you whether you even have a problem worth burning patch capital on.

What doesn't work

A WAF or reverse proxy does nothing here because there is no HTTP attack surface.
Perimeter vuln scanning overstates risk by finding the package and missing the key friction: the victim has to run bzip2recover.
MFA is irrelevant; this is not an authentication-bypass or account-takeover issue.
Generic network IDS/IPS has little value because exploitation is file-and-process driven, not a recognizable network exchange.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No known active exploitation in the sources reviewed; the CVE is not listed in CISA KEV.
Public PoC status	No public PoC repo or weaponized exploit surfaced in GitHub-focused searches. Current public material is advisory/metadata, not exploit code.
EPSS	0.00016 from the supplied intel — effectively near-floor exploit likelihood.
KEV status	Not listed in the CISA Known Exploited Vulnerabilities Catalog.
CVSS context	There is no upstream vendor severity from the bzip2 project in the reviewed sources. NVD currently shows a CERT.PL CNA CVSS v4 base 5.1 with vector `CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N`, which aligns with local, low-complexity, availability-limited impact.
Affected versions	CERT Polska states all versions through 1.0.8 are vulnerable, specifically in `bzip2recover`.
Fixed versions	Public records point to fix commit `35d122a3df8b0cc4082a4d89fdc6ee99f375fe67`; some databases map that to bzip2 1.0.9. Debian tracker currently shows unstable unfixed and tags bookworm/trixie as a minor issue / no-dsa.
Exposure reality	This is a local command-line recovery utility, not a listening service. Shodan/Censys-style internet exposure is basically not applicable; the real exposure question is whether your org has scripts or analysts that invoke `bzip2recover` on untrusted files.
Disclosure date	2026-05-28.
Reporter / coordinator	Coordinated by CERT Polska; credits go to Michał Majchrowicz and Marcin Wyczechowski from the AFINE Team.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to LOW (2.8/10)

Why this verdict

Local-only prerequisite cuts hard: the public vector is local, and bzip2recover is a command-line helper rather than a remotely reachable service. That means the attacker already needs delivery plus execution in a user or job context before the bug matters.
Tool-specific exposure slashes population: the flaw is in bzip2recover, not the common bzip2/bunzip2 path. Plenty of Linux hosts ship the package, but very few enterprise workflows actually call the recovery utility.
Observed impact is narrow: the advisory language describes memory corruption and a crash. With no public PoC, no KEV listing, and no code-exec evidence, this behaves like a localized availability issue, not a compromise accelerator.

Why not higher?

There is no unauthenticated remote path, no internet-facing service, and no evidence of active exploitation. More importantly, the bug sits behind a specialized workflow that most enterprises do not use, so the reachable population is far smaller than the package-install count suggests.

Why not lower?

It is still a real out-of-bounds write in broadly distributed software, and some shops do run file-recovery or archive-triage jobs against externally sourced data. That keeps it above IGNORE: if you have that niche workflow, a malicious file can still reliably break it.

06 · Verification

Crowdsourced verification payload.

Run this on the target Linux/Unix host or inside the affected container image. Invoke it as bash check_bzip2recover_cve_2026_42250.sh; it needs only normal user privileges, though package-manager metadata may be easier to inspect with standard local access.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# check_bzip2recover_cve_2026_42250.sh
# Detect likely exposure to CVE-2026-42250 in bzip2recover.
# Outputs exactly one of: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

have_cmd() { command -v "$1" >/dev/null 2>&1; }

version_lt() {
  # returns 0 if $1 < $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" != "$2" ]
}

version_ge() {
  # returns 0 if $1 >= $2
  ! version_lt "$1" "$2"
}

# Step 1: binary presence
if ! have_cmd bzip2recover; then
  echo "PATCHED"
  exit 0
fi

# Step 2: try to get upstream version from bzip2
VER=""
if have_cmd bzip2; then
  VER=$(bzip2 --version 2>/dev/null | sed -n '1{s/.*Version \([^, ]*\).*/\1/p}')
fi

# Step 3: fall back to package managers if needed
if [ -z "$VER" ] && have_cmd dpkg-query; then
  VER=$(dpkg-query -W -f='${Version}\n' bzip2 2>/dev/null | head -n1)
fi
if [ -z "$VER" ] && have_cmd rpm; then
  VER=$(rpm -q --qf '%{VERSION}-%{RELEASE}\n' bzip2 2>/dev/null | head -n1)
fi
if [ -z "$VER" ] && have_cmd apk; then
  VER=$(apk info -e bzip2 2>/dev/null && apk info -v bzip2 2>/dev/null | head -n1)
fi
if [ -z "$VER" ] && have_cmd pacman; then
  VER=$(pacman -Q bzip2 2>/dev/null | awk '{print $2}' | head -n1)
fi

# Normalize package suffixes like 1.0.8-5ubuntu1 -> 1.0.8
BASE_VER=$(printf '%s' "$VER" | sed -E 's/^([0-9]+(\.[0-9]+)+).*/\1/')

if [ -z "$BASE_VER" ]; then
  echo "UNKNOWN"
  exit 2
fi

# Public records state all versions through 1.0.8 are vulnerable; 1.0.9 is fixed.
if version_ge "$BASE_VER" "1.0.9"; then
  echo "PATCHED"
  exit 0
fi

if version_lt "$BASE_VER" "1.0.9"; then
  echo "VULNERABLE"
  exit 1
fi

echo "UNKNOWN"
exit 2