Max URL length of 2048 is too conservative for redirect targets

[Jacob Walls]

Since 4.2.3 (2023), Django has been enforcing a limit of 2048 characters in the URL and email validators to prevent a REDoS vector (CVE-2023-36053).

In 5.1.8 and 5.0.14 (April 2025), Django applied this limit in more places to prevent a DoS vector on Windows (CVE-2025-27556):

• LoginView
• LogoutView
• set_language()

In 5.2.8, 5.1.4, and 4.2.26 (November 2025) this same limit was applied in an additional case (to prevent an almost identical DoS vector, CVE-2025-64458):

• HttpResponseRedirect
• HttpResponsePermanentRedirect
• redirect()

We've seen multiple reports that 2048 characters is too strict for redirects involving third-party services like S3:

• ​authentik
• ​forum [1]
• ​forum [2]

The fact that we're catching 4.2 LTS users for the first time is relevant.

---

nginx allows about 8k characters ​source
apache allows about half that ​source

To my knowledge, 2048 was chosen simply because of the precedent in 4.2.3 for the URLValidator case (thereby reusing a single constant).

I'm not proposing to do anything about the URLValidator case. But for the Windows vulnerabilities, having to do with LoginView and redirect, we could have relaxed the limit to around nginx's 8K limit and still mitigated them.

That's essentially what authentik did when monkey-patching this constant. Users shouldn't have to do that (it degrades the validation for URLField).

---

I'm proposing we relax 2048 to 8192 (around the nginx limit) for the two vulnerabilities we patched in 2025 (in LoginView, redirect() and friends), i.e. have a second constant for those. I'm not proposing to expose this as a setting. I'm proposing we ship it with our next regularly scheduled patch release.

[Natalia Bidart]

Thank you!

[Mariusz Felisiak]

I'm not sure why we want to consider this as a release blocker, we've discussed and agreed on this limit within the security team. Moreover, users can adjust the current limit themselves. As far as I'm aware, this is not a bug but a cleanup, even then, I'm not convinced that we should change it (even in the current main branch).

[Jacob Walls]

Thanks Mariusz. My position is that we got the limit wrong.

we've discussed and agreed on this limit within the security team

I think this overstates the extent to which it was discussed.

Moreover, users can adjust the current limit themselves.

Do you not find the arguments convincing that this is a poor practice, not composable for reusable apps, and degrades URLField validation?

[nessita <124304+nessita@…>]

In a8cf8c2:

Fixed #36743 -- Increased URL max length enforced in HttpResponseRedirectBase.

Refs CVE-2025-64458.

The previous limit of 2048 characters reused the URLValidator constant
and proved too restrictive for legitimate redirects to some third-party
services. This change introduces a separate MAX_URL_REDIRECT_LENGTH
constant (defaulting to 16384) and uses it in HttpResponseRedirectBase.

Thanks Jacob Walls for report and review.

[Natalia <124304+nessita@…>]

In ce7d65fc:

[6.0.x] Fixed #36743 -- Increased URL max length enforced in HttpResponseRedirectBase.

Refs CVE-2025-64458.

The previous limit of 2048 characters reused the URLValidator constant
and proved too restrictive for legitimate redirects to some third-party
services. This change introduces a separate MAX_URL_REDIRECT_LENGTH
constant (defaulting to 16384) and uses it in HttpResponseRedirectBase.

Thanks Jacob Walls for report and review.

Backport of a8cf8c292cfee98fe6cc873ca5221935f1d02271 from main.

[Natalia <124304+nessita@…>]

In 0ae15bb:

[5.2.x] Fixed #36743 -- Increased URL max length enforced in HttpResponseRedirectBase.

Refs CVE-2025-64458.

The previous limit of 2048 characters reused the URLValidator constant
and proved too restrictive for legitimate redirects to some third-party
services. This change introduces a separate MAX_URL_REDIRECT_LENGTH
constant (defaulting to 16384) and uses it in HttpResponseRedirectBase.

Thanks Jacob Walls for report and review.

Backport of a8cf8c292cfee98fe6cc873ca5221935f1d02271 from main.

[Natalia <124304+nessita@…>]

In f354296:

