CVE-2026-71238: DjangoCRM django-crm · Use of Hard-coded Credentials
Affects DjangoCRM django-crmSource CVE Database V5
Not known to be exploited · CVSS 9.1 Critical.
Data as of 3 Nov 2026, 10:58 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 38% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NExploitation evidence
Disclosed: evidence found.
CVE published 5 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 3 Nov 2026.
What to do
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| DjangoCRMdjango-crm | Affected
| Fixed in– |
AI-suggested
Until an official fix is available, it is recommended to remove the hardcoded SECRET_KEY from the codebase and instead load it securely from environment variables or a secrets management system. Regenerate the SECRET_KEY and invalidate all existing sessions and tokens to prevent misuse.
Description
DjangoCRM ships with its Django SECRET_KEY hardcoded directly in the committed webcrm/settings.py rather than read from an environment variable. Since this key is used for session signing, CSRF token generation, and password reset tokens, anyone who reads the public repository can forge valid session cookies (including for the superadmin account), forge CSRF tokens, and forge password reset tokens, achieving full account takeover.