CVE-2026-69189 Overview
Hoppscotch, an open source API development ecosystem, contains a broken access control vulnerability in multiple GraphQL paths and the UserHistory service. Prior to version 2026.6.0, the team, teamMembers.user, RESTHistory, GQLHistory, currentRESTSession, currentGQLSession, environments, globalEnvironments, and settings GraphQL paths expose another workspace member's private User data. Additionally, the toggleHistoryStarStatus and removeRequestFromHistory mutations accept another user's history identifier without enforcing userUid ownership. An authenticated workspace member can read private request history, session data, authorization headers, environment values, and settings, and can modify or delete a victim's private history entries.
Critical Impact
Authenticated workspace members can exfiltrate other users' API request contents, authorization headers, and environment secrets while tampering with victims' private history entries.
Affected Products
- Hoppscotch (open source API development ecosystem)
- All versions prior to 2026.6.0
- Backend GraphQL API and UserHistory service
Discovery Timeline
- 2026-08-18 - CVE CVE-2026-69189 published to NVD
- 2026-08-18 - Last updated in NVD database
Technical Details for CVE-2026-69189
Vulnerability Analysis
The vulnerability is a broken access control flaw classified under CWE-200: Exposure of Sensitive Information to an Unauthorized Actor. Multiple GraphQL resolvers return private fields of the User object when queried by another workspace member. Fields such as currentRESTSession, currentGQLSession, environments, globalEnvironments, settings, RESTHistory, and GQLHistory were serialized into responses without validating that the requesting user matched the resource owner.
The UserHistory service compounds the issue. The toggleHistoryStarStatus and removeRequestFromHistory mutations accept a history record identifier but never verify that the identifier's userUid matches the authenticated caller. This allows any workspace member to alter another member's history.
Root Cause
The resolvers dereferenced creator or user objects and returned their private session and history fields directly to any caller. The UserHistory mutations trusted the supplied record ID rather than enforcing an ownership predicate against the authenticated userUid.
Attack Vector
Exploitation requires an authenticated account with workspace membership. The attacker issues a crafted GraphQL query referencing another user or supplies a target user's history record ID to the vulnerable mutations. No user interaction from the victim is required.
// Patch: packages/hoppscotch-backend/src/mock-server/mock-server.resolver.ts
if (E.isLeft(creator)) throwErr(creator.left);
return {
...creator.right,
- currentGQLSession: JSON.stringify(creator.right.currentGQLSession),
- currentRESTSession: JSON.stringify(creator.right.currentRESTSession),
+ currentGQLSession: null,
+ currentRESTSession: null,
};
}
Source: GitHub Commit 9cc980b
The patch replaces the serialized private session payloads with null so that private session data is no longer returned to callers who are not the resource owner.
// Patch: packages/hoppscotch-backend/src/published-docs/published-docs.service.ts
const creator = user
? {
...user,
- currentGQLSession: JSON.stringify(user.currentGQLSession),
- currentRESTSession: JSON.stringify(user.currentRESTSession),
+ currentGQLSession: null,
+ currentRESTSession: null,
}
: null;
Source: GitHub Commit 9cc980b
Detection Methods for CVE-2026-69189
Indicators of Compromise
- GraphQL queries from authenticated users that reference other users' RESTHistory, GQLHistory, currentRESTSession, currentGQLSession, environments, globalEnvironments, or settings fields.
- Invocations of toggleHistoryStarStatus or removeRequestFromHistory where the target history record's userUid does not equal the authenticated caller's userUid.
- Unexpected deletions or starred-status changes in user history tables not initiated by the owning user.
Detection Strategies
- Enable verbose GraphQL query logging on the Hoppscotch backend and compare query subject IDs against the authenticated session subject.
- Alert on repeated resolver access to team, teamMembers.user, and history fields resolved for user IDs other than the requester.
- Correlate database write events on the UserHistory table with the requesting user's UID to identify cross-account modifications.
Monitoring Recommendations
- Ingest Hoppscotch backend application and database audit logs into a centralized log platform for retention and correlation.
- Baseline normal per-user history mutation volume and alert on outliers that may indicate enumeration or bulk tampering.
- Track GraphQL query complexity and object counts to detect scraping of team-member records.
How to Mitigate CVE-2026-69189
Immediate Actions Required
- Upgrade Hoppscotch to version 2026.6.0 or later, which contains the ownership enforcement fix.
- Rotate any secrets, API keys, or authorization tokens that were stored in Hoppscotch environments or request history prior to the upgrade.
- Audit UserHistory records for unauthorized modifications or deletions and restore from backups where necessary.
Patch Information
The fix is delivered in Hoppscotch release 2026.6.0 via Pull Request #6409 and commit 9cc980b. Refer to the GitHub Security Advisory GHSA-p25p-g9jp-7q46 for full details.
Workarounds
- Restrict Hoppscotch workspace membership to trusted users until the upgrade is applied.
- Remove sensitive credentials from shared environments and use short-lived tokens where feasible.
- Place the Hoppscotch backend behind an authenticated reverse proxy that limits access to known internal networks.
# Upgrade Hoppscotch self-hosted deployment to the patched release
docker pull hoppscotch/hoppscotch:2026.6.0
docker compose down
docker compose up -d
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

