Verifier accepts signed non-authorizing receipt statuses

[manuelsampedro1]

Summary

The local Permission Protocol verifier accepts any signed, unexpired receipt status except lowercase revoked. A valid Ed25519 signature over a non-authorizing status such as DENIED, PENDING, or EXPIRED can therefore return success from pp verify / verifyReceipt if the signature verifies and the receipt is unexpired.

This is an acceptance-semantics flaw in the signing/verification flow: the signature can be mathematically valid, but the signed lifecycle state does not authorize execution.

Why this matters

Downstream gates commonly treat verifier success / exit code 0 as the authorization decision. If any issuer path, migration, compatibility layer, or imported receipt can produce a signed receipt with a non-authorizing lifecycle state, local consumers can accept it as approved because the verifier only rejects status === "revoked".

Relevant current logic in permission-protocol/pp-cli:

const status = String(receipt.status);
if (expiresAt.getTime() <= now.getTime() || status === "revoked") {
  return { verified: false, ... };
}

return { verified: true, ... };

Reproduction

I opened a fix with a regression test here:

permission-protocol/pp-cli#2

The test:

1. Loads a known-valid fixture.
2. Changes the signed status field to DENIED.
3. Re-signs the canonical receipt bytes with the fixture Ed25519 private key, so the signature is valid for the modified receipt.
4. Verifies the receipt with the matching public key.

Before the fix, this kind of receipt would pass because it is signed, unexpired, and not lowercase revoked. After the fix, it fails closed.

Suggested fix

Only accept the v1 authorizing status (valid) as verification success. Treat revoked as expired/revoked and reject every other status (DENIED, PENDING, EXPIRED, casing variants, unknown future values) as malformed/non-authorizing unless a future receipt version explicitly defines different semantics.

Bounty note

Related to #36: this is not a raw Ed25519 forgery; it is a flaw in the receipt verification acceptance flow where a valid signature over non-authorizing signed content can be accepted as authorization-valid by local consumers.

Validation for the PR:

• npm ci
• npm test -- --run
• npm run build
• git diff --check

[manuelsampedro1]

Additional fail-closed SDK fix opened: permission-protocol/python-sdk#1

It closes a verification-side gap where the Python SDK could swallow an APIError from /api/v1/receipts/verify and return a receipt as valid based on the fetched receipt metadata. The patch makes verify() require the authoritative verification response and adds regressions for verification-service failure and missing valid fields.

[manuelsampedro1]

Additional approval-bypass surface fixed in mcp-guard: permission-protocol/mcp-guard#2

The approval UI APIs exposed pending tool-call arguments and allowed approve/deny without any token, with wildcard CORS. The PR binds the server to loopback, adds a per-session page token required by /api/pending, /api/receipts, /api/approve/:id, and /api/deny/:id, removes wildcard CORS, and adds a regression test.

[Ilya0527]

The denylist-vs-allowlist split is the root defect: signature verification answers "are these bytes authentic," but every downstream caller is reading it as "is this authorized." Those are different questions and the only sound bridge is to allowlist the authorizing state explicitly — your suggested fix is correct. Two hardenings worth layering on top:

1. Reject unknown statuses at parse time, not verify time. If receipt.status is anything outside the v1 enum, fail at deserialization with a typed error. The verify-time allowlist should be the last line of defense, not the only one — otherwise every downstream consumer reinvents the same check, and the migration path for v2 statuses turns into a coordination problem across every embedder.

2. Canonicalize before signing AND at the schema boundary. If DENIED, denied, and Denied can all round-trip through the signer, you have a status-malleability surface independent of this bug. Pin the canonical form in the spec (lowercase, no whitespace) and normalize at parse — the verifier should never see a casing variant in the first place. Otherwise an issuer who mints VALID or valid (trailing space) sails past a naive === "valid" check.

One sharp question: is status typed as a freeform string or a discriminated union in the receipt schema today? If it's a string, the allowlist fix alone still leaves the canonicalization gap. If it's already an enum, then the bug is purely that the verifier was written defensively against one bad value instead of permissively against one good value — which is the more common version of this failure and worth calling out in the PR description as the lesson.

Also worth confirming: does any current issuer path (migration, import, compat shim) actually emit non-valid signed receipts in the wild, or is this purely a defense-in-depth fix? That changes the urgency for downstream consumers reading exit codes today.

Diagnosis: ALEF-PAT-004, ALEF-PAT-009 | Confidence: 0.8 | See standard: https://n50.io/patterns/004