Django-Vue-Lyadmin EUVD-2026-92777

Exploitation requires that the deployed instance still uses the shipped default/hard-coded SECRET_KEY in backend/application/settings.py, which is used for JWT signing; once the default key is known (it is public in the source and documentation), a remote unauthenticated attacker can forge valid JWTs. The decisive limiting factor is operator configuration: the maintainer documents that developers must manually change the SECRET_KEY before deployment, so any instance that rotated the key to a secret value is NOT vulnerable. There is no user-interaction requirement and no authentication needed against an unremediated instance, but the vulnerability is effectively a default-credential/weak-default problem - real-world exploitability depends entirely on deployments that neglected the documented key-rotation step. Affected scope is Lybbn Django-Vue-Lyadmin up to and including version 3.2.12.

This is a real but context-dependent issue rather than a widespread emergency. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes network-reachable, unauthenticated, low-complexity exploitation, and CWE-321 (use of hard-coded cryptographic key) in a JWT signing context means an attacker who knows the shipped default SECRET_KEY can forge valid JWTs and authenticate as arbitrary users, including admins. Exploit signals are mixed and mostly low-intensity: a public POC exists (GitHub issue #3), but the CVE is NOT in CISA KEV, no EPSS score was provided in the input, and SSVC/automatable data was not supplied - so there is no evidence of active or automated exploitation, only disclosed proof-of-concept. The input CVSS 4.0 rates impact as Low across VC/VI/VA (score 5.5), which under-represents the true consequence of JWT forgery (full authentication bypass); this is a conflict worth noting - the base score looks moderate, but the realistic impact on a vulnerable instance is account/admin takeover. Critically, the maintainer states the default key is documented and operators are instructed to change it before deployment, so the actual risk is gated almost entirely by whether a given deployment left the shipped key unchanged; this is a deployment-hygiene flaw, not a universally exploitable defect. All exploitation signals derive from a single reporter (VulDB); no independent vendor advisory or patch was provided.

An attacker obtains the hard-coded default SECRET_KEY from the project's public source or documentation, then crafts and signs a forged JWT (e.g., for an administrator account) and submits it to a deployed Django-Vue-Lyadmin instance that still uses the default key. The server validates the forged token as authentic, granting the attacker authenticated access without credentials. A public proof-of-concept for this issue has been disclosed (GitHub issue #3).