What is the CVSS score of CVE-2026-71238?

CVE-2026-71238 has a CVSS 3.1 base score of 9.1 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. EPSS exploitation probability: 0.3%.

Which versions of DjangoCRM are affected by CVE-2026-71238?

DjangoCRM contains a critical vulnerability enabling full account takeover through hardcoded credentials publicly exposed in its GitHub repository, allowing unauthenticated attackers to forge…

How to fix or mitigate CVE-2026-71238?

Within 24 hours: immediately take the GitHub repository private or remove all credentials from version history using tools such as BFG Repo-Cleaner or git-filter-repo, regenerate all Django SECRET_KEY values in production, set DEBUG=False in all production configurations, and invalidate all active user sessions. Within 7 days: conduct a comprehensive credential audit covering database passwords, email service credentials, OAuth tokens, and API keys; issue mandatory password resets for all user accounts with priority on administrative users; analyze authentication and access logs from the past 60 days for indicators of unauthorized account access; and implement automated secrets detection within the CI/CD pipeline to prevent future credential commits. Within 30 days: migrate all credentials to environment-based management eliminating hardcoded secrets, deploy a secrets management platform such as HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault, conduct a complete security review of deployment practices and configuration management, and execute a post-incident review to document lessons learned and prevent recurrence.

DjangoCRM CVE-2026-71238

EUVD-2026-53311 CRITICAL

Use of Hard-coded Credentials (CWE-798)

2026-08-05 309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c

GHSA-qc6p-hvpv-4f8h

Authentication Bypass Python CSRF

9.1

CVSS 3.1 · Vendor: 309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c

Severity by source

Vendor (309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c) PRIMARY

9.1 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

vuln.today AI

9.1 CRITICAL

Public hardcoded key enables unauthenticated remote token forgery (AV:N/AC:L/PR:N/UI:N) yielding full account takeover (C:H/I:H); no availability impact and no cross-system scope change.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c).

CVSS VectorVendor: 309f9ea4-e3e9-4c6c-b79d-e8eb01244f2c

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Generated

Aug 05, 2026 - 11:37 vuln.today

CVE Published

Aug 05, 2026 - 11:16 cve.org

CRITICAL 9.1

DescriptionCVE.org

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. The repository also ships with DEBUG=True as the default, causing error pages to leak database credentials, email credentials, OAuth data, and internal file paths.

Articles & Coverage 1

News Critical Hardcoded SECRET_KEY in DjangoCRM (Python) Enables Full Takeover - CVE-2026-71238 Aug 06, 2026

AnalysisAI

Full account takeover in DjangoCRM stems from a hardcoded Django SECRET_KEY committed in webcrm/settings.py, letting anyone who reads the public GitHub repository forge session cookies (including the superadmin), CSRF tokens, and password reset tokens. The default DEBUG=True setting compounds this by exposing database, email, and OAuth credentials plus internal paths on error pages. No public exploit is identified at time of analysis, but exploitation is trivial and requires no authentication (CVSS 9.1, PR:N).

Technical ContextAI

DjangoCRM is a Python/Django customer-relationship-management application. Django derives cryptographic signatures for session cookies, CSRF tokens, and the PasswordResetTokenGenerator from the project-wide SECRET_KEY; the security model assumes this value is secret and per-deployment. Here the key is CWE-798 (Use of Hard-coded Credentials) - checked directly into version control in webcrm/settings.py instead of being read from an environment variable - so the signing secret is public knowledge for every deployment that did not manually override it. Because the same static key protects authentication (sessions), anti-CSRF, and password-reset flows, one disclosed secret collapses several independent trust boundaries at once. The secondary DEBUG=True default triggers Django's verbose error/traceback pages, which render settings values and can leak database credentials, SMTP credentials, OAuth secrets, and filesystem layout.

RemediationAI

No vendor-released patch version is identified at time of analysis. The primary operator-side fix is to stop trusting the shipped configuration: generate a new random SECRET_KEY, load it (and all credentials) from an environment variable or secrets manager rather than committing it, and set DEBUG=False in production. After rotating the key, invalidate existing sessions and CSRF tokens and force password resets, since previously issued tokens may have been forged; also rotate any database, email, and OAuth credentials that could have been exposed via DEBUG error pages. As a compensating control until configuration is corrected, disabling DEBUG immediately stops the credential/path leakage (side effect: you lose verbose tracebacks for debugging), and restricting network access to the application reduces the unauthenticated attack surface. Consult the project repository at https://github.com/DjangoCRM/django-crm for any updated guidance.