mediumCVE-2026-53878

CVE-2026-53878 Django vulnerability

An issue was discovered in Django 6.0 before 6.0.7 and 5.2 before 5.2.16. `DomainNameValidator` does not prohibit newlines in domain names (unless used via a form field, since `CharField` strips newlines). If an application uses values with newlines in an HTTP response, header injection can occur. Django itself is unaffected because `HttpResponse` prohibits newlines in HTTP headers. Earlier, unsupported Django series (such as 5.0.x, 4.1.x, and 3.2.x) were not evaluated and may also be affected. Django would like to thank Bence Nagy for reporting this issue.

ProductDjango
CVSS5.3
EPSS0.00217
UpdatedJuly 12, 2026

Quick answer

Django should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.

Who is affected

Affected versions

  • >=6.0 <6.0.7
  • >=5.2 <5.2.16

Fixed versions

  • 6.0.7
  • 5.2.16

How to fix it

CVE-2026-53878 affects Django applications where DomainNameValidator accepted newline characters, which can lead to header injection if applications place validated domain values into HTTP responses outside Django form handling. Prioritize public applications, APIs, GeoDjango workloads, and pages that handle sensitive cached responses or user-supplied validation output depending on the issue. Django fixed the supported branches in versions 6.0.7 and 5.2.16. Unsupported Django branches were not fully evaluated, so upgrade to a supported patched release rather than relying on older series.

  1. Inventory all Django applications, containers, virtual environments, requirements files, lockfiles, and base images across production, staging, and background workers.
  2. Identify Django 6.0 before 6.0.7 and Django 5.2 before 5.2.16, and treat unsupported branches as requiring migration to a supported patched release.
  3. Upgrade Django to 6.0.7 and 5.2.16, or a later supported release, then rebuild and redeploy all application images and worker environments.
  4. Review application code paths that use DomainNameValidator, GeoDjango GDALRaster, shared cache middleware, cache_page, and sensitive cookie-varying responses as relevant to this CVE.
  5. Add focused regression tests for the affected workflow before and after patching, including malformed inputs and authorization-sensitive responses.
  6. Review access logs, application errors, cache entries, and worker crash reports for suspicious input, private-data exposure, or raster-processing failures.
  7. If private data or memory disclosure is suspected, purge shared caches, rotate affected sessions or credentials, preserve logs, and notify owners according to incident policy.

Scan now. Google sign-in is only needed to unlock fix guidance.

Verify the fix

  • Confirm package metadata, lockfiles, containers, and runtime checks report Django 6.0.7 and 5.2.16, or a later supported release.
  • Confirm newline-containing domain values are rejected by DomainNameValidator and cannot reach response headers.
  • Run application test suites and focused security regression tests for affected validators, GIS processing, caching, and response-header handling.
  • Rerun dependency, container, and Fixnx scans where relevant and confirm the Django CVE is no longer reported.
  • Document patched versions, rebuilt artifacts, test results, cache purge status, and any residual migration work.

Related categories

Trusted references

FAQ

What is affected by CVE-2026-53878?

Django versions listed as affected should be reviewed: >=6.0 <6.0.7, >=5.2 <5.2.16.

What should I fix first?

Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.

How do I confirm the fix worked?

Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.

How are Fixnx security risk categories chosen?

Fixnx keeps one canonical risk page and assigns only broad, relevant categories such as ecosystem, technology area, or vulnerability class.