Description

A vulnerability has been found in Lybbn Django-Vue-Lyadmin up to 3.2.12. The impacted element is an unknown function of the file backend/application/settings.py of the component JWT Signing. The manipulation of the argument SECRET_KEY leads to use of hard-coded cryptographic key . Remote exploitation of the attack is possible. The exploit has been disclosed to the public and may be used. The project maintainer explains: "The issue with this key is described in the documentation. Developers need to manually change their keys before deployment."

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.3",
  "pubDate": "2026-10-05T20:17:10.827Z",
  "pubdate": "2026-10-05T20:17:10.827Z",
  "executiveSummary": "Lybbn Django-Vue-Lyadmin versions up to 3.2.12 contain a critical security vulnerability involving the use of a hard-coded cryptographic key within the JWT signing mechanism.\nThe vulnerability is categorized as a failure to protect cryptographic secrets, which directly undermines the integrity and confidentiality of the application's authentication system.\nBy leveraging the known, static SECRET_KEY defined in backend/application/settings.py, an unauthenticated remote attacker can forge valid JSON Web Tokens (JWT).\nThis allows for unauthorized account impersonation, privilege escalation, and potential full system compromise, as the integrity of the session management layer is rendered void.\nThe risk is categorized as high due to the ease of exploitation, the public availability of the exploit, and the requirement for manual intervention by the administrator to remediate the static secret configuration.",
  "technicalDetails": "The vulnerability resides within the backend/application/settings.py file of the Lybbn Django-Vue-Lyadmin component. The root cause is the implementation of a static, hard-coded SECRET_KEY utilized by the Django framework's authentication and security middleware to sign and verify JSON Web Tokens (JWT).\nIn a secure deployment, the SECRET_KEY must be a cryptographically strong, randomly generated string unique to the environment. However, in this product, the key is bundled directly within the source code. This practice results in predictable cryptographic signatures, as the key value is discoverable by any individual with access to the codebase or via publicly available repository information.\nThe exploitation flow begins with the attacker identifying the hard-coded string via source code analysis. Once the key is obtained, the attacker can manipulate the JWT authentication process. By utilizing a common JWT library or tool, the attacker constructs a forged payload where the header and claims (e.g., user_id or roles) are modified. The attacker then signs this forged token using the compromised SECRET_KEY.\nBecause the application verifies incoming tokens using the same hard-coded key, it will accept the forged token as legitimate. This bypasses the standard authentication handshake entirely. An attacker can craft a token claiming the identity of an administrative account, gaining full access to the application’s backend functions.\nThis vulnerability is remotely exploitable and does not require prior authentication. The impact is significant, as it effectively nullifies the authentication boundary. Post-exploitation, an attacker can perform any action authorized to the impersonated user, including data exfiltration, modification of database records, or further execution of arbitrary code if administrative privileges are successfully forged. The vulnerability persists across all versions up to and including 3.2.12, requiring manual remediation by the system administrator to override the default settings provided in the distribution."
}