nest-admin EUVD-2026-110842

Exploitation requires that the deployment run nest-admin before 1.0.1 while still using the committed default secret (JWT_SECRET/REFRESH_TOKEN_SECRET = admin!@#123) from the shipped .env.production or .env.development - the exact value publicly disclosed in the repository. Given that, an unauthenticated network attacker signs a JWT asserting any user ID or the admin role and JwtStrategy/RbacGuard accept it; no user interaction, credentials, or non-default feature toggles are needed, and the API must simply be network-reachable. The principal LIMITING factor is secret reuse: deployments that already replaced the committed secret with their own independent strong value are not exploitable via the known key. The vendor states that environments which ever ran with the historical default must, after upgrading, rotate both JWT_SECRET and REFRESH_TOKEN_SECRET and reissue all login sessions - updating the code alone does not revoke tokens already forgeable with the old secret.

All severity signals point the same direction: the CVSS 4.0 base vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H, 9.3) describes trivial remote exploitation with full confidentiality, integrity and availability impact, and VulnCheck assigns an 'act_now' priority. The mechanism is confirmed by source evidence - the pre-fix .env.production and .env.development committed JWT_SECRET = admin!@#123 (and an identical REFRESH_TOKEN_SECRET), a textbook CWE-321 hardcoded-key flaw, and JwtStrategy/RbacGuard trust whatever that secret signs. Because the secret is published in the repository's git history, any attacker can forge a valid admin token offline, so the practical barrier to exploitation is effectively zero where the default secret is still in use. Counter-signals to weigh: no EPSS score was provided, this is NOT in CISA KEV, and the input does not flag confirmed working exploit code - so there is no evidence of active, widespread exploitation yet. The tension is that extreme ease-of-exploitation collides with a low real-world deployment footprint: nest-admin is an open-source NestJS admin boilerplate, not mainstream enterprise software, which likely explains any absent EPSS/KEV signal rather than low risk per instance. Net: for any exposed deployment still running the committed secret this is a genuine, drop-everything-and-patch issue; across the internet the aggregate exposure is limited by the product's niche footprint.

An attacker finds an internet-exposed nest-admin instance (version before 1.0.1) and retrieves the publicly committed JWT_SECRET 'admin!@#123' from the project's git history. Using that known secret they mint a JWT asserting the admin role (or any user ID), present it to the API, and JwtStrategy/RbacGuard accept it - granting full administrative access with no credentials, no user interaction, and no need for any exploit tooling beyond a standard JWT signing library. No confirmed working exploit package is cited in the input, but the disclosed secret makes token forgery a one-line operation.