CVE-2026-59720 in Hoppscotch
Summary
by MITRE • 07/09/2026
Hoppscotch is an open source API development ecosystem. Prior to 2026.6.0, mock server creation in mock-server.service.ts does not persist the isPublic input field while schema.prisma defaults isPublic to true, causing mock servers linked to private collections to be publicly accessible without authentication and potentially expose sensitive API data. This issue is fixed in version 2026.6.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/09/2026
The vulnerability identified in Hoppscotch's mock server functionality represents a critical authorization bypass issue that stems from a fundamental mismatch between frontend input handling and backend database schema defaults. This security flaw exists in the mock-server.service.ts component where the isPublic field, which should control whether a mock server is accessible to all users or restricted to specific collections, fails to properly persist user-provided values. The technical implementation demonstrates a classic case of improper data validation and synchronization between application layers, where the frontend accepts user input for access control but the backend service does not adequately validate or store this information.
The root cause of this vulnerability lies in how the system handles the isPublic parameter during mock server creation processes. When users attempt to create mock servers linked to private collections, they expect these resources to remain restricted to authorized parties only. However, due to the schema.prisma default configuration that sets isPublic to true by default, any mock server created without explicit override of this field becomes publicly accessible regardless of the user's intent or collection permissions. This design flaw creates a dangerous assumption that all mock servers should be public by default, ignoring the security context in which they were created and potentially exposing sensitive API data to unauthorized parties.
The operational impact of this vulnerability extends beyond simple access control breaches, as it fundamentally undermines the security model of private collections within Hoppscotch's ecosystem. Attackers could exploit this weakness to gain unauthorized access to mock servers that should only be accessible to specific users or teams, potentially leading to exposure of sensitive API endpoints, data structures, or implementation details that could be leveraged for further attacks. This issue particularly affects organizations using private collections to test APIs with confidential data, as the default public accessibility creates an unintended attack surface that violates standard security practices and could result in compliance violations.
This vulnerability aligns with several cybersecurity frameworks and threat modeling categories including CWE-284 (Improper Access Control) and addresses concerns related to the ATT&CK technique T1078.1.001 (Valid Accounts: Default Accounts). The flaw demonstrates poor input validation practices and improper state management between different system components, creating a scenario where user intent is not properly respected in the security configuration process. Organizations using Hoppscotch for API development and testing may unknowingly expose their internal API testing environments to public access, potentially compromising sensitive data or exposing implementation details that could be used in targeted attacks against their applications.
The mitigation strategy requires implementing proper input validation and ensuring that user-provided access control parameters are consistently stored and enforced throughout the application lifecycle. This includes updating the mock-server.service.ts component to explicitly handle the isPublic field during server creation, ensuring that database schema defaults do not override user intent, and implementing comprehensive testing procedures to verify that access control configurations persist correctly. The fix implemented in version 2026.6.0 addresses these concerns by properly synchronizing frontend inputs with backend storage mechanisms and enforcing consistent security policies across all mock server creation operations.