[FIX] Bump Django 4.2.1 -> 4.2.30 (LTS) to clear SQLi/DoS Dependabot alerts#2040
[FIX] Bump Django 4.2.1 -> 4.2.30 (LTS) to clear SQLi/DoS Dependabot alerts#2040jaseemjaskp wants to merge 1 commit into
Conversation
…alerts Django was hard-pinned at 4.2.1 in backend/pyproject.toml and the root hook-check-django-migrations group. Bumps to the latest 4.2.x LTS patch, which clears the critical SQL-injection alert (_connector kwarg) plus the high-severity ASGI header spoofing, DATA_UPLOAD bypass, column-alias SQLi, path traversal and several DoS advisories. - pyproject.toml / backend/pyproject.toml: django==4.2.1 -> ==4.2.30 - uv.lock, backend/uv.lock: re-locked (django-only diff, no transitive churn) Verified: both locks pass 'uv lock --check'; pinned Django ecosystem (django-tenants 3.5.0, DRF 3.14.0, django-celery-beat 2.5.0) still resolves. Runtime/test verification deferred to CI (local backend sync is blocked by an unrelated django-celery-beat 2.5.0 wheel packaging quirk).
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (2)
Summary by CodeRabbit
WalkthroughDjango version is updated from 4.2.1 to 4.2.30 across two configuration files: the backend project dependencies and the development hook-check-django-migrations dependency group. Both changes coordinate a single upstream version bump. ChangesDjango dependency updates
🎯 1 (Trivial) | ⏱️ ~2 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Unstract test resultsPer-group results
Critical paths
|
|
| Filename | Overview |
|---|---|
| backend/pyproject.toml | Single-line Django pin bump from 4.2.1 → 4.2.30; correct and consistent with the lock file, but lands on an EOL release. |
| pyproject.toml | Django pin updated in the hook-check-django-migrations group to match backend; consistent with root uv.lock. |
| backend/uv.lock | Django entry updated to 4.2.30 with correct sdist/wheel URLs and SHA-256 hashes from PyPI; no transitive dependency churn. |
| uv.lock | Root lock file updated identically to backend/uv.lock; hashes match between both lock files. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart TD
A["Django 4.2.1\n(current pin)"] -->|"This PR"| B["Django 4.2.30\n(4.2 LTS final release)"]
B --> C{"Django 4.2 EOL\nApril 7, 2026"}
C -->|"EOL — no future patches"| D["⚠️ Unpatched CVEs\naccumulate"]
C -->|"Recommended path"| E["Django 5.2 LTS\n(supported → April 2028)"]
E --> F["✅ Continued\nsecurity patches"]
style A fill:#f66,color:#fff
style B fill:#fa0,color:#fff
style C fill:#f90,color:#fff
style D fill:#f66,color:#fff
style E fill:#6b6,color:#fff
style F fill:#6b6,color:#fff
Prompt To Fix All With AI
Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 1
backend/pyproject.toml:21
**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.
Reviews (1): Last reviewed commit: "[FIX] Bump Django 4.2.1 -> 4.2.30 (LTS) ..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| "cron-descriptor==1.4.0", # For cron string description | ||
| "cryptography>=48.0.0", | ||
| "django==4.2.1", | ||
| "django==4.2.30", |
There was a problem hiding this comment.
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!
jaseemjaskp
left a comment
jaseemjaskp
left a comment
There was a problem hiding this comment.
PR Review Toolkit — automated pass.
This PR is a dependency-only change (Django 4.2.1 → 4.2.30 across two pyproject.toml pins + two re-locked uv.lock files). It carries no application code, types, comments, or test changes, so the code-focused toolkit agents (Type Design, Silent Failure Hunter, Comment Analyzer, Code Simplifier, PR Test Analyzer) have no surface to review. I instead ran dependency-bump-specific checks:
✅ Pin consistency — both Django pins in the monorepo (backend/pyproject.toml:21, root pyproject.toml:47) and both lock files (uv.lock, backend/uv.lock) are updated to 4.2.30. No stray django==4.2.1 remains anywhere in the repo.
✅ Lock integrity / no transitive churn — each lock diff is exactly 4 lines (the django package block + its requires-dist specifier); asgiref/sqlparse/tzdata are untouched, confirming the "django-only diff" claim.
✅ LTS-line patch upgrade — stays within 4.2.x, so Django's intra-series backward-compat policy applies; security remediation rationale is sound.
One forward-looking compatibility note left inline. (The Django-4.2-EOL concern is already covered by the existing @greptile-apps P1 comment — not re-raised here.)
| "cron-descriptor==1.4.0", # For cron string description | ||
| "cryptography>=48.0.0", | ||
| "django==4.2.1", | ||
| "django==4.2.30", |
There was a problem hiding this comment.
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.
1 participant
What
Bumps Django 4.2.1 → 4.2.30 (latest 4.2.x LTS patch). Django was hard-pinned at
4.2.1, so this needs apyproject.tomlchange (not just a lock bump) in two places:backend/pyproject.toml:django==4.2.1→django==4.2.30pyproject.toml(hook-check-django-migrationsgroup):django==4.2.1→django==4.2.30backend/uv.lock,uv.lock: re-lockedWhy
Django 4.2.1 carries a long list of open Dependabot alerts. Moving to the latest 4.2 LTS patch clears them in one step:
_connectorkwarg inQuerySet/QDATA_UPLOAD_MAX_MEMORY_SIZEbypass, column-alias SQL injection,HasKeyOracle SQLi, path traversal, plus several DoS advisories (Truncator, intcomma, EmailValidator/URLValidator ReDoS, etc.)How
==4.2.30, thenuv lock --upgrade-package djangoforbackend/and the root workspace.Can this PR break any existing features. If yes, please list possible items. If no, please explain why. (PS: Admins do not merge the PR without this section filled)
Low risk, but this one touches the whole backend so it deserves a full CI/test run before merge.
django-tenants3.5.0,djangorestframework3.14.0,django-celery-beat2.5.0,asgiref3.11.1,sqlparse0.5.5.uv lock --check.Database Migrations
None introduced by this change. (Django's own migrations are unchanged within 4.2.x.)
Env Config
None.
Relevant Docs
Django 4.2 release notes / security releases
Related Issues or PRs
Part of the Dependabot remediation series — follows #2038 (frontend) and #2039 (Python transitive). Authlib + PyMySQL pinned bumps will be a separate PR.
Dependencies Versions
Django 4.2.1 → 4.2.30
Notes on Testing
uv lock --checkonbackend/and root ✓Screenshots
N/A — dependency bump.
Checklist
I have read and understood the Contribution Guidelines.