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.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “Aikido Attack finds multiple 0-days in Hoppscotch”.
By the numbers:
- Hoppscotch had three vulnerabilities present in versions up to and including 2026.2.1.
Key questions
Q: What breaks when redirect validation checks only part of the URL?
A: The control fails when the server validates one URL component but the browser executes another.
Q: Why do same-origin XSS bugs become identity and secret exposure issues?
A: Because the browser executes attacker-controlled script with the victim’s authenticated origin, which can read visible data, call application APIs, and interact with sensitive sessions.
Q: Where do collection move and reorder controls fail in practice?
A: They fail when the application checks the source object but skips authorisation on the destination object or team.
Practitioner guidance
- Harden redirect validation Replace prefix-based checks with parsed URL allowlists for every authentication redirect, including device-login and desktop authentication flows.
- Isolate mock and preview execution Serve mock responses from a separate origin or tightly sandbox them so injected HTML or JavaScript cannot inherit the main application session.
- Authorise destination collections explicitly Require an access check on the target collection or team for every move, reorder, or injection workflow, even when nextRequestID is null.
Bottom line: Hoppscotch’s flaws show how open redirect, stored XSS, and broken access control can combine into a single identity and secret-exposure problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:58 pm
Application trust boundaries now decide identity outcomes: when redirect handling, browser origin policy, and GraphQL mutations are all part of the same workflow, a flaw in any one layer can become an access event. That means identity governance for developer tools cannot stop at login flows; it has to account for how tokens move after authentication. The practitioner takeaway is to treat application trust boundaries as part of the identity control plane, not as a separate web-security concern.
A question worth separating out:
Q: How should IAM teams govern tools that carry API keys and auth headers between collections?
A: Treat those tools as secret-moving systems, not just workflow editors. Every path that copies, reorders, imports, or replays requests should be scoped by team, collection, and destination context, with tests that prove credentials cannot cross tenant boundaries. Without that, a harmless-looking workflow can become a secret exfiltration path.
👉 Read our full editorial: Hoppscotch AI pentest findings expose token theft and XSS paths