#36912: Q.create() doesn't validate connectors as Q.__init__() does
-------------------------------------+-------------------------------------
Reporter: Jacob Walls | Owner: Sarah
Type: | Boyce
Cleanup/optimization | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: _connector security | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Jacob Walls:
Old description:
> In 98e642c69181c942d60a10ca0085d48c6b3068bb, we mitigated a SQL injection
> vector for user-controlled arguments to `filter()` and friends
> (CVE-2025-64459) by adding validation for the `_connector` argument.
>
> We deliberately avoided adding the same validation to `Q.create()`,
> because `Q.create` is an undocumented internal not to be used with user-
> controlled field names.
>
> The Security Team then received more than one report extrapolating from
> CVE-2025-64459, suggesting that `Q.create` was missing the same
> validation.
>
> Although we don't consider this a security vulnerability, we would be
> interested to evaluate if adding validation to `Q.create` to match
> `Q.__init__` would be cheap enough to implement. A concern is how many
> times `Q.create` might be called in loops. Thus, one part of the solution
> here might be a refactor to reduce the number of times `Q.create` is
> called in loops in Django's code:
>
> in `contrib.contenttypes`:
> https://github.com/django/django/blob/13299a6203f4bc3e5b2552c96a51ff2b15da3c43/django/contrib/contenttypes/fields.py#L682-L695
> in the deletion `Collector`:
> https://github.com/django/django/blob/13299a6203f4bc3e5b2552c96a51ff2b15da3c43/django/db/models/deletion.py#L357-L358
> ...others?
> ----
> Tentatively passing over to Djangonaut Space navigators to see if a good
> fit for anyone (git archaeology, benchmarking, security, ORM internals)
New description:
In 98e642c69181c942d60a10ca0085d48c6b3068bb, we mitigated a SQL injection
vector for user-controlled arguments to `filter()` and friends
(CVE-2025-64459) by adding validation for the `_connector` argument.
We deliberately avoided adding the same validation to `Q.create()`,
because `Q.create` is an undocumented internal not to be used with user-
controlled field names and was created specifically for the purpose of
speed.
The Security Team then received more than one report extrapolating from
CVE-2025-64459, suggesting that `Q.create` was missing the same
validation.
Although we don't consider this a security vulnerability, we would be
interested to evaluate if adding validation to `Q.create` to match
`Q.__init__` would be cheap enough to implement. A concern is how many
times `Q.create` might be called in loops. Thus, one part of the solution
here might be a refactor to reduce the number of times `Q.create` is
called in loops in Django's code:
in `contrib.contenttypes`:
https://github.com/django/django/blob/13299a6203f4bc3e5b2552c96a51ff2b15da3c43/django/contrib/contenttypes/fields.py#L682-L695
in the deletion `Collector`:
https://github.com/django/django/blob/13299a6203f4bc3e5b2552c96a51ff2b15da3c43/django/db/models/deletion.py#L357-L358
...others?
----
Tentatively passing over to Djangonaut Space navigators to see if a good
fit for anyone (git archaeology, benchmarking, security, ORM internals)
--
--
Ticket URL: <https://code.djangoproject.com/ticket/36912#comment:2>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019c4492ec0b-d99ee18a-be93-4a4c-931c-637f4037753d-000000%40eu-central-1.amazonses.com.
