Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HSummary
CVE-2023-27584 is a critical-severity Use of Hard-coded Cryptographic Key (CWE-321) vulnerability in Linuxfoundation Dragonfly. Its CVSS base score is 9.8 (Critical).
Operationally, ranked in the top 2% of CVEs by exploit likelihood; it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to IA-5 (Authenticator Management) and SC-12 (Cryptographic Key Establishment and Management) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
Dragonfly, an open source P2P-based file distribution and image acceleration system hosted by the CNCF, contains a hardcoded JWT secret key value of "Secret Key" used for user authentication. This flaw, tracked as CVE-2023-27584 and assigned CVSS 9.8, corresponds to CWE-321 and CWE-798 and permits complete authentication bypass in all versions prior to the fix.
An unauthenticated remote attacker can exploit the static key to forge valid JWT tokens and perform any action with administrative privileges, including arbitrary operations on the Dragonfly deployment. The vulnerability requires no user interaction or special network positioning beyond network reachability to the affected service.
The official security advisory and release notes for Dragonfly2 version 2.0.9 state that the issue has been resolved in that version and that no workarounds exist, directing all users to upgrade immediately. The associated EPSS score has reached 0.6618 without a documented low-to-high trajectory after disclosure.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2024-2812
Vulnerability Data
Dragonfly is an open source P2P-based file distribution and image acceleration system. It is hosted by the Cloud Native Computing Foundation (CNCF) as an Incubating Level Project. Dragonfly uses JWT to verify user. However, the secret key for JWT, "Secret…
more
Key", is hard coded, which leads to authentication bypass. An attacker can perform any action as a user with admin privileges. This issue has been addressed in release version 2.0.9. All users are advised to upgrade. There are no known workarounds for this vulnerability.
- CWE(s)
Related Threats
Likely ATT&CK TechniquesAI
Techniques this vulnerability likely enables, inferred from its description, weakness type, and attributed-actor tradecraft. Confidence is per-technique.
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
Mitigating Controls (NIST 800-53 r5) AI
Directly requires secure generation, storage, and rotation of authenticators so that a JWT signing key cannot be statically embedded as the literal string "Secret Key".
Mandates proper cryptographic key establishment and management procedures that preclude hard-coded, publicly known secrets used for token signing.
Enforces that every access request must be validated against current authorizations, which fails when an attacker can mint arbitrary admin JWTs with the static key.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure-SDLC activities such as code review and secret scanning directly prevent embedding static keys.
PR.AA-01's credential/key-management processes can reduce the incentive to embed secrets but do not address or detect hard-coded values in source code, so the weakness remains fully possible.
Data-at-rest protection policies require proper key management and therefore discourage hard-coded keys.
Data-in-transit protection similarly depends on non-hard-coded keys for encryption.
Configuration baselines and reviews can prohibit hard-coded keys in deployed artifacts.
PR.AA-02 addresses human identity proofing and per-person credential issuance at enrollment; it has no bearing on whether developers embed static credentials in software.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Education on secure configuration practices discourages technical staff from embedding or relying on hard-coded credentials in systems and applications.
Key-management controls that govern generation, rotation and protection of keys make the use of embedded hard-coded cryptographic keys less likely and easier to detect.
Explicit prohibition of hard-coded passwords and unauthenticated external services stops credentials from being embedded directly in source code.
Contractual requirements for secure coding practices and evidence of testing make it less likely that hard-coded credentials will be introduced or remain undetected in delivered code.
Requiring independent oversight and timely disabling of non-human identities makes it harder for hard-coded or long-lived credentials to remain exploitable.
Mandating immediate replacement of vendor-supplied default credentials eliminates the use of hard-coded or factory passwords that attackers can trivially obtain from documentation or firmware.