GHSA-73P9-6HRP-8QHR

Vulnerability from github – Published: 2026-08-28 19:20 – Updated: 2026-08-28 19:20
VLAI
Summary
AIIR verification and policy gates could report success without enforcing the control (fail-open)
Details

Summary

Several of AIIR's verification and policy paths could return a success/"verified" result without actually enforcing the control they represent — they could fail open rather than fail closed. For a tool whose purpose is trustworthy verification, a consumer relying on these gates may have treated unverified or non-conforming input as verified.

Found during an internal adversarial hardening review of AIIR (not a third-party audit). All paths are fixed in 1.7.0.

Affected paths

  • A require_signing policy gate could be satisfied by a forgeable/empty field, so an unsigned or forged-bundle receipt could pass a "signing required" check without a valid signature.
  • A CI verification path could report success regardless of the underlying verification result.
  • A release-verification gate could advertise policy limits it did not actually enforce.
  • A signature-verification path could be silently skipped for certain input categories, exiting success without verifying.

Impact

A consumer relying on these gates (e.g. require_signing, release/policy verification, or the CI check) to block unsigned, forged, or non-conforming receipts could have received a false "verified"/"pass". Exploitation requires reliance on the affected gate; it does not forge valid signatures, nor does it compromise content-addressing or correctly-signed receipts.

Patches

Fixed in 1.7.0. Every affected path now fails closed, each with a regression test. Upgrade to aiir >= 1.7.0.

Workarounds

None for earlier versions other than upgrading. Full cryptographic Sigstore verification (pip install aiir[sign], --verify-signature with --signer-identity/--signer-issuer) provides defense in depth.

Scope note

This advisory covers code present in released versions (< 1.7.0). Separately, an unreleased agent-receipt feature had pre-release forgery findings fixed before it shipped — those were never in a released version and are out of scope.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "aiir"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-347",
      "CWE-636"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T19:20:32Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nSeveral of AIIR\u0027s verification and policy paths could return a success/\"verified\" result without actually enforcing the control they represent \u2014 they could **fail open** rather than fail closed. For a tool whose purpose is trustworthy verification, a consumer relying on these gates may have treated unverified or non-conforming input as verified.\n\nFound during an internal adversarial hardening review of AIIR (not a third-party audit). All paths are fixed in **1.7.0**.\n\n### Affected paths\n- A `require_signing` policy gate could be satisfied by a forgeable/empty field, so an unsigned or forged-bundle receipt could pass a \"signing required\" check without a valid signature.\n- A CI verification path could report `success` regardless of the underlying verification result.\n- A release-verification gate could advertise policy limits it did not actually enforce.\n- A signature-verification path could be silently skipped for certain input categories, exiting success without verifying.\n\n### Impact\nA consumer relying on these gates (e.g. `require_signing`, release/policy verification, or the CI check) to block unsigned, forged, or non-conforming receipts could have received a false \"verified\"/\"pass\". Exploitation requires reliance on the affected gate; it does not forge valid signatures, nor does it compromise content-addressing or correctly-signed receipts.\n\n### Patches\nFixed in **1.7.0**. Every affected path now fails closed, each with a regression test. Upgrade to `aiir \u003e= 1.7.0`.\n\n### Workarounds\nNone for earlier versions other than upgrading. Full cryptographic Sigstore verification (`pip install aiir[sign]`, `--verify-signature` with `--signer-identity`/`--signer-issuer`) provides defense in depth.\n\n### Scope note\nThis advisory covers code present in released versions (`\u003c 1.7.0`). Separately, an unreleased agent-receipt feature had pre-release forgery findings fixed before it shipped \u2014 those were never in a released version and are out of scope.",
  "id": "GHSA-73p9-6hrp-8qhr",
  "modified": "2026-08-28T19:20:32Z",
  "published": "2026-08-28T19:20:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/invariant-systems-ai/aiir/security/advisories/GHSA-73p9-6hrp-8qhr"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/invariant-systems-ai/aiir"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "AIIR verification and policy gates could report success without enforcing the control (fail-open)"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
Events included in the timeline

Loading timeline…


    Loading…

    Loading…

    Loading…

    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.