{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://index.boks.sh/vex/python-amd64",
  "author": "boks index <https://index.boks.sh>",
  "timestamp": "2026-08-19T13:04:13Z",
  "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."
    },
    {
      "vulnerability": {
        "name": "CVE-2026-4739"
      },
      "products": [
        {
          "@id": "pkg:deb/ubuntu/expat@2.7.4-1?distro=ubuntu-26.04"
        }
      ],
      "status": "fixed",
      "impact_statement": "The advisory is filed against ITK (InsightSoftwareConsortium), naming\nModules/ThirdParty/Expat/src/expat -- the copy of expat that ITK VENDORS.\nUbuntu's tracker indexes it under the expat source package (and xmlrpc-c,\nwhich vendors expat too), so any image linking libexpat matches it by purl.\nThat is why it surfaces on a python build, which has no connection to medical\nimaging: python links system expat, expat is in the SBOM, and the advisory\nnames expat.\n\nThe version bound decides it. \"affects ITK: before 2.7.1\" is expat's\nversioning, not ITK's -- ITK releases are 5.x -- so 2.7.1 is the expat release\ncarrying the fix. boks ships 2.7.4-1, three patch releases past it.\n\nUbuntu has not contradicted this and has not confirmed it either: the status\nfor expat is \"Needs evaluation\" on every release, including 26.04, which is\nexplicitly not \"affected\". With no fixed-version recorded upstream, grype has\nnothing to compare against and reports the match, at NVD's 9.4 rather than\nUbuntu's Medium -- which is how a CVE about a medical imaging toolkit becomes\nthe single critical finding on a python image.\n\nThe claim here is checkable and is checked: the shipped expat version is read\nfrom this image's own SBOM and compared. An image that shipped an older expat\nemits no statement and the finding stands."
    }
  ]
}