= Security Team =

This page is used by the security team to help with process of analyzing and replying to security reports.

== Canned Responses == 

=== Report acknowledgement === 

Hello,

Thank you for your report. We will investigate and get back to you soon. In the meantime, please keep this information confidential.

If you haven't already, please review how the Django security team evaluates reports: https://docs.djangoproject.com/en/dev/internals/security/.

Note that it can take several weeks before we have completed our analysis. There is no need to chase the security team unless you discover new, relevant information. All reports aim to be resolved within the industry-standard 90 days.

Kind regards, the Django Security Team.

=== DMARC/SPF/Email Spoofing ===

Hello,

Thank you for your report. The current DMARC and SPF settings are intentional, and we do not consider this a vulnerability.

For more information on how the Django security team evaluates reports, please see: https://docs.djangoproject.com/en/dev/internals/security/.

Kind regards, the Django Security Team.

=== Report about djangoproject.com ===

Hello,

Thank you for your report. This mailing list is intended for reporting security issues related to the Django web framework, rather than its website, so you can consider this issue closed.

For more information on how the Django security team evaluates reports, please see: https://docs.djangoproject.com/en/dev/internals/security/.

Kind regards, the Django Security Team.

=== Asked for support instead ===

Hello,

This mailing list is intended for reporting security issues in the Django web framework, not for support related to using or contributing to Django.

