Hoppscotch AI pentest findings expose token theft and XSS paths

At a glance

What this is: Aikido reports that AI pentest agents found three high and medium severity flaws in Hoppscotch, including token theft, stored XSS, and cross-team request movement.

Why it matters: This matters to IAM, PAM, and NHI teams because application-level flaws often become credential compromise paths when session tokens, API keys, and inherited authorisation headers are exposed.

By the numbers:

• Aikido said its AI pentest agents found two high-severity vulnerabilities and one medium-severity vulnerability in versions up to and including 2026.2.1.

👉 Read Aikido’s analysis of Hoppscotch token theft, XSS, and access control flaws

Context

Open redirect, stored cross-site scripting, and broken access control are not abstract web issues. In practice, they become identity and secret-handling failures when an application issues session tokens, accepts delegated access, or lets one user influence another team’s workflow. This article is primarily about how seemingly ordinary application bugs can turn into account takeover and credential exposure.

For IAM and NHI practitioners, the interesting point is not the exploit mechanics alone. It is the way application trust boundaries, token handling, and inherited permissions can turn a user action into a credential exfiltration path. That intersection is especially relevant in developer platforms, API tools, and systems that move data or requests between teams.

AI-assisted pentesting also changes the tempo of discovery. The article shows a typical modern pattern rather than an edge case: automated analysis can surface auth, XSS, and access control weaknesses quickly enough that defenders need stronger release gates and tighter identity-aware validation before exposure reaches production users.

Key questions

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. If the application only checks a URL prefix or a partial string match, the browser can still resolve the request to an attacker-controlled host. That turns an authentication step into token exfiltration and can enable account takeover.

Q: Why do same-origin mock or preview features increase security risk?

A: Because the browser treats same-origin content as trusted application state. If untrusted mock content can execute in that origin, scripts can read visible data, manipulate the interface, and interact with authenticated state. The risk rises sharply when API-level writes bypass the front end and let attackers inject executable content directly.

Q: What do security teams get wrong about moving requests across teams?

A: They often validate the source object but forget the destination boundary. In multi-tenant systems, owning or editing a request in one team does not prove that another team’s collection is authorised. If destination membership is skipped, cross-tenant injection can carry inherited secrets into the wrong workflow.

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.

Technical breakdown

Open redirects turn login flow mistakes into token theft

An open redirect exists when an application accepts a destination URL without sufficiently validating where the browser will actually go. In this case, the login flow used a redirect parameter to send session tokens after authentication, but the validation only checked that the string started with a localhost prefix. That is not enough, because attacker-controlled domains can embed that prefix and still resolve to an external host. Once the browser follows the crafted URL, the token lands with the attacker instead of the intended local endpoint.

Practical implication: validate redirect targets with a real URL parser and explicit allowlists, not prefix checks.

Stored XSS in a same-origin mock server expands privilege

Stored XSS becomes more serious when the vulnerable content is served from the same origin as the main application. Here, the mock server allowed user-controlled response content to execute in the victim browser, which meant the script inherited the application’s trust context and could read or modify visible data. The article also shows how API-level writes bypassed front-end restrictions, which is a common weakness when business logic is enforced only in the UI layer. Same-origin execution turns a content injection bug into a session and data exposure issue.

Practical implication: enforce server-side content validation and isolate untrusted preview or mock content with a strict Content Security Policy.

Broken access control in request movement can cross team boundaries

The request-move flaw is a destination-authorisation failure, not just a source-side validation gap. The backend checked whether the attacker owned the source request, but skipped a team membership check for the destination collection when the next request reference was null. That allowed a request to be injected into another team’s collection, where inherited headers or variables could carry secrets into an attacker-influenced execution path. This is a classic multi-tenant control failure: the system validated ownership of the object being moved, but not the tenant boundary being crossed.

Practical implication: validate both source and destination tenant membership whenever objects can be moved across collections or workspaces.

Threat narrative

Attacker objective: The attacker objective is to steal session tokens or embedded credentials and use them to impersonate users or pivot into another team’s data and workflow context.

1. Entry occurred through a crafted login redirect, a GraphQL mutation that set malicious mock response content, or a request-move action that crossed team boundaries.
2. Credential access followed when the open redirect leaked authentication tokens and the injected request could carry inherited API keys or authorization headers.
3. Impact came from account takeover, browser-side data access, and the possibility of secret exfiltration from another team’s workflow.

Breaches seen in the wild

• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Same-origin preview and mock features create a hidden trust zone. When user-supplied content is rendered from the same origin as the primary app, the browser stops distinguishing between preview data and trusted application state. That creates an avoidable escalation path for XSS, especially when API writes can bypass the UI. Practitioners should treat mock servers, sandboxes, and previews as identity-sensitive surfaces, not cosmetic features.

Multi-tenant request movement needs tenant-boundary enforcement, not just object ownership checks. The broken access control shows a specific governance assumption failure: owning a source request does not mean the destination collection is authorised. That is a workload identity and access model problem as much as an application bug. In multi-team platforms, the destination tenant must be validated every time an object crosses a boundary.

AI-assisted pentesting is collapsing discovery time for routine but dangerous flaws. The article demonstrates that automated agents can find redirect, XSS, and access control issues quickly enough to matter before broad exposure or exploitation. That increases pressure on release engineering, not just security review. Teams should expect faster identification of identity-adjacent flaws in developer tools, API platforms, and internal workflows.

Request integrity is now an identity control, not only an application concern. When a request can be moved, previewed, or replayed across teams, the security model must preserve who can act, where they can act, and what inherited secrets travel with the object. That is exactly where classic IAM and NHI governance meet application security. The control gap is boundary validation at the moment of delegation.

From our research:

• 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.
• Forward link: Review 52 NHI Breaches Analysis for the breach patterns that most often turn secret exposure into operational impact.

What this signals

Credential-aware application design is becoming part of NHI governance. When a web app can leak session tokens, inherited headers, or API keys, the boundary between application security and identity security disappears. Teams should expect more findings where access control, secret handling, and workflow design fail together, and they should align remediation with Ultimate Guide to NHIs , Why NHI Security Matters Now and the OWASP NHI Top 10.

Cross-tenant request movement is a governance problem, not just a bug class. The practical signal for programme owners is whether your platform can prove destination authorisation every time an object moves. If that cannot be demonstrated, inherited permissions and secret propagation remain unresolved exposure paths. That is a useful lens for reviewing workflow tools, internal developer platforms, and AI-assisted testing outputs.

The fastest-growing risk is not novel exploitation, but the speed at which automation exposes ordinary mistakes. That means release pipelines need stronger validation for redirects, same-origin rendering, and object transfers before a defect becomes an identity incident. For identity programmes, the priority is to make secret movement and tenant boundary checks visible enough to measure and govern.

For practitioners

• 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. Review all login and device flows for token handoff logic that depends on string matching. This is the kind of control that should be tested alongside the Ultimate Guide to NHIs and the OWASP NHI Top 10.
• 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. Do not rely on the front end to block dangerous headers or HTML bodies. If the preview surface can read authenticated state, treat it as a production-risk path.
• 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. Add tests for null or optional path parameters that might bypass the destination check. This pattern belongs in the same review set as the 52 NHI Breaches Analysis because inherited permissions often mask the real boundary failure.
• Review inherited headers and variables in moved requests Assume that moved or cloned requests may carry API keys, bearer tokens, or environment variables into the wrong collection. Strip or rebind inherited secrets when a request crosses a team boundary, and alert on any execution path that mixes trust domains. This is especially important in developer tooling where workflow convenience often outruns access governance.
• Use AI-assisted testing as a release gate, not a post-release net Run automated pentesting before deployment for login flows, same-origin content rendering, and access-control mutations that affect tenant boundaries. Feed findings into the same remediation workflow used for auth and NHI issues so that identity-adjacent bugs do not sit in separate queues. That aligns well with lessons from the 52 NHI Breaches Report.

Key takeaways

• Hoppscotch’s flaws show how application bugs become identity incidents when tokens, inherited headers, and tenant boundaries are weakly enforced.
• The article highlights three distinct exposure paths: token theft through open redirect, browser-side compromise through stored XSS, and cross-team request injection through broken access control.
• The limiting controls are precise: URL allowlisting, same-origin isolation for untrusted content, and destination-authorisation checks on every cross-team object move.

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.
• Cross-Tenant Access Control: Cross-tenant access control is the set of checks that prevents one team, customer, or workspace from acting inside another’s boundary. In multi-tenant platforms, it must validate both the source object and the destination context, or object movement can become a stealthy exposure path.
• Inherited Secrets: Inherited secrets are credentials, tokens, or headers that travel with a request, collection, or workflow object as it moves through a system. They create hidden risk because a seemingly harmless action, such as reordering or cloning a request, can carry sensitive authentication material into the wrong execution context.

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.

👉 Aikido’s full post covers the exploit paths, proof steps, and remediation notes in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity controls to the broader security programmes they run every day.