{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://index.boks.sh/vex/php-arm64",
  "author": "boks index <https://index.boks.sh>",
  "timestamp": "2026-08-19T12:55:53Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": {
        "name": "CVE-2026-27171"
      },
      "products": [
        {
          "@id": "pkg:deb/ubuntu/zlib@1%3A1.3.dfsg%2Breally1.3.1-1ubuntu3?distro=ubuntu-26.04"
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "The unbounded loop is in x2nmodp, reached only from crc32_combine64 and\ncrc32_combine_gen64. Those are the public API for combining the CRCs of two\nseparately-checksummed streams; nothing in inflate or deflate calls them.\n\nThe operative claim is narrow, and it is the predicate below: no binary in\nthis image references either entry point. It is NOT that zlib is unused. zlib\ncode executes in every image this statement is attached to -- whatever links\nlibz does so in order to compress or decompress, which is the ordinary path\nand reaches nothing described here. Measured on python, three separate\nconsumers import zlib: libcrypto, the zlib extension module, and binascii.\nAny of them calling crc32_combine would withhold this statement.\n\nThis remains the weakest assessment in this directory and is recorded as such.\nIt rests on a reading of zlib's own call graph -- that x2nmodp has no other\ncaller -- rather than on a property of the artifact, and should be revisited\nif zlib's maintainers contradict it.\n\nAn earlier version of this text said libcrypto was what linked zlib. That was\ntrue of the image it was written against and false everywhere else, and it\nshipped as the impact_statement of signed documents describing images it did\nnot describe. A rationale that names particular consumers goes stale the\nmoment the assessment is inherited; what is written here holds for any\nartifact the predicate admits."
    },
    {
      "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."
    }
  ]
}