Live › vulnerability › CVE-2026-42196
Go to dashboarddjango-s3file's S3FileMiddleware accepts a modified upload request whose path escapes the pre-signed upload location. The Django application then loads files from other locations on disk into request.FILES, which can expose or alter data depending on how the app handles uploads.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-27 16:25 UTC, 0h before NVD. All times on this page are UTC.
Django projects that use django-s3file with S3FileMiddleware to handle direct-to-S3 uploads are exposed, since the middleware is what processes the forged request paths. Projects that do not install django-s3file or do not enable its middleware are not affected by this flaw. The sources do not describe a specific deployment configuration beyond that.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| django-s3file | pypi | <= 7.0.1 | 7.0.2 |
pip show django-s3file and check whether the version is 7.0.1 or lower.S3FileMiddleware in MIDDLEWARE settings.request.FILES for uploaded files that are then stored or processed.django-s3file to 7.0.2 or later.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
django-s3file is a lightweight file upload input for Django and Amazon S3. Prior to 7.0.2, S3FileMiddleware is vulnerable to relative path traversal attacks, where an attacker can use a modified request to escape pre-signed upload locations and have the Django application load files from random locations into request.FILES. Depending on how files are handled, this may lead to confidentiality and integrity issues. This vulnerability is fixed in 7.0.2.
This page as .md · .json · in your agent: get_signal("CVE-2026-42196")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.