When one endpoint method forgets the authorization check
The smallest finding from this engagement, and the most ordinary — the kind of bug that predates AI entirely. One method on the chat endpoint checked who was asking. Another, right next to it, didn't.
About these case studies. Every finding in this series is a real vulnerability CyberStrike discovered in a live penetration test. Customer names, hostnames, and any detail that could identify the target have been removed under the confidentiality agreement that governs the engagement. The technique, the impact, and the lesson are exactly as we found them — only the target is deliberately unidentifiable.
The same engagement that produced an RCE through the agent’s execute tool and an SSRF in the document fetch also produced its smallest finding — and its most ordinary. This one has nothing to do with AI being clever or dangerous. It’s a missing authorization check, the kind of bug that predates chatbots by thirty years. It’s here because it shows where these bugs actually live.
Severity: LOW · CVSS 3.7 · CWE-862 (missing authorization) · vector: request body.
What we found
The chat endpoint multiplexes several methods: agent/run starts a run, agent/suggest offers completions, agent/stop cancels a run in flight. The first two verify the caller — a session, a tenant, an ownership check. agent/stop verifies nothing.
It cancels an active run identified only by a client-supplied threadId. No cookies, no session, no institutionId, no check that the run belongs to the caller. Send someone else’s threadId and their run stops — even across sessions, even across tenants.
What it can and can’t do
This is a LOW, and it behaves like one. We rate it honestly:
- It can interrupt another user’s in-flight AI run — a targeted nuisance, one run at a time.
- It can’t read data, change data, or stop runs in bulk. Exploitation needs the specific
threadId, and thread IDs aren’t broadcast — an attacker has to learn one (a leaked log, a referrer, a shared link, a chatty client) before they can cancel that run.
So the real-world bite is small, and CVSS 3.7 is the right number. We’re not going to dress it up.
Why it’s worth fixing anyway
The interesting part isn’t the impact — it’s the shape. Authorization wasn’t missing from the endpoint. It was missing from one method on it. run and suggest check ownership; stop doesn’t. That inconsistency is exactly where authorization bugs hide: the check is implemented per-handler, and one handler got added or refactored without it. Nothing looks wrong until someone enumerates the methods and tries each one cold.
The fix is boring and correct:
- Enforce ownership on every method that acts on a run, in shared middleware — not per-handler. When the check lives in one place that all methods pass through, “add a new method” can’t quietly mean “forget the check.”
- Bind
threadIdto its owning session and tenant, and reject anystop(or any other action) for a run the caller doesn’t own.
The pattern
Line the three findings up and they’re the same question answered in the wrong place three times. The execute-tool RCE put the trust boundary inside the model. The document-fetch SSRF put it in a denylist instead of an allowlist. This one applied it to some methods and not others. Every time, “is this caller allowed to do this?” was decided somewhere other than where it had to be — and the least glamorous version is the one you’ll find most often.
Found by CyberStrike — AI-powered security testing. Target and identifying details withheld under NDA.
