3. Persistent Infrastructure Access via Webhook IDOR

Background

I was analyzing a platform's automation integrations, specifically looking at the lifecycle of webhooks. The platform assigned each webhook a unique, persistent UUID (node_id).

I wanted to see what happens to API access when a user's UI permissions are suddenly revoked. I set up a webhook using a high-privileged account, saved the node_id, and then purposely downgraded my own account's permissions.

The Exploit

The UI handled the downgrade perfectly. The integration settings panel disappeared, and browsing to it returned a 403 Forbidden.

But UI restrictions mean nothing if the API isn't secured.

I fired up Burp Suite and sent a direct PATCH request to the webhook modification endpoint using the node_id I had saved. The backend verified that the UUID existed, but it failed to verify if my current session was actually authorized to modify it. By exploiting this IDOR, I bypassed the revocation completely.

Replication

First, my downgraded account attempts to view the integration settings and gets blocked via the UI.

GET /api/v3/integrations/settings HTTP/1.1
Host: api.target-platform.com
Cookie: session_id=attacker_revoked_session

Next, I bypass the UI and send a direct API request to disable the webhook using the known node_id. The backend accepts it from my revoked session.

PATCH /api/v3/webhooks/nodes/550e8400-e29b-41d4-a716-446655440000 HTTP/1.1
Host: api.target-platform.com
Cookie: session_id=attacker_revoked_session
Content-Type: application/json

{
  "status": "disabled"
}

The Impact

A malicious former employee whose access was supposed to be "revoked" could hold onto these UUIDs and silently disable critical webhooks weeks or months later. They could disable security alerts, break billing syncs, or halt deployments, causing chaos that is incredibly difficult for an engineering team to track down.

The Resolution

The company confirmed the issue and deployed a fix. They acknowledged the impact and paid the bounty reward.