Potential log injection in development server (runserver) logging

[Natalia Bidart]

django.core.servers.basehttp.WSGIRequestHandler.log_message() may emit log records that are not properly escaped or sanitized, making it possible for specially crafted requests to inject terminal escape sequences or misleading log content. This only affects the internal development server (runserver command). Per the documentation, this server is not intended for production use and has not been security-audited.

Although this is not considered a vulnerability, a fix for defense-in-depth should be applied, also to avoid confusion and future security reports about the same thing. This fix would be in line to what ​Python does for esacaping.

Thanks to "Kainan Zhang (@4xpl0r3r) from Fortinet" for the report in the security mailing list.

[Natalia Bidart]

I think that an ideal solution would be to use django.utils.log.log_response() to implemenet django.core.servers.basehttp.WSGIRequestHandler.log_message().

[houston0222]

Submitted a PR to address this issue:
​https://github.com/django/django/pull/19592

This patch strips ANSI escape codes from log_message() arguments in the development server to prevent terminal log injection.
It includes a regression test to verify the behavior.

[nessita <124304+nessita@…>]

In 9bb8392:

Fixed #36470 -- Prevented log injection in runserver when handling NOT FOUND.

Migrated WSGIRequestHandler.log_message() to use a more robust
log_message() helper, which was based of log_response() via factoring out
the common bits.

Refs CVE-2025-48432.

Co-authored-by: Natalia <124304+nessita@…>

[Natalia <124304+nessita@…>]

In f5b6ed78:

[6.0.x] Fixed #36470 -- Prevented log injection in runserver when handling NOT FOUND.

Migrated WSGIRequestHandler.log_message() to use a more robust
log_message() helper, which was based of log_response() via factoring out
the common bits.

Refs CVE-2025-48432.

Co-authored-by: Natalia <124304+nessita@…>

Backport of 9bb83925d6c231e964f8b54efbc982fb1333da27 from main.