Skip to content

[FIX] Bump Django 4.2.1 -> 4.2.30 (LTS) to clear SQLi/DoS Dependabot alerts #2040

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jaseemjaskp wants to merge 1 commit into
base: main
Choose a base branch
from
+10 −10
Open

[FIX] Bump Django 4.2.1 -> 4.2.30 (LTS) to clear SQLi/DoS Dependabot alerts #2040

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion backend/pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ dependencies = [
"celery[amqp]>=5.3.4", # For Celery
"cron-descriptor==1.4.0", # For cron string description
"cryptography>=48.0.0",
"django==4.2.1",
"django==4.2.30",

@greptile-apps greptile-apps Bot Jun 11, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 security Django 4.2 reached end-of-life on April 7, 2026 — no further security patches will be issued

According to the official Django download page, 4.2.30 is both the latest and the final release of the 4.2 LTS series — extended support ended on April 7, 2026, which is ~2 months before this PR's merge date. Any new vulnerabilities discovered in Django's core from that point onward will not receive backport patches on the 4.2 branch.

The PR clears all known Dependabot alerts in one step, which is valuable. However, landing on an EOL dependency inverts the intent: the project will accumulate unpatched CVEs again as soon as Django discloses its next advisory. The current actively maintained LTS is Django 5.2 (supported until April 2028, latest 5.2.15).

A follow-up PR to upgrade to django==5.2.x would be the complete remediation — the same-minor patch guarantee cited in the PR description doesn't apply to an EOL branch.

Prompt To Fix With AI 
This is a comment left during a code review.
Path: backend/pyproject.toml
Line: 21

Comment:
**Django 4.2 reached end-of-life on April 7, 2026 — no further security patches will be issued**

According to the [official Django download page](https://www.djangoproject.com/download/), `4.2.30` is both the latest *and the final* release of the 4.2 LTS series — extended support ended on April 7, 2026, which is ~2 months before this PR's merge date. Any new vulnerabilities discovered in Django's core from that point onward will not receive backport patches on the 4.2 branch.

The PR clears all *known* Dependabot alerts in one step, which is valuable. However, landing on an EOL dependency inverts the intent: the project will accumulate unpatched CVEs again as soon as Django discloses its next advisory. The current actively maintained LTS is **Django 5.2** (supported until April 2028, latest `5.2.15`).

A follow-up PR to upgrade to `django==5.2.x` would be the complete remediation — the same-minor patch guarantee cited in the PR description doesn't apply to an EOL branch.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Fix in Claude Code

@jaseemjaskp jaseemjaskp Jun 12, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Compatibility note (Low) — multipart file-count limit changed within this jump.

The 4.2.x security series bumped between 4.2.1 and 4.2.30 introduced DATA_UPLOAD_MAX_NUMBER_FILES (default 100), which makes Django raise TooManyFilesSent when a single multipart request carries more than 100 file fields. Django 4.2.1 had no such ceiling.

Unstract has bulk file-upload paths (e.g. Prompt Studio document uploads / ManageDocsModal). If any endpoint accepts >100 files in one multipart/form-data POST, it will start 400-ing after this bump.

Suggested fix / verification: confirm upload endpoints batch ≤100 files per request, or set DATA_UPLOAD_MAX_NUMBER_FILES explicitly in backend/backend/settings/base.py to a value that matches the intended bulk-upload limit. This is the one behavioral change in the 4.2.x range likely to be operationally visible; the rest (ReDoS / SQLi / DoS fixes) are pure hardening with no API change.

"djangorestframework==3.14.0",
"django-cors-headers==4.3.1",
# Pinning django-celery-beat to avoid build issues
Expand Down
8 changes: 4 additions & 4 deletions backend/uv.lock
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion pyproject.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@ test-rig = [
hook-check-django-migrations = [
"celery>=5.3.4",
"cron-descriptor==1.4.0",
"django==4.2.1",
"django==4.2.30",
"djangorestframework==3.14.0",
# Pinning django-celery-beat to avoid build issues
"django-celery-beat==2.5.0",
Expand Down
8 changes: 4 additions & 4 deletions uv.lock
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Loading