DEV Community

Cover image for We planted a Descope privilege-escalation bug — can your coding agent catch it?
FetchSandbox
FetchSandbox

Posted on • Originally published at fetchsandbox.com

We planted a Descope privilege-escalation bug — can your coding agent catch it?

We open-sourced a repo with a bug planted on purpose: github.com/fetchsandbox/playground.

The bug is in apps/descope — a small FastAPI "Agent Gateway" where AI agents exchange a Descope access key for a scoped session. The flaw: the exchange endpoint trusts whatever scopes the client requests. A read-only agent key can ask for users:write and get it.

This is the privilege-escalation shape that ships constantly in agentic auth. The token exchange returns 200, the happy path works, and nothing ever compares the granted scope against what the key was actually granted.

The 20-minute test drive

Two tasks, both run from your IDE (Cursor, Claude Code, or any MCP-capable editor). No Descope account, no API keys — the workflows run against FetchSandbox's hosted Descope sandbox over MCP, and each app ships a .mcp.json already wired.

Task 1 — greenfield. apps/descope-onboarding is a tiny notes app with placeholder auth. Ask your agent to add Descope OTP sign-up, but with one constraint: prove the OTP + session flow in the sandbox before writing any code, then propose the diff.

./fetchsandbox I'm adding Descope OTP sign-up to this app — prove the Descope
OTP + session flow in the sandbox before writing any code, then propose the
diff. I'll decide whether to apply.
Enter fullscreen mode Exit fullscreen mode

Task 2 — brownfield. Point the agent at the Agent Gateway and ask it to audit:

./fetchsandbox our agent access-key exchange might be handing out more scope
than the key was granted — audit the descope agentic auth
Enter fullscreen mode Exit fullscreen mode

What a real catch looks like

Static review is not the bar. "This looks vulnerable" is a guess. The bar is:

  • the escalation is reproduced — read-only key in, users:write session out
  • the proof shows buggy vs fixed on actual Descope routes (/v1/...)
  • there's a receipt URL — an openable run trace, not a claim in chat

Auth bugs live in the lifecycle: replayed magic links, expired sessions, JWTs that were decoded instead of verified, scope grants nobody re-checked. Mocks return clean 200s for all of these. That's the gap the playground is designed to expose.

The other planted bugs

If Descope isn't your stack, the repo also has broken Stripe (webhook dedup keyed on the wrong header — events processed 2–3×), Resend (bounces silently dropped, users stay "active"), Clerk (session validation skipped on one endpoint), and a few more. Each app is ~50–150 lines of Python.

The part where you tell us it fell flat

Findings go back as a PR — there's a FINDINGS_TEMPLATE.md in the repo. Paste your agent's session, the receipt URLs, and your honest reaction. Merged PRs show up on your GitHub contribution graph.

We explicitly want the failure reports: MCP wouldn't connect, the agent caught nothing, the proof felt fake. An honest "it didn't work" beats a polite green checkmark.

Start here: TESTING.md.

Top comments (0)