Apigee revision tampering: weak auth and a credential-leaking callout

Apigee is the front door for your APIs, and whoever can deploy a proxy revision controls how every call is authenticated and routed. That makes the deploy permission a powerful target.

How the attack works

An attacker with deploy rights authors a new revision of a production API proxy. Cloud Audit Logs show the revision created and deployed by a principal outside the release pipeline. The revision relaxes the API-key and OAuth enforcement, adds a route to a backend target that was meant to stay internal, and inserts a JavaScript or ServiceCallout policy that forwards request headers, including bearer tokens, and bodies to an attacker host. Once the tampered revision is deployed, every production call traverses the side channel and credentials and payloads are exfiltrated on every request. In ATT&CK terms this is T1556, Modify Authentication Process, with T1190, Exploit Public-Facing Application, and T1530, Data from Cloud Storage.

Why it works

The attacker held deploy rights and proxy changes were not gated. Apigee serves whichever revision is currently deployed, so one out-of-pipeline revision silently changes authentication and routing for every consumer.

How to fix it

Blocking the outbound host leaves the tampered revision serving with weak auth and an exposed backend, and the callout can be repointed. Redeploy the known-good revision from source or roll back to the last trusted revision so the live path no longer weakens auth or runs the callout, then freeze proxy deploy rights so it cannot be re-pushed. Bound the exposure with the deploy and rollback timestamps and enumerate affected requests from Apigee analytics and message logs, then revoke the leaked tokens rather than waiting for expiry.

Practice it

We built this as a GraphLattice Range scenario so developers can rehearse the revision tamper, the restore-and-freeze containment, and the gated-deploy fix.