CVE-2026-117564 in nest-admin
Summary
by MITRE • 10/27/2026
nest-admin before 1.0.1 contains an authentication bypass vulnerability that allows unauthenticated attackers to forge administrator tokens by using a hardcoded JWT_SECRET committed in .env.production. Attackers can sign tokens with the known secret that JwtStrategy and RbacGuard trust, impersonating any user ID or claiming the admin role for full administrative access.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The vulnerability identified in nest-admin versions prior to 1.0.1 represents a critical authentication bypass resulting from improper handling of cryptographic secrets within the application's configuration files. Specifically, the flaw stems from the inclusion of a hardcoded JSON Web Token secret, designated as JWT_SECRET, directly inside the .env.production file which is committed to version control systems. This practice violates fundamental security principles regarding key management and exposes sensitive credentials that are intended for production environments to anyone with access to the source code repository or any backup thereof. The presence of this static secret allows external actors to reverse-engineer the authentication mechanism without needing to exploit complex logic errors in the application's runtime behavior, effectively reducing a high-severity vulnerability to a simple credential theft scenario.
From a technical perspective, the core issue lies in how the NestJS framework utilizes the JwtStrategy and RbacGuard modules for access control. These components rely on the JWT_SECRET to verify the integrity of incoming tokens and to decode claims such as user identity and role assignments. Because the secret is static and publicly available through the repository history or exposed configuration files, an attacker can independently generate valid JSON Web Tokens signed with this known key. By crafting a token that includes specific payload data, specifically setting the role claim to administrator and assigning any desired user identifier, the attacker creates a forged credential that passes all standard verification checks performed by the application's middleware stack. This bypasses both authentication and authorization layers entirely, as the system trusts tokens signed with its own secret without further validation of their origin or legitimacy beyond signature verification.
The operational impact of this vulnerability is severe, granting unauthenticated attackers full administrative access to the nest-admin interface. Once a forged token is presented in an HTTP Authorization header, the application treats the requestor as a legitimate administrator user. This level of access typically encompasses the ability to manage system configurations, view sensitive data stored within the admin database, modify other users' accounts and permissions, and potentially execute administrative functions that could lead to further compromise of the underlying infrastructure depending on how these administrative endpoints are implemented in conjunction with backend services. The attacker can maintain persistent access by refreshing or regenerating tokens as needed, provided they retain knowledge of the secret key which remains static unless manually rotated.
This vulnerability aligns closely with CWE-798: Use of Hard-coded Credentials and CWE-287: Improper Authentication, reflecting a failure to protect sensitive authentication data and a resulting inability to reliably verify user identity. In terms of offensive security frameworks such as MITRE ATT&CK, this scenario maps directly to T1078: Valid Accounts, where adversaries leverage legitimate credentials or forged tokens to gain initial access while evading detection mechanisms that rely on standard login procedures. The exploitation path is straightforward and does not require complex interaction with the application's user interface beyond making authenticated API calls using the crafted token in subsequent requests.
Mitigation strategies must prioritize immediate remediation of the credential exposure followed by robust key management practices. First, the hardcoded JWT_SECRET present in .env.production and its history within version control systems must be rotated immediately to invalidate any existing forged tokens issued with the compromised secret. It is imperative to purge this secret from all repository histories using tools like git-filter-repo or BFG Repo-Cleaner to prevent future exposure through historical commits. Subsequently, the application should be configured to retrieve secrets from secure environment variables managed by a dedicated secrets management service rather than storing them in plaintext configuration files committed to source control. Implementing dynamic secret rotation and ensuring that production environments do not expose internal configuration details are essential steps to restore trust in the authentication mechanism and prevent similar bypasses in future deployments.