bzip2 contains an off‑by‑one error in the bzip2recover utility

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.

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.

1. 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.
2. 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.
3. 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.

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.

#!/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

Sources

1. NVD CVE-2026-42250
2. CERT Polska advisory
3. Debian security tracker entry
4. bzip2 upstream manual
5. bzip2 upstream downloads page
6. CISA Known Exploited Vulnerabilities Catalog
7. Tenable Nessus plugin 318082
8. Official bzip2 GitLab project