For assistance, please refer to the Getting Help page (https://docs.djangoproject.com/en/dev/faq/help/), where you'll find resources and communities ready to support you. Following these guidelines will also help you structure your question in a way that makes it easier for others to assist.

Thanks for your understanding!

Kind regards, the Django Security Team.

=== Unsanitized user input ===

After review, we've determined that the reported issue only affects workflows that process user input without sanitization. As documented at [0]:

"Reports based on a failure to sanitize user input are not valid security vulnerabilities. It is the developer’s responsibility to properly handle user input."

[0] https://docs.djangoproject.com/en/stable/internals/security/#user-input-must-be-sanitized

Because of this, the behavior you reported is not considered a security issue within the Django project.

Thanks for taking the time to submit it through the appropriate channel.

Kind regards, the Django Security Team.

=== Private API ===

After review, we've determined that the reported issue only affects direct usage of private, undocumented functionality. As documented at [0]:

> Django contains many private and undocumented functions that are not part of its public API. If a vulnerability depends on directly calling these internal functions in an unsafe way, it will not be considered a valid security issue.

[0] https://docs.djangoproject.com/en/stable/internals/security/#code-under-test-must-feasibly-exist-in-a-django-project

Because of this, the behavior you reported is not considered a security issue within the Django project.

Thanks for taking the time to submit it through the appropriate channel.

Kind regards, the Django Security Team.

=== Security issue in the development server (runserver) ===

After review, we've determined that the reported issue only affects the development server used by runserver. As documented at [0]:

"This lightweight development server has not gone through security audits or performance tests, hence is unsuitable for production. Making this server able to handle a production environment is outside the scope of Django."

Also, our security policy at [1] states that:

"[...] This means the following scenarios do not require a security release: Exploits that only affect local development, for example when using runserver."

Because of this, the behavior you reported is not considered a security issue within the Django project. That said, we appreciate your diligence and have opened a public ticket to track a regular fix for this case, with appropriate credit for your report.

Thanks for taking the time to submit it through the appropriate channel.

Kind regards, the Django Security Team.

[0] https://docs.djangoproject.com/en/stable/ref/django-admin/#django-admin-runserver
[1] https://docs.djangoproject.com/en/stable/internals/security/#how-does-django-evaluate-a-report

=== SQL Injection via extra, raw or RawSQL ===

Hello!

Thank you for taking the time to submit your discoveries responsibly.

After reviewing your report, we have concluded that it does not constitute a security issue. The behavior presented relies on the use of `QuerySet.extra`, `QuerySet.raw`, or `RawSQL` expressions, which are explicitly designed to execute arbitrary SQL. These APIs are documented to require that user-controllable input be passed via `params` as shown below:

* https://docs.djangoproject.com/en/stable/ref/models/querysets/#django.db.models.query.QuerySet.extra
* https://docs.djangoproject.com/en/stable/ref/models/querysets/#raw
* https://docs.djangoproject.com/en/stable/ref/models/expressions/#raw-sql-expressions

Recently addressed issues such as CVE-2025-59681 differ from your report since that class of issue concerns identifier escaping, whereas your report concerns value escaping. For raw SQL query APIs, responsibility for distinguishing between code (SQL) and data (user input) rests with the developer.

For further clarification, please see our documentation on performing raw SQL queries: https://docs.djangoproject.com/en/stable/topics/db/sql/#performing-raw-sql-queries

Kind regards, the Django Security Team.

=== Maximum password validator (lack of) ===

Thank you for your report. We reviewed the issue and do not consider it a security vulnerability.

While it is true that extremely long passwords could, in theory, increase the cost of password hashing, Django applies a request body size limit [0], which defaults to 2.5 MB. In practice, this means passwords cannot exceed roughly 2.5 million characters.Django's built-in password hashers handle inputs of this size efficiently. On a regular desktop machine, hashing a 2.5 MB password takes on the order of a third of a second.

For example, running the following plain Python script:
{{{#!python
import timeit
from django.contrib.auth.hashers import get_hasher

hasher = get_hasher()
salt = hasher.salt()
password = "x" * 2_621_440  # ~2.5 MB
n = 5  # number of runs
total_seconds = timeit.timeit(lambda: hasher.encode(password, salt), number=n)avg_ms = (total_seconds / n) * 1000

print(f"Average time: {avg_ms:.2f} ms over {n} runs")
}}}
Produces output such as: `Average time: 281.13 ms over 5 runs`

Given these limits and performance characteristics, and noting that it is generally good practice to permit long and secure passwords, we do not consider any change necessary in Django itself.

Kind regards, The Django Security Team.

[0] https://docs.djangoproject.com/en/stable/ref/settings/#data-upload-max-memory-size

=== HTTP Content-Type Header parsing (parse_header_parameters) ===

Thank you for your report. This problem has already been reported a few times in the past. The security team does not consider this to be a vulnerability, and work towards improving the handling of strings containing a large number of separators by `parse_header_parameters` has been happening in public[0]. We invite you to join this effort.

Kind regards, the Django Security Team.

[0] https://code.djangoproject.com/ticket/35440

=== Confusion with YANGO (usually sent in Spanish) ===

Hola!

Lamentamos informarte que esta dirección de correo no tiene relación alguna con YANGO.
Esta casilla recibe reportes de seguridad relacionados al software Django (https://www.djangoproject.com/), y no tenemos ninguna relación con el servicio de transporte. Es decir, esta es una dirección equivocada para hacer reclamos de YANGO.
No conocemos ni tenemos detalles de contacto de YANGO.

Saludos.

=== Unauthenticated cache purge ===

(This is a known behavior and we've previously disregarded such reports, needs a skeleton response.)

== Bug Bounty program scope ==

Hello,

Thank you for your email. Django has a bug bounty program, its details can be read here: https://hackerone.com/django, but please note that the bounty only applies to security issues found in the Django web framework, rather than to the djangoproject.com or any other website built with Django.

Kind regards, the Django Security Team.

== Confirmation of vulnerability ==

Hello {{ name }},

Thank you for your report and patience. We have confirmed the vulnerability, which has been assigned {{ cve_number }}.

I have attached our proposed mitigation solution. Could you please test the patch to ensure it reliably fixes the issue?

We plan to mention the discoverer of the vulnerability in a blog post. Is "{{ name }}" okay, or would you prefer to be credited differently?

The Django release with this fix is currently planned for {{ planned_release_date }}. Please keep this private until after the updated versions are published.

Thank you again!