GHSA-JQ29-C7V8-RG55
Vulnerability from github – Published: 2026-09-17 20:34 – Updated: 2026-09-17 20:34Path Traversal in MediaUploadTrait::deleteFile() Allows Arbitrary File Deletion
Summary
A path traversal vulnerability in MediaUploadTrait::deleteFile() allows an authenticated user with media management permissions to delete arbitrary files on the server. The method validates only the basename portion of the filename using Utils::checkFilename(), while the directory path (which may contain ../ sequences) is preserved and passed unvalidated to unlink(). This enables directory escape from the intended media storage path.
Severity
High (8.1) - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
CWE
CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Details
In system/src/Grav/Common/Media/Traits/MediaUploadTrait.php, the deleteFile() method (lines 332-365) performs filename validation only on the basename, not the full path:
public function deleteFile(string $filename, ?array $settings = null): void
{
$settings = $this->getUploadSettings($settings);
$filesystem = Filesystem::getInstance(false);
// Line 339-340: Only the BASENAME is validated
$basename = $filesystem->basename($filename); // e.g. "evil.jpg" from "../../evil.jpg"
if (!Utils::checkFilename($basename)) { // passes - no traversal in basename
throw new RuntimeException(/* ... */);
}
$path = $settings['destination'] ?? $this->getPath();
// ...
// Line 353: Full pathname (with traversal) is preserved
$pathname = $filesystem->pathname($filename); // "../../"
// Line 356-357: Traversal path reconstructed
[$base, $ext,,] = $this->getFileParts($basename);
$name = "{$pathname}{$base}.{$ext}"; // "../../evil.jpg"
// Line 360: Passed to doRemove()
$this->doRemove($name, $path);
}
doRemove() (line 521-582) then calls:
// Line 538
unlink("{$folder}/{$filename}");
// e.g. unlink("/var/www/grav/user/pages/mypage/../../config/system.yaml")
Utils::checkFilename() (lines 1022-1044) properly checks for /, \, and .., but it is applied to $filesystem->basename($filename) (the last path component only), so traversal sequences in the directory portion are never validated.
Data flow from user input
The vulnerability is reachable through the Flex media handling pipeline:
FlexMediaTrait::setUpdatedMedia()(line 386) iterates form flash data where$filenameis the array key - user-controlled- For file deletions (
$fileis null, line 396), NO upload validation is performed (thecheckUploadedFile()call at line 401 only executes when$fileis truthy) - The raw filename is stored in
$this->_uploadsat line 414 saveUpdatedMedia()(line 499) calls$media->deleteFile($filename, $settings)with the unsanitized filename
Sibling: renameFile()
The same pattern exists in renameFile() (lines 374-405) which has even weaker validation - it performs NO checkFilename() call at all. While renameFile() currently has no callers in the core codebase, it is part of the public MediaUploadInterface and should be fixed as defense-in-depth.
Proof of Concept
Environment: Grav CMS 2.0.16 with admin plugin
The attack requires an authenticated admin user with page/media editing permissions (not super-admin).
- Create a target file:
echo "DELETE_ME" > /var/www/grav/user/data/target.txt
- Submit a Flex object form (e.g. page edit) with a crafted media deletion where the filename key contains path traversal:
POST /admin/pages/mypage/task:save
Content-Type: multipart/form-data
# The form flash data includes a media deletion entry with key:
# "../../data/target.txt" -> null (deletion marker)
- When
saveUpdatedMedia()processes the deletion queue: $filename=../../data/target.txtdeleteFile("../../data/target.txt")is called$basename=target.txt(passescheckFilename())$pathname=../../data/$name=../../data/target.txtdoRemove()callsunlink("/var/www/grav/user/pages/mypage/../../data/target.txt")-
Which resolves to
unlink("/var/www/grav/user/data/target.txt") -
The file is deleted outside the intended media directory.
Impact
An authenticated user with media management permissions can:
- Delete configuration files (user/config/system.yaml, user/config/security.yaml)
- Delete other pages' content files
- Delete authentication-related files (user account YAML files)
- Cause denial of service by removing critical application files
- Potentially escalate privileges by removing security configuration
Suggested Fix
Apply Utils::checkFilename() to the full $filename parameter before decomposing it, or reject any filename containing directory separators or .. sequences:
public function deleteFile(string $filename, ?array $settings = null): void
{
$settings = $this->getUploadSettings($settings);
$filesystem = Filesystem::getInstance(false);
// Validate the FULL filename, not just the basename
if (!Utils::checkFilename($filename)) {
throw new RuntimeException(/* ... */);
}
// ... rest unchanged
}
The same fix should be applied to renameFile() for both $from and $to parameters.
References
- Vulnerable file:
system/src/Grav/Common/Media/Traits/MediaUploadTrait.phplines 332-365, 521-582 - Caller:
system/src/Grav/Framework/Flex/Traits/FlexMediaTrait.phplines 386-414, 490-499 - Sibling:
system/src/Grav/Common/Media/Traits/MediaUploadTrait.phplines 374-405 (renameFile) - Related GHSA: GHSA-g6j3-8jv9-ch5f (path traversal in PagesController::batchCopy - different file, same bug class)
Disclosure
This vulnerability was discovered using AI-assisted security research tools.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.15"
},
"package": {
"ecosystem": "Packagist",
"name": "getgrav/grav"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.16"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-72695"
],
"database_specific": {
"cwe_ids": [
"CWE-22"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-17T20:34:05Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "# Path Traversal in MediaUploadTrait::deleteFile() Allows Arbitrary File Deletion\n\n## Summary\n\nA path traversal vulnerability in `MediaUploadTrait::deleteFile()` allows an authenticated user with media management permissions to delete arbitrary files on the server. The method validates only the basename portion of the filename using `Utils::checkFilename()`, while the directory path (which may contain `../` sequences) is preserved and passed unvalidated to `unlink()`. This enables directory escape from the intended media storage path.\n\n## Severity\n\n**High (8.1)** - CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H\n\n## CWE\n\nCWE-22: Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)\n\n## Details\n\nIn `system/src/Grav/Common/Media/Traits/MediaUploadTrait.php`, the `deleteFile()` method (lines 332-365) performs filename validation only on the basename, not the full path:\n\n```php\npublic function deleteFile(string $filename, ?array $settings = null): void\n{\n $settings = $this-\u003egetUploadSettings($settings);\n $filesystem = Filesystem::getInstance(false);\n\n // Line 339-340: Only the BASENAME is validated\n $basename = $filesystem-\u003ebasename($filename); // e.g. \"evil.jpg\" from \"../../evil.jpg\"\n if (!Utils::checkFilename($basename)) { // passes - no traversal in basename\n throw new RuntimeException(/* ... */);\n }\n\n $path = $settings[\u0027destination\u0027] ?? $this-\u003egetPath();\n // ...\n\n // Line 353: Full pathname (with traversal) is preserved\n $pathname = $filesystem-\u003epathname($filename); // \"../../\"\n\n // Line 356-357: Traversal path reconstructed\n [$base, $ext,,] = $this-\u003egetFileParts($basename);\n $name = \"{$pathname}{$base}.{$ext}\"; // \"../../evil.jpg\"\n\n // Line 360: Passed to doRemove()\n $this-\u003edoRemove($name, $path);\n}\n```\n\n`doRemove()` (line 521-582) then calls:\n\n```php\n// Line 538\nunlink(\"{$folder}/{$filename}\");\n// e.g. unlink(\"/var/www/grav/user/pages/mypage/../../config/system.yaml\")\n```\n\n`Utils::checkFilename()` (lines 1022-1044) properly checks for `/`, `\\`, and `..`, but it is applied to `$filesystem-\u003ebasename($filename)` (the last path component only), so traversal sequences in the directory portion are never validated.\n\n### Data flow from user input\n\nThe vulnerability is reachable through the Flex media handling pipeline:\n\n1. `FlexMediaTrait::setUpdatedMedia()` (line 386) iterates form flash data where `$filename` is the array key - user-controlled\n2. For file deletions (`$file` is null, line 396), NO upload validation is performed (the `checkUploadedFile()` call at line 401 only executes when `$file` is truthy)\n3. The raw filename is stored in `$this-\u003e_uploads` at line 414\n4. `saveUpdatedMedia()` (line 499) calls `$media-\u003edeleteFile($filename, $settings)` with the unsanitized filename\n\n### Sibling: renameFile()\n\nThe same pattern exists in `renameFile()` (lines 374-405) which has even weaker validation - it performs NO `checkFilename()` call at all. While `renameFile()` currently has no callers in the core codebase, it is part of the public `MediaUploadInterface` and should be fixed as defense-in-depth.\n\n## Proof of Concept\n\n**Environment**: Grav CMS 2.0.16 with admin plugin\n\nThe attack requires an authenticated admin user with page/media editing permissions (not super-admin).\n\n1. Create a target file:\n```bash\necho \"DELETE_ME\" \u003e /var/www/grav/user/data/target.txt\n```\n\n2. Submit a Flex object form (e.g. page edit) with a crafted media deletion where the filename key contains path traversal:\n\n```\nPOST /admin/pages/mypage/task:save\nContent-Type: multipart/form-data\n\n# The form flash data includes a media deletion entry with key:\n# \"../../data/target.txt\" -\u003e null (deletion marker)\n```\n\n3. When `saveUpdatedMedia()` processes the deletion queue:\n - `$filename` = `../../data/target.txt`\n - `deleteFile(\"../../data/target.txt\")` is called\n - `$basename` = `target.txt` (passes `checkFilename()`)\n - `$pathname` = `../../data/`\n - `$name` = `../../data/target.txt`\n - `doRemove()` calls `unlink(\"/var/www/grav/user/pages/mypage/../../data/target.txt\")`\n - Which resolves to `unlink(\"/var/www/grav/user/data/target.txt\")`\n\n4. The file is deleted outside the intended media directory.\n\n### Impact\n\nAn authenticated user with media management permissions can:\n- Delete configuration files (`user/config/system.yaml`, `user/config/security.yaml`)\n- Delete other pages\u0027 content files\n- Delete authentication-related files (user account YAML files)\n- Cause denial of service by removing critical application files\n- Potentially escalate privileges by removing security configuration\n\n## Suggested Fix\n\nApply `Utils::checkFilename()` to the full `$filename` parameter before decomposing it, or reject any filename containing directory separators or `..` sequences:\n\n```php\npublic function deleteFile(string $filename, ?array $settings = null): void\n{\n $settings = $this-\u003egetUploadSettings($settings);\n $filesystem = Filesystem::getInstance(false);\n\n // Validate the FULL filename, not just the basename\n if (!Utils::checkFilename($filename)) {\n throw new RuntimeException(/* ... */);\n }\n\n // ... rest unchanged\n}\n```\n\nThe same fix should be applied to `renameFile()` for both `$from` and `$to` parameters.\n\n## References\n\n- Vulnerable file: `system/src/Grav/Common/Media/Traits/MediaUploadTrait.php` lines 332-365, 521-582\n- Caller: `system/src/Grav/Framework/Flex/Traits/FlexMediaTrait.php` lines 386-414, 490-499\n- Sibling: `system/src/Grav/Common/Media/Traits/MediaUploadTrait.php` lines 374-405 (renameFile)\n- Related GHSA: GHSA-g6j3-8jv9-ch5f (path traversal in PagesController::batchCopy - different file, same bug class)\n\n## Disclosure\n\nThis vulnerability was discovered using AI-assisted security research tools.",
"id": "GHSA-jq29-c7v8-rg55",
"modified": "2026-09-17T20:34:05Z",
"published": "2026-09-17T20:34:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getgrav/grav/security/advisories/GHSA-jq29-c7v8-rg55"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72695"
},
{
"type": "PACKAGE",
"url": "https://github.com/getgrav/grav"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/grav-before-path-traversal-via-mediauploadtrait-deletefile"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Grav: Path Traversal in MediaUploadTrait::deleteFile() Allows Arbitrary File Deletion"
}
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.
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.