Unshakken

Flag

PINAKA{angada_the_unshaken_oath}

Vulnerability

The chancery approves revisions asynchronously. An approval request names one revision, but the scribe later records its verdict against the document's current head. The envoy can change that head with the rollback endpoint while the request is queued. This lets a review of a normal revision clear the original sealed revision.

Exploit

1. POST /chancery/enroll to obtain session_id and token. Send them as X-Session and Authorization: Bearer <token> on subsequent requests.
2. GET /chancery/documents reveals doc_war_terms, whose initial head r_001 is sealed. GET /chancery/delegations shows the envoy has normal revise and dispatch permissions.
3. POST /chancery/documents/doc_war_terms/revisions with {} creates a normal revision, r_002.
4. POST /chancery/documents/doc_war_terms/rollback with {"rev_id":"r_001"} makes the sealed revision the head again.
5. POST /chancery/approvals with {"doc_id":"doc_war_terms","rev_id":"r_002"} queues review of the normal revision. When the worker runs, the audit log shows {"action":"certify","rev":"r_001","verdict":"cleared"}: it has applied that approval to the sealed head.
6. POST /chancery/dispatch with {"doc_id":"doc_war_terms"} now dispatches r_001 and returns the flag in response.

The approval and rollback order matters: the normal revision must exist when review is submitted, and the sealed revision must be the head when the worker processes it. In this instance, rolling back before queueing the review was sufficient.