CWE-321: Use of Hard-coded Cryptographic Key

VariantLikelihood of exploit: High

The product uses a hard-coded, unchangeable cryptographic key.

Consequences

Access Control: Bypass Protection Mechanism, Gain Privileges or Assume Identity, Read Application Data

How to prevent it

Architecture and Design: Prevention schemes mirror that of hard-coded password storage.

Recent advisories

GHSA-3qg8-5g3r-79v5 — praisonai-platform: JWT signing key defaults to hardcoded "dev-secret-change-me", allowing token forgery for any user when PLATFORM_ENV is unset
GHSA-6c8g-9hfh-pq5h — HAXcms: Private Key Disclosure via Broken HMAC Implementation
GHSA-cc4f-hjpj-g9p8 — Flowise: Weak Default JWT Secrets
GHSA-wqxq-w68r-wg85 — Apache OpenMeetings Uses Hard-coded Cryptographic Key
GHSA-32cc-x95p-fxcg — FUXA Unauthenticated Remote Code Execution via Hardcoded JWT Secret in Default Configuration
CVE-2025-30406 — Gladinet CentreStack through 16.1.10296.56315 (fixed in 16.4.10315.56368) has a deserialization vulnerability due to the CentreStack portal's hardcoded…
GHSA-mr45-rx8q-wcm9 — xkeys seal encryption used fixed key for all encryption
GHSA-p836-389h-j692 — Improper Access Control in Apache Shiro
GHSA-6cr4-7c7p-p3xv — Use of Hard-coded Cryptographic Key in Apache Tomcat

All advisories for CWE-321

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor