Critical Hoppscotch Bug Enables Full Server Takeover – Patch Now
A maximum-severity vulnerability has been disclosed in the self-hosted version of Hoppscotch, the widely used open-source API development platform.
Tracked as CVE-2026-50160 and assigned a CVSS 3.1 base score of 10.0, the flaw allows unauthenticated attackers to overwrite JWT signing secrets and seize complete administrative control of a target server using a single crafted HTTP request.
Critical Hoppscotch Vulnerability
Hoppscotch published the details via GitHub Security Advisory GHSA-j542-4rch-8hwf on May 28, 2026. All self-hosted backend deployments running version 2026.4.1 and earlier are affected. A patch is available in version 2026.5.0.
The vulnerability stems from a classic mass assignment weakness (CWE-915) in the POST /v1/onboarding/config endpoint. The NestJS ValidationPipe governing the backend is configured without the whitelist: true option, meaning the framework does not strip undeclared properties from incoming request bodies.
This allows an attacker to inject arbitrary configuration keys including JWT_SECRET and SESSION_SECRET directly into the database, even though these fields are never declared in the SaveOnboardingConfigRequest DTO.
Four independent security failures combine to make exploitation trivial:
- Missing
whitelist: trueflag allows undeclared properties to pass through the validation layer unchecked - Unconstrained
Object.entries(dto)iteration ininfra-config.service.tsprocesses every property on the DTO using a TypeScript cast with no runtime validation - Silent default case in
validateEnvValuescausesJWT_SECRETandSESSION_SECRETto fall through without resistance, allowing the database write to proceed - No authentication guard on the onboarding controller, leaving the endpoint fully accessible to unauthenticated requests while
usersCount === 0
Exploitation Window and Attack Flow
The exploit is effective only during the brief window between deployment and the completion of the onboarding process precisely when a self-hosted instance is most likely to be internet-exposed.
An attacker first queries GET /v1/onboarding/status to confirm onboarding is incomplete, then sends a single crafted POST request embedding attacker-controlled JWT_SECRET and SESSION_SECRET values alongside legitimate onboarding fields.
The attack was confirmed with a live proof-of-concept on a fresh Hoppscotch AIO Docker deployment, with database queries used to verify the overwritten secrets post-exploitation.
Once the JWT signing key is compromised, the consequences escalate rapidly. Attackers can forge arbitrary JWT tokens for any user UID, including administrator accounts, bypassing all authentication guards without valid credentials.
The attacker retains persistent admin access even after legitimate password resets, because the compromised secret remains in the database until the entire deployment is rebuilt.
All user workspaces, API collections, team data, and stored API keys become accessible through authenticated GraphQL queries. Overwriting SESSION_SECRET simultaneously invalidates every active user session while enabling the attacker to freely mint new ones.
Patch and Mitigation
Hoppscotch addressed the issue in backend version 2026.5.0 by enabling whitelist: true and forbidNonWhitelisted: true on the global ValidationPipe, ensuring undeclared properties are stripped before reaching the service layer.
Additional hardening measures include key allowlist enforcement in update OnboardingConfig, explicit rejection of security-critical keys insidevalidateEnvValues, and protection of the onboarding endpoint with a one-time setup token at first boot.
All self-hosted Hoppscotch operators should upgrade to version 2026.5.0 immediately. Deployments still in the onboarding phase are at the highest risk and should be treated as potentially compromised if exposed to the internet before patching.
No Comment! Be the first one.