Shipped administrative credentials in Juspay Hyperswitch
Hyperswitch ships a working admin key and JWT secret in its default configuration — and the startup validator refuses only blank values, never these published defaults. Any instance left on shipped config runs with credentials printed in the public source.
A shipped configuration boots into full administrative access over the network
The credentials were never hidden. The validator just never looked for them.
Hyperswitch is open-source payment infrastructure that operators run on their own servers. The shipped example configs contain a working admin API key — the literal string test_admin — and a JWT secret, the literal word secret.
The default that was never rejected
Attacker → validator → full admin
- Identifier
- CVE requestedpending MITRE assignment
- Severity
- 9.8 CriticalCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Weakness
- Hard-coded CredentialsCWE-798
- Affected
- Hyperswitchthrough v2026.07.08.1 · commit 51a6960 (2026-07-08)
- Vendor
- Juspay Technologiesnotified security@juspay.in
- Vector
- Networkself-hosted, default config
- Researcher
- Drew Morana@dmorana · Whitenbaker
- Status
- Disclosed90-day window elapsed
One published string is the whole exploit
The startup validator in crates/router/src/configs/validations.rs applies is_default_or_empty() to the credential fields. Because they are typed Secret<String>, the “default” compared against is the empty string — so a blank credential is rejected but the published default is accepted.
An instance deployed on shipped configuration boots and runs with credentials printed, in plain text, in the public repository.
The credentials were never hidden. The validator just never looked for them.
Every instance is served the same shipped config — and the check refuses only the empty string, not the default that follows it.
No boundary between reaching the network and administering the deployment
The three scenarios were confirmed against the current release. Each grants control that should require issued administrative credentials. The same key path also reads stored customer PII and creates payments.
The pattern is recognized and CVE-worthy. Apache APISIX was assigned CVE-2020-13945 for the identical class — a shipped default admin token accepted by a self-hosted service — independent of whether an operator “should have” rotated it.
POST /organization api-key: test_admin → 200 OK org created under attacker control
POST /api_keys/{merchant_id} api-key: test_admin → 200 OK live API key issued
DELETE /accounts/{merchant_id} api-key: test_admin → 200 OK merchant permanently deleted
Full administrative compromise of a payment system
An attacker who can reach a default-configuration instance over the network gains administrative control: creating organizations and merchants, minting API keys, exfiltrating customer PII, creating payments, and permanently deleting merchant accounts.
Exploitation requires no discovery step and no privilege — only network reachability to an instance deployed on shipped configuration.
Affected operators requiring remediation guidance should contact Whitenbaker Security Research.
Initial disclosure. Reported to Juspay at security@juspay.in under coordinated disclosure, opening a 90-day window.
Window elapsed. The 90-day deadline was reached with no fixed release published.
Re-confirmed on current release. Defaults and validator behavior verified at v2026.07.08.1, commit 51a6960489caa3bb246e547b4b3cc11bd890a190.
CVE requested. Filed with MITRE with version and commit identifiers; this advisory published as the public reference.
Whitenbaker
Adversarial security research — silent-patch detection, vulnerability disclosure, and the gap between what vendors ship and what they tell you.
Drew Morana · @dmoranaPublished for coordinated disclosure and defensive purposes. Findings confirmed against the referenced public release. © 2026 Whitenbaker. All rights reserved.