Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-69189

CVE-2026-69189: Hoppscotch Information Disclosure Flaw

CVE-2026-69189 is an information disclosure vulnerability in Hoppscotch that exposes private user data to workspace members. This post covers technical details, affected versions, security impact, and mitigation.

Published:

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.

typescript
// 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.

typescript
// 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.
bash
# 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.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.