{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://index.boks.sh/vex/coreutils-arm64",
  "author": "boks index <https://index.boks.sh>",
  "timestamp": "2026-08-19T12:24:54Z",
  "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-54371"
      },
      "products": [
        {
          "@id": "pkg:deb/ubuntu/attr@1%3A2.5.2-4?distro=ubuntu-26.04"
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "The advisory is explicit that the symlink-traversal flaw is in the getfattr\nand setfattr UTILITIES, not in libattr. The finding arises because the SBOM\nnames the SOURCE package `attr`, which is what the advisory is filed against\nand which builds both the library and the utilities. That is correct SBOM\nbehaviour and the right purl to carry; it just means the match is at source\ngranularity while the vulnerability is at binary granularity.\n\nThe operative claim is the predicate below: this image ships neither utility,\nso the vulnerable code is not in the artifact. It is NOT that libattr is\nunused -- an image carries libattr.so.1 because something in it preserves\nextended attributes, which is the library path and reaches neither utility.\nWhich programs those are differs per image and does not change the\nassessment.\n\nThis text used to name cp, install and mv as the linkers. That was true of\ncoreutils, where it was written, and wrong for the other images carrying the\nstatement, so it now states the rule rather than one image's inventory."
    },
    {
      "vulnerability": {
        "name": "CVE-2026-54876"
      },
      "products": [
        {
          "@id": "pkg:deb/ubuntu/openssl@3.5.5-1ubuntu3.3?distro=ubuntu-26.04"
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "The leak is in OCSP response handling, reached from X.509 chain verification\nwhen X509_V_FLAG_OCSP_RESP_CHECK or X509_V_FLAG_OCSP_RESP_CHECK_ALL is set --\nin practice, a TLS client validating a peer certificate. libcrypto.so.3 is\nshipped, so the vulnerable code is present, but nothing in this image can\nreach it: the only libcrypto symbols imported are the message-digest ones.\n\nReaching this bug requires a TLS handshake. An image that imports no TLS,\nOCSP, X.509 or certificate-verification symbol cannot perform one."
    }
  ]
}