bzip2 EUVD-2026-32898

The vulnerability is triggered exclusively when bzip2recover processes a specially crafted input file - the core bzip2 library and bzip2/bunzip2 commands are not affected. Per the CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:N), no special privileges are required, and no particular non-default configuration is needed; the only prerequisite is that the attacker can supply a malicious file to an invocation of bzip2recover. Exploitation is naturally limited by the local attack vector: bzip2recover is not a network service and is not exposed remotely, so the attacker must already have local file-system write access or the ability to influence which files a recovery pipeline processes. The impact is further bounded to crashing only the bzip2recover process, with no effect on system integrity or confidentiality.

The CVSS 4.0 score of 5.1 accurately reflects limited real-world risk. The local attack vector (AV:L) is a hard constraint - this is not remotely exploitable as a standalone attack; an attacker must already be able to supply a crafted file to a process that invokes bzip2recover. The impact profile (VC:N/VI:N/VA:L) confirms no confidentiality or integrity exposure, only a low-availability impact to the recovery utility itself. No EPSS score was provided in the source data, so exploitation probability cannot be quantified numerically. KEV status is absent, and no POC is known, meaning exploitation status is 'no public exploit identified at time of analysis.' Critically, bzip2recover is a standalone utility invoked manually or in recovery scripts - it is not a daemon or network service - which substantially limits automated or opportunistic exploitation. For most deployments, this vulnerability presents a low operational priority unless bzip2recover is invoked programmatically in an automated pipeline where untrusted archive files could be processed. No conflicting signals were identified between the CVSS vector and the description.

A local attacker places a specially crafted .bz2 file in a directory monitored by a script or automated recovery process that calls bzip2recover on damaged archives. When bzip2recover processes the malicious file, the off-by-one error triggers an out-of-bounds write to the global buffer, corrupting adjacent memory and crashing the utility. No public exploit code is known at this time; the scenario relies on the attacker's ability to control the input file presented to bzip2recover.