{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://index.boks.sh/vex/openssh-agent-arm64",
  "author": "boks index <https://index.boks.sh>",
  "timestamp": "2026-08-19T12:40:10Z",
  "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-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."
    }
  ]
}