Hoppscotch AI pentest findings expose token theft and XSS paths

At a glance

What this is: Aikido’s analysis of Hoppscotch found three vulnerabilities that could lead to token theft, stored XSS, and cross-team request abuse in versions up to 2026.2.1.

Why it matters: IAM and application security teams should treat redirect validation, browser-origin trust, and collection-level authorisation as linked controls because weaknesses in any one of them can expose session tokens, API keys, or cross-tenant request paths.

By the numbers:

• Hoppscotch had three vulnerabilities present in versions up to and including 2026.2.1.

Context

Hoppscotch is an API development platform, but the security problem here is not the category of software. The issue is that browser-based authentication, GraphQL mutation paths, and collection sharing logic can create trust gaps that turn ordinary application bugs into identity exposure. For IAM and security teams, the relevant question is how a development tool handles tokens, redirects, and inherited authorisation headers.

The three findings show different failure modes with the same governance consequence: application controls were allowed to determine identity outcomes. An open redirect can move session tokens off-domain, XSS can inherit the victim’s browser context, and broken access control can let one team inject requests into another team’s workspace. That pattern is not unusual in self-hosted tooling when authorisation is implemented at the feature layer rather than the trust boundary.

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. Attackers can hide malicious destinations in fragments, encodings, or traversal segments, then rely on the application returning the original value. The fix is to validate the final effective destination after canonicalisation and reject any mismatch between checked and returned forms.

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. When the app also stores tokens, headers, or variables in reachable state, XSS becomes a privilege amplifier rather than just a content flaw. Isolation and sanitisation are the key controls.

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. That creates a cross-boundary write path, which is especially risky in collaborative tools where requests can inherit headers or variables. Teams should test null-parameter branches, because optional inputs often change which permission checks run.

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.

Technical breakdown

Open redirects and token exfiltration

An open redirect becomes an identity problem when authentication flows carry bearer tokens or session tokens through a redirect_uri parameter. If validation only checks for a string prefix such as http://localhost, an attacker can register a lookalike domain that passes the check but resolves elsewhere. The browser then sends the sensitive token to the attacker’s endpoint, which can be replayed to impersonate the user. This is a classic example of why redirect handling must parse and normalise URLs before trust is assigned.

Practical implication: validate redirect targets with a real URL parser and allowlist exact origins, not string prefixes.

Stored xss in same-origin mock services

Stored XSS in a same-origin feature is more dangerous than a simple content injection bug because the payload runs with the application’s own origin and inherits its session context. In this case, a GraphQL mutation was used to bypass front-end restrictions and set a response header to text/html, turning a mock response into executable script. Once the victim visits the mock endpoint, the browser executes attacker-controlled JavaScript that can read data, alter what the user sees, or pivot into adjacent application actions.

Practical implication: enforce server-side content sanitisation and isolate mock or preview services with strict CSP and origin separation.

Broken access control in team request movement

Broken access control here is not about generic authorisation failure. It is a specific destination-collection validation gap: the backend checked the source request and team membership, but skipped the destination team check when nextRequestID was null. That allowed an attacker to move a request into another team’s collection and rely on a victim to execute it. Because requests can inherit headers or contain variables, the resulting blast radius includes credentials and API keys, not just data visibility.

Practical implication: authorise both source and destination objects in every move or reorder operation, including null-path variants.

Threat narrative

Attacker objective: The attacker aims to steal session tokens, hijack a victim account, and use trusted application workflows to expose secrets or cross-team data.

1. Entry began with an application trust gap in redirect handling, where a crafted redirect_uri could steer authentication tokens to an attacker-controlled domain.
2. Credential access occurred when the victim completed authentication and the application sent session tokens to the malicious endpoint, enabling replay as the victim.
3. Escalation followed through same-origin script execution and cross-team request injection, which gave the attacker access to application context and potential credential-bearing requests.
4. Impact was account takeover, data exposure through browser-context XSS, and possible exfiltration of credentials and API keys from inherited request headers.

