CVE-2026-42196: django-s3file Path Traversal Vulnerability

CVE-2026-42196 Overview

CVE-2026-42196 is a relative path traversal vulnerability in django-s3file, a lightweight file upload input for Django and Amazon S3. Versions prior to 7.0.2 ship a vulnerable S3FileMiddleware that fails to validate upload paths supplied in requests. Attackers can craft modified requests to escape pre-signed upload locations and force the Django application to load arbitrary S3 objects into request.FILES. Depending on how the application processes uploaded files, this leads to confidentiality and integrity impacts on data stored in the connected S3 bucket. The issue is tracked under [CWE-22] and is fixed in version 7.0.2.

Critical Impact

Unauthenticated network attackers can manipulate file upload requests to load arbitrary S3 objects into Django views, exposing or corrupting bucket contents.

Affected Products

• django-s3file versions prior to 7.0.2
• Django applications using S3FileMiddleware with Amazon S3 backends
• Deployments relying on pre-signed S3 upload URLs through django-s3file

Discovery Timeline

• 2026-05-12 - CVE-2026-42196 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-42196

Vulnerability Analysis

The django-s3file package implements direct-to-S3 uploads by issuing pre-signed POST URLs to the browser. After the client uploads the file directly to S3, the browser sends a follow-up request to the Django backend referencing the S3 object key. The S3FileMiddleware then fetches the referenced object and injects it into request.FILES so the Django view can process it as if it were a standard multipart upload.

The middleware trusts the object key supplied by the client without enforcing that the key remains within the pre-signed upload prefix. An attacker can submit a relative path that traverses outside the intended location, causing the middleware to load a different S3 object into request.FILES. The application then processes attacker-chosen content as a legitimate upload.

Root Cause

The root cause is insufficient path validation in S3FileMiddleware when resolving client-supplied object keys against the pre-signed upload location. Relative path segments are not normalized or constrained, allowing escape from the upload prefix and arbitrary object selection within the bucket.

Attack Vector

Exploitation requires network access to a Django endpoint that uses S3FileMiddleware. No authentication or user interaction is required when the upload form itself is reachable anonymously. The attacker initiates a normal upload flow, then modifies the file reference returned to the backend with traversal sequences pointing at sensitive bucket keys. The view receives the attacker-selected object as request.FILES, which may be persisted, served back, or used to overwrite trusted records. See the GitHub Security Advisory GHSA-67qg-7284-2277 for technical details.

Detection Methods for CVE-2026-42196

Indicators of Compromise

• Upload requests containing ../ sequences, URL-encoded traversal patterns, or absolute keys in fields consumed by S3FileMiddleware.
• S3 access logs showing GetObject calls from the Django application role against keys outside configured pre-signed upload prefixes.
• request.FILES entries in application logs that reference object keys inconsistent with the user's session or form context.

Detection Strategies

• Inspect Django access logs and WAF telemetry for path traversal patterns on endpoints that route through S3FileMiddleware.
• Correlate S3 server access logs with application upload events to flag object reads outside expected upload directories.
• Audit installed Python dependencies and identify hosts running django-s3file below 7.0.2.

Monitoring Recommendations

• Enable S3 bucket access logging and CloudTrail data events for the buckets backing django-s3file uploads.
• Alert on Django application role activity that reads keys outside the documented upload prefix.
• Track deployments of vulnerable django-s3file versions in software bill of materials inventories.

How to Mitigate CVE-2026-42196

Immediate Actions Required

• Upgrade django-s3file to version 7.0.2 or later across all Django services.
• Review S3 access logs since deployment of vulnerable versions for unexpected GetObject calls by the Django application role.
• Restrict the IAM policy bound to the Django application so it can only read and write keys under the intended upload prefix.

Patch Information

The maintainers fixed this issue in django-s3file7.0.2. The patch enforces that resolved S3 object keys remain within the pre-signed upload location before injecting them into request.FILES. Refer to the GitHub Security Advisory GHSA-67qg-7284-2277 for advisory details and upgrade instructions.

Workarounds

• If upgrading immediately is not possible, tighten the S3 bucket policy and IAM role to limit reads strictly to the upload prefix.
• Place a WAF rule in front of upload endpoints to reject requests containing ../, ..\, or URL-encoded traversal sequences in form fields.
• Validate within Django views that any key returned by S3FileMiddleware matches the expected per-user or per-session prefix before processing the file.

# Configuration example: upgrade django-s3file to the fixed release
pip install --upgrade 'django-s3file>=7.0.2'
pip show django-s3file | grep -i version