Bounty claim: non-member GitHub session can approve deploy request by ID via API

[sjj79475067-max]

Summary

I found a backend authorization bypass in the deploy request approval flow while validating the public bounty in #36.

A GitHub-authenticated account that is not part of the Permission Protocol workspace was able to access and approve the target deploy request by ID through the API, without using the approval UI.

What I verified

Using my GitHub account (sjj79475067-max), after OAuth sign-in to app.permissionprotocol.com:

• GET /api/user returned my newly-created user record.
• GET /api/v1/deploy-requests/cmnby88lk002niovev8uawnfm returned the target request for permission-protocol/pp-demo PR feat: demo GIF + MP4 in README #32, even though my deploy queue was empty and I had no active company selected.
• A direct API approval request to /api/v1/deploy-requests/cmnby88lk002niovev8uawnfm/approve returned HTTP 200 with success: true.
• The response recorded my actor as a signer and increased the satisfied approval count:
  • requestId: cmnby88lk002niovev8uawnfm
  • status: approved
  • receiptId: rcpt_dg_cmnby88lk002niovev8uawnfm
  • requiredQuorum: 1
  • approvalsCount: 2
  • signerActorKey: my newly-created PP user id

I did not use the approval UI for the approval action. I also did not attack infrastructure or spoof GitHub commit status.

Safety note

The target request from #36 is already merged and its receipt expired on 2026-03-29, so this did not authorize a live deploy. The important finding is that the server accepted an approval from a non-member authenticated user. If the same missing authorization check applies to a current unexpired deploy request, knowing the request ID appears sufficient to satisfy approval quorum and trigger the post-approval flow.

Why this appears bounty-relevant

The challenge asks for a way to pass the deploy gate without using the approval UI. This issue demonstrates that the approval backend accepted an unauthorized signer and returned success for the challenge target request. The only limiting factor in the public target is that the provided request is historical/expired.

I can provide exact request/response evidence privately. If this qualifies for the bounty, I can provide PayPal details privately as well.