CVE-2026-50160: Critical unauthenticated mass assignment in Hoppscotch backend

Who is affected?

The affected product is the self-hosted Hoppscotch backend. The vulnerable version range is explicitly documented as 2026.4.1 and earlier. The fixed release is 2026.5.0. If you are running a self-hosted deployment and have not upgraded beyond 2026.4.1, you should assume your instance is vulnerable until proven otherwise.

Exposure depends on deployment state. The NVD description says exploitation is possible when an attacker can reach a fresh instance before onboarding completes, or when no users exist. That matters operationally: not every long-running Hoppscotch installation will present the same attack window, but internet-exposed deployments, newly provisioned systems, test environments, and instances rebuilt from automation may be especially at risk. If you do not know whether onboarding was ever reachable externally, treat that uncertainty as a reason to patch urgently and review access logs.

Why this matters operationally

This is not just a setup bug with limited impact. Overwriting JWT_SECRET gives an attacker control over the key used to sign authentication tokens. Once the signing key is attacker-controlled, they can forge JWTs for arbitrary identities, including administrative users. NVD explicitly states that this can result in full server compromise.

For defenders, the real concern is that authentication trust can be subverted without valid credentials. Even if the vulnerable window is limited to onboarding or a no-users state, successful exploitation can turn into persistent control very quickly. An attacker who forges admin tokens may be able to change configuration, access stored data, extract additional secrets, or pivot into systems integrated with the Hoppscotch deployment. If your instance handled sensitive API definitions, environment variables, or internal endpoints, the blast radius may extend beyond the application itself.

CVSS score and severity context

The reported CVSS v3.x score is 10.0, which places this flaw at the maximum critical severity. The score aligns with the described attack path: no authentication required, network reachable, low complexity if the endpoint is exposed in the right deployment state, and severe impact on confidentiality, integrity, and likely availability due to administrative takeover.

The CVSS vector was not available in the NVD summary provided here, so it should not be guessed or reconstructed without a primary source. In the absence of the vector string, defenders should still treat the score as a strong indicator of urgent patch priority. A maximum score combined with direct control over JWT_SECRET is enough to justify immediate change action even before broader exploit telemetry emerges.

Exploitation status

At the time of writing, there is no confirmed evidence in the provided primary-source material that exploitation is happening in the wild. The CVE is not listed in the CISA Known Exploited Vulnerabilities catalog based on the research note, so there is no CISA-backed confirmation of active exploitation. That said, absence from KEV is not evidence of safety; it only means public confirmation was not available from that catalog at this check.

No standalone public proof-of-concept repository was confirmed from the provided sources either. However, defenders should not take comfort from the lack of a widely circulated PoC. The vulnerable endpoint, affected conditions, and impact are described with enough specificity that reproduction is likely straightforward for capable attackers. In other words: exploitation in the wild is not confirmed, a PoC is not confirmed, but the attack path is sufficiently clear that you should assume opportunistic scanning and weaponization are plausible.

How the vulnerability works

The vulnerable endpoint is POST /v1/onboarding/config. In secure NestJS patterns, a validation layer often strips unapproved request fields before business logic sees them. Here, NVD says the global ValidationPipe was configured without whitelist: true, so extra properties were allowed to pass through.

That becomes dangerous because the backend service did not treat those extra fields as invalid junk. Instead, it iterated them as if they were valid InfraConfig entries. Since keys like JWT_SECRET and SESSION_SECRET were considered valid configuration enum values and were not explicitly rejected during validation, an unauthenticated user could supply them during onboarding. The application would then persist attacker-controlled values, effectively handing the attacker control over token signing and session trust.

Technical Notes

A simplified example of the risky request pattern, based on the NVD-described behavior, would look like this:

POST /v1/onboarding/config HTTP/1.1
Host: hoppscotch.example
Content-Type: application/json

{
  "someExpectedField": "value",
  "JWT_SECRET": "attacker-controlled-secret",
  "SESSION_SECRET": "attacker-controlled-session-secret"
}

The implementation issue is conceptually similar to the following NestJS anti-pattern:

app.useGlobalPipes(
  new ValidationPipe({
    // whitelist: true is missing
    transform: true
  })
)

A safer pattern would explicitly strip undeclared properties:

app.useGlobalPipes(
  new ValidationPipe({
    whitelist: true,
    forbidNonWhitelisted: true,
    transform: true
  })
)

What defenders should do next

First, identify every self-hosted Hoppscotch backend instance and confirm its version. Any deployment on 2026.4.1 and earlier should move to 2026.5.0 immediately. Second, determine whether POST /v1/onboarding/config was reachable from untrusted networks during initial provisioning or after rebuilds. Third, rotate JWT_SECRET and SESSION_SECRET if exposure cannot be ruled out.

Finally, improve deployment hygiene around initialization workflows. Onboarding and bootstrap endpoints are often overlooked because they are only expected to exist briefly, but they are high-value targets precisely because they can influence trust and configuration. Restrict those paths to administrator IP ranges during setup, keep staging and fresh-production builds off the public internet until initialized, and ensure input validation protections like whitelist: true are enforced consistently across all externally reachable API paths.