[5.1.x] Fixed #36743 -- Increased URL max length enforced in HttpResponseRedirectBase.

Refs CVE-2025-64458.

The previous limit of 2048 characters reused the URLValidator constant
and proved too restrictive for legitimate redirects to some third-party
services. This change introduces a separate MAX_URL_REDIRECT_LENGTH
constant (defaulting to 16384) and uses it in HttpResponseRedirectBase.

Thanks Jacob Walls for report and review.

Backport of a8cf8c292cfee98fe6cc873ca5221935f1d02271 from main.

[Natalia <124304+nessita@…>]

In e697349:

[4.2.x] Fixed #36743 -- Increased URL max length enforced in HttpResponseRedirectBase.

Refs CVE-2025-64458.

The previous limit of 2048 characters reused the URLValidator constant
and proved too restrictive for legitimate redirects to some third-party
services. This change introduces a separate MAX_URL_REDIRECT_LENGTH
constant (defaulting to 16384) and uses it in HttpResponseRedirectBase.

Thanks Jacob Walls for report and review.

Backport of a8cf8c292cfee98fe6cc873ca5221935f1d02271 from main.

[nessita <124304+nessita@…>]

In 18b13cf:

Refs #36743 -- Added missing release notes for 5.1.15 and 4.2.27.

The fix landed in a8cf8c292cfee98fe6cc873ca5221935f1d02271 will be
backported to 5.1 and 4.2 since the 2048 limit was rolled out as part of
the security release for CVE-2025-64458.

[Natalia <124304+nessita@…>]

In 1f34900:

[6.0.x] Refs #36743 -- Added missing release notes for 5.1.15 and 4.2.27.

The fix landed in a8cf8c292cfee98fe6cc873ca5221935f1d02271 will be
backported to 5.1 and 4.2 since the 2048 limit was rolled out as part of
the security release for CVE-2025-64458.

Backport of 18b13cf6c48ff0a20b2a74d3b90d1fc1602608e4 from main.

[Natalia <124304+nessita@…>]

In 2171933:

[5.2.x] Refs #36743 -- Added missing release notes for 5.1.15 and 4.2.27.

The fix landed in a8cf8c292cfee98fe6cc873ca5221935f1d02271 will be
backported to 5.1 and 4.2 since the 2048 limit was rolled out as part of
the security release for CVE-2025-64458.

Backport of 18b13cf6c48ff0a20b2a74d3b90d1fc1602608e4 from main.

[Natalia <124304+nessita@…>]

In ca4251d0:

[5.1.x] Refs #36743 -- Added missing release notes for 5.1.15 and 4.2.27.

The fix landed in a8cf8c292cfee98fe6cc873ca5221935f1d02271 will be
backported to 5.1 and 4.2 since the 2048 limit was rolled out as part of
the security release for CVE-2025-64458.

Backport of 18b13cf6c48ff0a20b2a74d3b90d1fc1602608e4 from main.

[Natalia <124304+nessita@…>]

In 0e85bdb:

[4.2.x] Refs #36743 -- Added missing release notes for 5.1.15 and 4.2.27.

The fix landed in a8cf8c292cfee98fe6cc873ca5221935f1d02271 will be
backported to 5.1 and 4.2 since the 2048 limit was rolled out as part of
the security release for CVE-2025-64458.

Backport of 18b13cf6c48ff0a20b2a74d3b90d1fc1602608e4 from main.

[minusf]

Tangentially the docstring for DisallowedRedirect is now out of date:

class DisallowedRedirect(SuspiciousOperation):
    """Redirect to scheme not in allowed list"""

[nessita <124304+nessita@…>]

In ce36c35:

Refs #36743 -- Corrected docstring for DisallowedRedirect.

[Natalia <124304+nessita@…>]

In 2e3953f:

[6.0.x] Refs #36743 -- Corrected docstring for DisallowedRedirect.

Backport of ce36c35e76f82f76cdfa5777456e794d481e5afc from main.

[Natalia <124304+nessita@…>]

In e2ddec4:

[5.2.x] Refs #36743 -- Corrected docstring for DisallowedRedirect.

Backport of ce36c35e76f82f76cdfa5777456e794d481e5afc from main.