Breaches seen in the wild

• SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Open redirect and XSS are identity problems when tokens are in play: the first lets an attacker redirect a credential, and the second lets an attacker use the victim’s authenticated browser session. Together they show why session security depends on both strict URL handling and origin isolation. The practitioner takeaway is to review every feature that can carry or reflect auth material, especially in self-hosted collaboration tools.

Access control checks must cover both source and destination state: the Hoppscotch request-move issue shows what happens when authorisation is checked only for the object being moved, not for the target collection. That is a governance assumption failure, not a simple missing permission rule. The practitioner takeaway is to test every move, copy, reorder, and reassignment workflow for destination-side enforcement gaps.

Cross-tenant request injection is a machine-identity adjacent risk: once requests can inherit authorization headers or embedded variables, a collaboration feature becomes a secret-disclosure path. The real control issue is not just user roles, but whether application workflows can transport credentials across administrative boundaries. The practitioner takeaway is to map where tokens, API keys, and inherited headers are reused inside development tooling and to constrain those flows explicitly.

Trust boundaries in dev tooling need stronger runtime isolation: the same-origin mock server example shows how preview and testing features can collapse into production-grade risk if they share session context. That is a pattern security teams should expect in API development platforms and internal tooling. The practitioner takeaway is to separate untrusted content execution from authenticated application surfaces wherever users can preview or replay responses.

What this signals

Hoppscotch-style failures show why application security and IAM governance have to meet at the workflow layer: session tokens, inherited headers, and GraphQL mutations are all part of the identity attack surface when tools allow requests to move across trust boundaries. The control gap is not just vulnerability presence, but whether the product’s state transitions are authorised end to end.

The named concept here is request-boundary collapse: when a development platform lets request content, destination collections, and browser-origin trust intersect without explicit separation, the platform turns collaboration into credential exposure. IAM teams should expect these patterns anywhere authorisation is delegated to the application instead of enforced on the destination object.

Security teams should also test null-path and alternate-path logic, because optional parameters often disable the very permission checks that appear to exist in normal flows. That is where application features become escalation paths, and where identity controls need to be enforced with automated abuse-case testing rather than policy statements alone.

For practitioners

• 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.
• Review inherited headers and variables Map any workflow that can carry authorization headers, API keys, or secret-bearing variables across collections, then block cross-team propagation.
• Test null-path permission branches Add security tests for edge cases where optional parameters bypass validation logic, because those branches often hide the authorisation gap.

Key takeaways

• Hoppscotch’s flaws show how open redirect, stored XSS, and broken access control can combine into a single identity and secret-exposure problem.
• The article describes three distinct failure modes, including token exfiltration for account takeover and a cross-team request path that could leak credentials and API keys.
• The limiting control is not one generic security fix but strict destination-side authorisation, real URL parsing, and isolation of untrusted content from authenticated sessions.

Key terms

• Open redirect: An open redirect is a web endpoint that forwards a visitor to a different destination without strict validation. In identity and AI attack chains, it is dangerous because it can make a malicious payload look like a trusted domain, increasing the chance that users will follow the link and trigger the next stage of abuse.
• Stored Xss: Stored XSS happens when an application saves malicious script in backend content such as comments, profiles, or posts, then serves it to other users later. Because the payload persists, one successful injection can trigger repeated execution across many authenticated sessions.
• Destination-side Authorisation: Destination-side authorisation is the practice of checking permissions on the target object, not only the source object being modified. It matters in move, copy, reorder, and delegation workflows because access to the original item does not imply access to the destination context.
• Inherited Headers: Inherited headers are authentication or context headers that follow a request as it moves through a workflow or system boundary. They are dangerous when a feature allows content to be replayed, copied, or moved between tenants, because the headers can carry secrets into the wrong trust zone.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and IAM practitioners connect identity controls to the broader access patterns that shape risk in modern platforms.