Notifications
Clear all
Topic starter
02/08/2026 11:48 am
TL;DR: Three vulnerabilities were found in Hoppscotch up to version 2026.2.1, according to Aikido’s AI pentest agents, including an open redirect that enabled account takeover, stored XSS in the Mock Server, and a broken access control path that could expose credentials and API keys. The pattern is familiar: application bugs become identity and secret-exposure events when authentication tokens and inherited headers are in play.
NHIMG editorial — based on content published by Aikido: Attack finds multiple 0-days in Hoppscotch
Questions worth separating out
Q: What breaks when open redirects are used in login flows?
A: Open redirects let attackers steer browser-based token handoff to an unexpected destination.
Q: Why do same-origin mock or preview features increase security risk?
A: Because the browser treats same-origin content as trusted application state.
Q: What do security teams get wrong about moving requests across teams?
A: They often validate the source object but forget the destination boundary.
Practitioner guidance
- Replace redirect prefix checks with URL allowlisting Parse redirect targets server-side, compare the final host against an explicit allowlist, and reject any value that can resolve outside the intended local callback pattern.
- Isolate mock and preview content from the primary origin Serve user-controlled mock responses from a separate origin or hardened sandbox, then apply a strict Content Security Policy and server-side content-type enforcement.
- Enforce destination membership checks on every cross-team move For any object transfer, validate both source ownership and destination tenant membership before the write commits.
What's in the full article
Aikido's full blog post covers the operational detail this analysis intentionally leaves for the source:
- Step-by-step exploitation traces for the open redirect, including the listener setup used to confirm token exfiltration.
- The exact GraphQL mutation structure that bypassed the UI restriction and enabled the stored XSS path.
- The request-move payload and backend logic path that allowed a request to cross team boundaries.
- Patch references and vulnerability identifiers for teams tracking remediation in self-hosted environments.
👉 Read Aikido’s analysis of Hoppscotch token theft, XSS, and access control flaws →
Hoppscotch access control failures: what IAM teams should notice?
Explore further
02/08/2026 12:58 pm
Application security flaws become identity incidents when the application is a credential conveyor. The Hoppscotch findings are not just about web bugs. They show how login redirects, inherited headers, and team workflows can convert ordinary flaws into token theft and cross-tenant exposure. For identity teams, the relevant control question is whether the application can move credentials or authorisation context without a second layer of destination-aware checks.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
A question worth separating out:
Q: How should IAM and application teams respond when identity data can move through workflows?
A: They should treat workflow objects, not just users, as identity-bearing assets. That means validating destination authorisation, stripping inherited credentials on transfer, and monitoring for execution paths that mix trust domains. When requests, tokens, and secrets travel together, the access model must be enforced at each boundary.
👉 Read our full editorial: Hoppscotch AI pentest findings expose token theft and XSS paths
