GHSA-F74M-X83R-C4V4
Vulnerability from github – Published: 2026-11-09 22:17 – Updated: 2026-11-09 22:17Summary
GET /batchdownload streams a batch ZIP to any requester who supplies its uniqid, without checking that the current user/session created it. In deployments where users have separate home directories, a valid low-privileged user who obtains an active archive id can download another user's batch archive, disclosing files the per-user boundary otherwise protects. Reported with explicit preconditions and bounded impact — not a universal "any user steals any file" issue.
Details
The archive id is generated with plain uniqid() and no ownership metadata is bound to it before streaming.
backend/Services/Archiver/Adapters/ZipArchiver.php:44—createArchive()uses plainuniqid().backend/Controllers/DownloadController.php:144-145—batchDownloadStart()reads the tmpfs file by the request-supplieduniqidafter only a charsetpreg_replace().backend/Controllers/DownloadController.php:158— the tmpfs archive is removed only after streaming.backend/Controllers/routes.php:207-226— both batch endpoints are exposed to normal roles withread,download,batchdownload.
No user id, session id, home directory, or creator check is applied before streaming. The code path is unchanged since commit 3f03a40 (2022-05-31) and is present in the latest release v7.14.3.
PoC
Preconditions: a multi-user deployment with distinct per-user homedirs (set per-user in users.json, or private_repos => true on the WordPress/LDAP adapter). The shipped sample config (admin/guest both at /, guest with no perms) does not create this boundary on its own. Attacker is a valid user with read, download, batchdownload.
- User John (
homedir /john) createssecret.txt, signs in, and creates a batch archive viaPOST /batchdownload. The JSON response returns the archiveuniqid. - User Jane (
homedir /jane, withbatchdownload) signs in normally. - Jane's direct
GET /downloadof/secret.txtreturns302— the normal home-directory boundary blocks the file. - Jane sends
GET /batchdownload?uniqid=<John's id>and receives a valid ZIP containingsecret.txtwith John's content.
A PHPUnit proof with two real sessions reproduces this end to end (OK, 3 tests / 29 assertions), plus a lifecycle test (OK, 2 tests / 9 assertions). Full test files, run logs, and a real Apache access-log replay demo are available on request.
Lifetime / acquisition: a normal completed download removes the archive at the end of streaming, limiting the window. An aborted/failed download leaves the archive in tmpfs (cleanup never reached). The frontend issues the download as a top-level navigation (window.open('.../batchdownload&uniqid='+ret.uniqid, '_blank')), so the id appears in standard web access logs. That access-log path only adds meaningful impact when log visibility is decoupled from host filesystem access (e.g. a log-aggregation/shared-hosting/downstream-sink reader) and the archive is still alive; if the reader is ops/root on the same host they can already read the storage tree directly. The uniqid() token is timestamp-derived (1,000,000-value space per known second) — included to justify a CSPRNG, not presented as a practical universal brute force.
Impact
Missing authorization (CWE-862) on a temporary download object, leading to cross-user file disclosure across the per-user home-directory boundary in configured multi-user deployments. Secondary effect: a successful replay deletes the victim's pending archive (the GET removes the tmpfs file after streaming), denying the victim their own download if not yet consumed.
Remediation: generate ids with bin2hex(random_bytes(32)); store creator user/session + home dir + expiry per archive id; verify the requester matches before streaming and return 403/404 on mismatch or unknown/expired id; delete metadata with the tmpfs file.
{
"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-94618"
],
"database_specific": {
"cwe_ids": [
"CWE-330",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-11-09T22:17:36Z",
"nvd_published_at": "2026-11-06T22:18:00Z",
"severity": "MODERATE"
},
"details": "### Summary\n`GET /batchdownload` streams a batch ZIP to any requester who supplies its `uniqid`, without checking that the current user/session created it. In deployments where users have separate home directories, a valid low-privileged user who obtains an active archive id can download another user\u0027s batch archive, disclosing files the per-user boundary otherwise protects. Reported with explicit preconditions and bounded impact \u2014 not a universal \"any user steals any file\" issue.\n\n### Details\nThe archive id is generated with plain `uniqid()` and no ownership metadata is bound to it before streaming.\n\n- `backend/Services/Archiver/Adapters/ZipArchiver.php:44` \u2014 `createArchive()` uses plain `uniqid()`.\n- `backend/Controllers/DownloadController.php:144-145` \u2014 `batchDownloadStart()` reads the tmpfs file by the request-supplied `uniqid` after only a charset `preg_replace()`.\n- `backend/Controllers/DownloadController.php:158` \u2014 the tmpfs archive is removed only after streaming.\n- `backend/Controllers/routes.php:207-226` \u2014 both batch endpoints are exposed to normal roles with `read`, `download`, `batchdownload`.\n\nNo user id, session id, home directory, or creator check is applied before streaming. The code path is unchanged since commit `3f03a40` (2022-05-31) and is present in the latest release `v7.14.3`.\n\n### PoC\nPreconditions: a multi-user deployment with distinct per-user `homedir`s (set per-user in `users.json`, or `private_repos =\u003e true` on the WordPress/LDAP adapter). The shipped sample config (`admin`/`guest` both at `/`, `guest` with no perms) does not create this boundary on its own. Attacker is a valid user with `read`, `download`, `batchdownload`.\n\n1. User John (`homedir /john`) creates `secret.txt`, signs in, and creates a batch archive via `POST /batchdownload`. The JSON response returns the archive `uniqid`.\n2. User Jane (`homedir /jane`, with `batchdownload`) signs in normally.\n3. Jane\u0027s direct `GET /download` of `/secret.txt` returns `302` \u2014 the normal home-directory boundary blocks the file.\n4. Jane sends `GET /batchdownload?uniqid=\u003cJohn\u0027s id\u003e` and receives a valid ZIP containing `secret.txt` with John\u0027s content.\n\nA PHPUnit proof with two real sessions reproduces this end to end (`OK, 3 tests / 29 assertions`), plus a lifecycle test (`OK, 2 tests / 9 assertions`). Full test files, run logs, and a real Apache access-log replay demo are available on request.\n\nLifetime / acquisition: a normal completed download removes the archive at the end of streaming, limiting the window. An aborted/failed download leaves the archive in tmpfs (cleanup never reached). The frontend issues the download as a top-level navigation (`window.open(\u0027.../batchdownload\u0026uniqid=\u0027+ret.uniqid, \u0027_blank\u0027)`), so the id appears in standard web access logs. That access-log path only adds meaningful impact when log visibility is decoupled from host filesystem access (e.g. a log-aggregation/shared-hosting/downstream-sink reader) and the archive is still alive; if the reader is ops/root on the same host they can already read the storage tree directly. The `uniqid()` token is timestamp-derived (1,000,000-value space per known second) \u2014 included to justify a CSPRNG, not presented as a practical universal brute force.\n\n### Impact\nMissing authorization (CWE-862) on a temporary download object, leading to cross-user file disclosure across the per-user home-directory boundary in configured multi-user deployments. Secondary effect: a successful replay deletes the victim\u0027s pending archive (the GET removes the tmpfs file after streaming), denying the victim their own download if not yet consumed.\n\nRemediation: generate ids with `bin2hex(random_bytes(32))`; store creator user/session + home dir + expiry per archive id; verify the requester matches before streaming and return `403`/`404` on mismatch or unknown/expired id; delete metadata with the tmpfs file.",
"id": "GHSA-f74m-x83r-c4v4",
"modified": "2026-11-09T22:17:36Z",
"published": "2026-11-09T22:17:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/filegator/filegator/security/advisories/GHSA-f74m-x83r-c4v4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-94618"
},
{
"type": "WEB",
"url": "https://github.com/filegator/filegator/pull/597"
},
{
"type": "WEB",
"url": "https://github.com/filegator/filegator/commit/638737e560cbf20cbeb5da4e4e6c974f8a080531"
},
{
"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:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "FileGator: Missing authorization in GET /batchdownload allows cross-user retrieval of another user\u0027s archive"
}
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.