AIIR EUVD-2026-92118

Exploitation requires a downstream consumer to actually rely on one of the affected fail-open gates in aiir < 1.7.0: the require_signing policy gate (satisfiable by a forgeable/empty field), the CI verification path (returns success regardless of result), the release-verification gate (advertises unenforced policy limits), or a signature-verification path that is silently skipped for certain input categories. The attacker supplies an unsigned, forged-bundle, or non-conforming receipt and the gate falsely reports 'verified'. LIMITING FACTORS: it does not forge valid cryptographic signatures and does not compromise content-addressing or correctly-signed receipts; it is ineffective where full Sigstore verification is enforced (pip install aiir[sign], --verify-signature with --signer-identity/--signer-issuer), which provides defense in depth; and it only affects released versions below 1.7.0.

The input CVSS 4.0 base score is 6.9 (medium), with vector AV:N/AC:L/AT:N/PR:N/UI:N but impact limited to VI:L (low integrity) and VC:N/VA:N - no confidentiality or availability impact. No EPSS probability, CISA KEV listing, or POC/exploit-code signal was provided, and the CVSS exploit-maturity metric is undefined (E:X), so there is no public exploitation evidence at this time. Realistically this is a moderate-to-low priority rather than a critical one: the flaw is a fail-open logic weakness (CWE-347) that yields a false 'verified' result, not code execution or data theft, and it cannot forge valid signatures or compromise correctly-signed receipts. Exploitation is only meaningful where a downstream consumer actually relies on one of the affected gates. Two signals conflict with the vendor data and should be flagged: the 'Information Disclosure' tag contradicts the CVSS (VC:N means no confidentiality impact - this is an integrity issue), and the 'Jwt Attack' tag is not supported by the advisory, which describes Sigstore/receipt signing rather than JWT. The product is also abandoned (its GitHub repo is no longer available and it is unsupported), which lowers real-world exposure further.

An attacker submits an unsigned, forged-bundle, or non-conforming receipt to a workflow that relies on AIIR's require_signing policy gate, release/policy verification, or CI verification check. Because the affected path fails open, the gate returns a 'verified'/'pass' result without enforcing the control, so the forged artifact is accepted as trusted. No public exploit code was identified in the provided data; the weakness does not forge valid cryptographic signatures and does not affect correctly-signed receipts.