CVE-2026-59720: Hoppscotch Mock Server Public Exposure Vulnerability

Technical summary

The vulnerability exists in mock-server.service.ts where the isPublic input parameter is not persisted during mock server creation. The Prisma schema defaults the isPublic field to true when not explicitly set, resulting in mock servers being created with public visibility regardless of the privacy setting of their parent collections. This causes mock servers linked to private collections to be accessible without authentication, exposing the underlying API specifications and potentially sensitive test data. The flaw is an improper handling of access control defaults (CWE-200, CWE-284).

Business impact

Teams using Hoppscotch to manage private API specifications face unintended exposure of API schemas, endpoints, and test data to the public internet. This could enable reconnaissance attacks, API abuse, or competitive intelligence gathering. Organizations relying on Hoppscotch for internal API development and documentation may inadvertently violate compliance requirements by exposing sensitive technical details. The risk is particularly acute for organizations with strict data governance policies or those handling APIs in regulated industries.

Affected systems

Hoppscotch versions prior to 2026.6.0 are affected. This includes self-hosted and cloud-hosted instances of the platform. Any deployment where users create mock servers from collections marked as private is vulnerable. The open source nature of Hoppscotch means affected instances exist across diverse environments—from individual developer machines to enterprise deployments.

Exploitability

Exploitation requires only network access to a Hoppscotch instance and the ability to enumerate or guess mock server URLs. No authentication, special privileges, or user interaction is required. The ease of exploitation is high; an attacker with knowledge of a target's use of Hoppscotch could systematically discover exposed mock servers and their associated API specifications. The CVSS 3.1 score of 7.5 (HIGH) reflects the network-accessible, unauthenticated nature of the exposure.

Remediation

Upgrade Hoppscotch to version 2026.6.0 or later, which properly persists the isPublic field during mock server creation. Organizations must verify the setting is correctly propagated after upgrading. For teams unable to patch immediately, restrict network access to Hoppscotch instances using firewall rules or authentication gateways, and audit existing mock servers for unintended public exposure.

Patch guidance

Update to Hoppscotch version 2026.6.0 or later. Consult the official Hoppscotch repository and release notes for deployment-specific guidance, as patching procedures differ between self-hosted and managed instances. After patching, test mock server creation to confirm the isPublic setting is now correctly saved when set to private. Review and remediate any mock servers created prior to the upgrade.

Detection guidance

Audit all existing mock servers in your Hoppscotch instances to identify those marked as public but linked to private collections. Review access logs for unauthenticated requests to mock server endpoints. For self-hosted deployments, query the underlying database to compare the isPublic flag against the parent collection's privacy setting. Monitor for scanning or enumeration attempts targeting mock server endpoints that may indicate external discovery.

Why prioritize this

This vulnerability is HIGH priority because it enables unauthenticated, network-accessible disclosure of sensitive API specifications with no user interaction required. Teams managing proprietary APIs or APIs in regulated environments should prioritize patching immediately. The fix is straightforward and available, and the risk of continued exposure is material for any organization relying on Hoppscotch's privacy controls.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects a high-severity information disclosure vulnerability with network-adjacent attack vector (AV:N), low attack complexity (AC:L), no privileges required (PR:N), no user interaction (UI:N), and confidentiality impact (C:H) while integrity and availability are not affected. The score appropriately emphasizes the ease of exploitation and the sensitive nature of API specifications as attack surface information.

Frequently asked questions