# GHSA-73p9-6hrp-8qhr: AIIR verification and policy gates could report success without enforcing the control (fail-open)

> Attackers can bypass AIIR verification gates, causing unsigned or forged receipts to be incorrectly reported as verified, undermining trust in the verification process.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Not stated
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 28 Aug 2026

## What is GHSA-73p9-6hrp-8qhr?

GHSA-73p9-6hrp-8qhr is a vulnerability in aiir, published on 28 Aug 2026. 

### Official description

### 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.

## Which versions are affected by GHSA-73p9-6hrp-8qhr?

2 open source packages ship an affected version, including aiir.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `aiir` | PyPI | All versions | 1.7.0 |
| `aiir` | PyPI | All versions | 1.7.0 |

## How do I fix GHSA-73p9-6hrp-8qhr?

Upgrade aiir to 1.7.0 or later.

## Is GHSA-73p9-6hrp-8qhr being exploited?

There is no known exploitation of GHSA-73p9-6hrp-8qhr in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-73p9-6hrp-8qhr and fix it if it is affected.

What it is: GHSA-73p9-6hrp-8qhr is a vulnerability in aiir, published on 28 Aug 2026. 
Exploitation: There is no known exploitation of GHSA-73p9-6hrp-8qhr in the wild and no public exploit code.

Affected packages and fixed versions:
- aiir (PyPI): affected all versions; fixed in 1.7.0
- aiir (PyPI): affected all versions; fixed in 1.7.0

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-73p9-6hrp-8qhr/ (Markdown: https://insights.sbomify.com/GHSA-73p9-6hrp-8qhr/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-73p9-6hrp-8qhr

---
From sbomify Insights: https://insights.sbomify.com/GHSA-73p9-6hrp-8qhr/
Summaries are generated and may contain mistakes; the official description above is the record.