GHSA-44R8-3P76-84MW
Vulnerability from github – Published: 2026-11-09 22:20 – Updated: 2026-11-09 22:20Summary
POST /upload uses the request-supplied resumableFilename directly as a key into the shared temporary directory, without the character filter it applies to resumableIdentifier and without namespacing it per user. A valid user holding the upload permission can read any file in that directory into their own home directory, append to it, and delete it.
This reproduces the cross-user batch-archive disclosure of GHSA-f74m-x83r-c4v4 through a different route — it still works with the fix for that advisory (PR #597) applied — and additionally allows deleting the login rate-limit lockfile.
Reported with explicit preconditions and bounded impact, as before: the primitive is confined to the temporary directory, not the whole filesystem.
Details
backend/Controllers/UploadController.php:61—$file_name = $request->input('resumableFilename', 'file')is not passed through thepreg_replace('/[^0-9a-zA-Z_]/', '', ...)that line 66 applies toresumableIdentifier.- Line 88 builds
$prefixnamespaced by the sanitized username, but$file_namereaches the temporary storage at lines 118, 121 and 125 without that prefix. - Line 115 —
if ($chunks_size >= $total_size)is entered wheneverresumableTotalSizeis0. - Lines 116-119 — the assembly loop
for ($i = 1; $i <= $total_chunks; ++$i)does not execute whenresumableTotalChunksis0, so nothing is written to$file_name. - Line 121 —
readStream($file_name)therefore reads the pre-existing temporary file of that exact name. - Line 122 — its contents are stored into the requester's own home directory.
- Line 125 —
remove($file_name)deletes it.
Path traversal outside the temporary directory is prevented by Tmpfs::sanitizeFilename(), so the primitive is bounded to that directory — but every user's transient objects share it.
PoC
Preconditions: a multi-user deployment with distinct per-user homedirs. The attacker is a valid low-privileged user holding upload (a first-class permission in the admin UI, and present in the shipped users.json.blank admin set).
- Victim creates a batch archive via
POST /batchdownload; the JSON response returns the archive id. - Attacker sends one
POST /uploadwithresumableFilename=<victim's id>,resumableTotalChunks=0,resumableTotalSize=0,resumableRelativePath=/, and any small valid file part. - Response is
{"data":"Stored"}. The victim's archive is now byte-identical in the attacker's home directory, retrievable through the ordinaryGET /download. The victim's temporary archive has been deleted.
Verified end to end with a PHPUnit test against current master; the archive contents matched byte for byte. Test file available on request.
Impact
Missing authorization (CWE-862) on temporary storage objects.
- Cross-user disclosure of any transient object whose name the attacker can learn or predict. This includes batch archives — so GHSA-f74m-x83r-c4v4's impact remains reachable even with its fix applied — and the plaintext per-file copies that
ZipArchiver::addFileFromStorage()writes while an archive is being built (those still useuniqid(), which is timestamp-derived). - Arbitrary delete within the temporary directory.
AuthController::login()stores the login rate-limit counter asmd5($ip).'.lock'in that same directory (backend/Controllers/AuthController.php:36, checked at line 44, written at line 58). An attacker can compute their own lockfile name and delete it, defeating the lockout. - Arbitrary append: with
resumableTotalChunks >= 1, line 118write($file_name, ..., true)appends attacker-controlled bytes to an arbitrary existing temporary file.
Remediation
Do not use the request-supplied filename as a storage key. Namespace the assembly file per user — for example reuse the existing $prefix — and carry the display filename separately for the storage->store() call.
Note that simply applying the [^0-9a-zA-Z_] filter to resumableFilename would corrupt legitimate uploads (sample.txt becomes sampletxt), because $final['filename'] is what becomes the stored name. The fix needs the namespacing, not just the filter.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.14.4"
},
"package": {
"ecosystem": "Packagist",
"name": "filegator/filegator"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "7.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-94619"
],
"database_specific": {
"cwe_ids": [
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-11-09T22:20:08Z",
"nvd_published_at": "2026-11-06T22:18:00Z",
"severity": "MODERATE"
},
"details": "## Summary\n\n`POST /upload` uses the request-supplied `resumableFilename` directly as a key into the shared temporary directory, without the character filter it applies to `resumableIdentifier` and without namespacing it per user. A valid user holding the `upload` permission can read any file in that directory into their own home directory, append to it, and delete it.\n\nThis reproduces the cross-user batch-archive disclosure of GHSA-f74m-x83r-c4v4 through a different route \u2014 it still works with the fix for that advisory (PR #597) applied \u2014 and additionally allows deleting the login rate-limit lockfile.\n\nReported with explicit preconditions and bounded impact, as before: the primitive is confined to the temporary directory, not the whole filesystem.\n\n## Details\n\n- `backend/Controllers/UploadController.php:61` \u2014 `$file_name = $request-\u003einput(\u0027resumableFilename\u0027, \u0027file\u0027)` is **not** passed through the `preg_replace(\u0027/[^0-9a-zA-Z_]/\u0027, \u0027\u0027, ...)` that line 66 applies to `resumableIdentifier`.\n- Line 88 builds `$prefix` namespaced by the sanitized username, but `$file_name` reaches the temporary storage at lines 118, 121 and 125 **without** that prefix.\n- Line 115 \u2014 `if ($chunks_size \u003e= $total_size)` is entered whenever `resumableTotalSize` is `0`.\n- Lines 116-119 \u2014 the assembly loop `for ($i = 1; $i \u003c= $total_chunks; ++$i)` does not execute when `resumableTotalChunks` is `0`, so nothing is written to `$file_name`.\n- Line 121 \u2014 `readStream($file_name)` therefore reads the pre-existing temporary file of that exact name.\n- Line 122 \u2014 its contents are stored into the requester\u0027s own home directory.\n- Line 125 \u2014 `remove($file_name)` deletes it.\n\nPath traversal outside the temporary directory is prevented by `Tmpfs::sanitizeFilename()`, so the primitive is bounded to that directory \u2014 but every user\u0027s transient objects share it.\n\n## PoC\n\nPreconditions: a multi-user deployment with distinct per-user `homedir`s. The attacker is a valid low-privileged user holding `upload` (a first-class permission in the admin UI, and present in the shipped `users.json.blank` admin set).\n\n1. Victim creates a batch archive via `POST /batchdownload`; the JSON response returns the archive id.\n2. Attacker sends **one** `POST /upload` with `resumableFilename=\u003cvictim\u0027s id\u003e`, `resumableTotalChunks=0`, `resumableTotalSize=0`, `resumableRelativePath=/`, and any small valid file part.\n3. Response is `{\"data\":\"Stored\"}`. The victim\u0027s archive is now byte-identical in the attacker\u0027s home directory, retrievable through the ordinary `GET /download`. The victim\u0027s temporary archive has been deleted.\n\nVerified end to end with a PHPUnit test against current `master`; the archive contents matched byte for byte. Test file available on request.\n\n## Impact\n\nMissing authorization (CWE-862) on temporary storage objects.\n\n- **Cross-user disclosure** of any transient object whose name the attacker can learn or predict. This includes batch archives \u2014 so GHSA-f74m-x83r-c4v4\u0027s impact remains reachable even with its fix applied \u2014 and the plaintext per-file copies that `ZipArchiver::addFileFromStorage()` writes while an archive is being built (those still use `uniqid()`, which is timestamp-derived).\n- **Arbitrary delete** within the temporary directory. `AuthController::login()` stores the login rate-limit counter as `md5($ip).\u0027.lock\u0027` in that same directory (`backend/Controllers/AuthController.php:36`, checked at line 44, written at line 58). An attacker can compute their own lockfile name and delete it, defeating the lockout.\n- **Arbitrary append**: with `resumableTotalChunks \u003e= 1`, line 118 `write($file_name, ..., true)` appends attacker-controlled bytes to an arbitrary existing temporary file.\n\n## Remediation\n\nDo not use the request-supplied filename as a storage key. Namespace the assembly file per user \u2014 for example reuse the existing `$prefix` \u2014 and carry the display filename separately for the `storage-\u003estore()` call.\n\nNote that simply applying the `[^0-9a-zA-Z_]` filter to `resumableFilename` would corrupt legitimate uploads (`sample.txt` becomes `sampletxt`), because `$final[\u0027filename\u0027]` is what becomes the stored name. The fix needs the namespacing, not just the filter.",
"id": "GHSA-44r8-3p76-84mw",
"modified": "2026-11-09T22:20:09Z",
"published": "2026-11-09T22:20:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/filegator/filegator/security/advisories/GHSA-44r8-3p76-84mw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94619"
},
{
"type": "WEB",
"url": "https://github.com/filegator/filegator/pull/598"
},
{
"type": "WEB",
"url": "https://github.com/filegator/filegator/commit/cae442a8323fddae7c8cee0924cdbb1aa6eea702"
},
{
"type": "PACKAGE",
"url": "https://github.com/filegator/filegator"
},
{
"type": "WEB",
"url": "https://github.com/filegator/filegator/releases/tag/v7.15.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "FileGator: Missing authorization in POST /upload allows cross-user read and deletion of temporary files"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
How durations are calculated
Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.
Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.