CVE-2026-69189 in Hoppscotch
Summary
by MITRE • 08/18/2026
Hoppscotch is an open source API development ecosystem. Prior to 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, while toggleHistoryStarStatus and removeRequestFromHistory in the UserHistory service accept another user's history identifier without enforcing userUid ownership, allowing an authenticated workspace member to read private request history, session data, request contents, authorization headers, environment values, and settings and to modify or delete the victim's private history entries. This issue is fixed in version 2026.6.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
Hoppscotch serves as a prominent open-source API development ecosystem designed for testing and debugging APIs through REST and GraphQL interfaces. The application facilitates collaborative workflows by allowing multiple workspace members to share environments, sessions, and request histories. However, prior to version 2026.6.0, the platform suffered from significant access control vulnerabilities within its GraphQL API layer that compromised data isolation between distinct user accounts operating within the same workspace. These flaws stemmed primarily from insufficient authorization checks on specific GraphQL paths and mutation operations, leading to a breakdown in tenant-level security boundaries where authenticated users could inadvertently or maliciously access resources belonging to other members of their shared workspace.
The core technical flaw involves improper enforcement of ownership constraints for sensitive user-specific data structures. Specifically, the GraphQL endpoints exposing team details via teamMembers.user, along with paths handling RESTHistory, GQLHistory, currentRESTSession, and currentGQLSession failed to validate that the requesting authenticated user was the legitimate owner of the requested resource. In a properly secured system, each query or mutation must verify that the session context matches the identity associated with the data being accessed. Instead, Hoppscotch allowed any authenticated member of a workspace to retrieve private User data belonging to another member simply by manipulating input parameters or relying on default resolution logic that did not strictly bind the userUid field to the requester's credentials. This lack of object-level authorization control permitted unauthorized reading of highly sensitive information including request history, active session states, and configuration settings.
Beyond passive data exfiltration, the vulnerability extended into destructive actions through mutations in the UserHistory service. The toggleHistoryStarStatus and removeRequestFromHistory operations accepted a history identifier without enforcing userUid ownership validation. This omission allowed an attacker to modify or delete private history entries belonging to other workspace members. By supplying arbitrary identifiers that corresponded to another user's records, an authenticated actor could alter the state of their colleagues' workspaces, potentially causing data loss or disrupting ongoing development workflows. The combination of read and write access violations created a comprehensive breach of confidentiality and integrity for user-generated content within the application.
The operational impact of these vulnerabilities is severe given the nature of API development tools which often handle sensitive credentials and proprietary logic. An authenticated workspace member could exfiltrate private request contents, authorization headers containing tokens or API keys, environment values that may include secrets such as database passwords or service account credentials, and global settings configurations. This exposure not only violates user privacy but also poses a significant risk to organizational security posture by leaking authentication material that could be leveraged for further attacks against external services targeted via the exposed APIs. Furthermore, the ability to delete history entries undermines audit trails and operational continuity, making it difficult for teams to track changes or recover previous states of their API development efforts.
To mitigate these risks, organizations using Hoppscotch must immediately upgrade to version 2026.6.0 where these access control issues have been resolved through stricter validation logic in the GraphQL resolvers and mutations. For environments unable to update immediately due to compatibility constraints or deployment cycles, temporary mitigations should focus on restricting workspace membership to only those individuals who require direct collaboration, thereby reducing the attack surface of potential insider threats. Additionally, implementing strict logging and monitoring for unusual patterns of history access or deletion can help detect exploitation attempts in real-time. It is also advisable to rotate any credentials that may have been exposed through authorization headers during periods when the vulnerability was active.
From a classification perspective, this incident aligns with CWE-284 Improper Access Control, specifically reflecting failures in enforcing ownership constraints on resources. The ability of an authenticated user to read and modify data belonging to another user within the same context is characteristic of broken object level authorization vulnerabilities often cataloged under OWASP API Security Top 10 as API5 Broken Object Level Authorization. In terms of adversary behavior mapping, this vulnerability facilitates actions consistent with ATT&CK technique T1078 Valid Accounts, where an attacker leverages legitimate credentials to access unauthorized resources, and potentially T1489 Service Stop if the deletion capabilities are exploited for denial of service purposes against specific user workflows. Ensuring robust input validation and context-aware authorization checks in all API endpoints is critical to preventing similar breaches in future versions or other collaborative software platforms.