{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://index.boks.sh/vex/unzip-amd64",
  "author": "boks index <https://index.boks.sh>",
  "timestamp": "2026-08-19T13:12:14Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": {
        "name": "CVE-2026-42250"
      },
      "products": [
        {
          "@id": "pkg:deb/ubuntu/bzip2@1.0.8-6build2?distro=ubuntu-26.04"
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "The off-by-one is in the bzip2recover UTILITY, not in libbz2. The advisory is\nfiled against the bzip2 source package, which builds both, so any image\nlinking the library matches the advisory by purl whether or not it ships the\nprogram that contains the defect.\n\nThe operative claim is the predicate below: this image does not ship\nbzip2recover, so the vulnerable code is not in the artifact. It is NOT that\nlibbz2 is unused -- images this statement is attached to link it precisely\nbecause they need bzip2 compression, and measured on python the _bz2\nextension module imports BZ2_bzCompress, BZ2_bzDecompress and their\ncompanions. Compressing and decompressing does not reach the recovery tool.\n\nWhere the utility IS shipped -- the bzip2 image itself -- the predicate\nmatches, no statement is emitted, and the finding stands. Same assessment,\nopposite results, decided by what each image measurably contains rather than\nby which package the advisory names.\n\nThis text used to name the zip and unzip images as the ones linking libbz2.\nThat was accurate when written and became misleading as soon as the\nassessment was inherited by images it did not mention, so it now describes the\nrule instead of an inventory of consumers."
    }
  ]
}