GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-JQ29-C7V8-RG55

Vulnerability from github – Published: 2026-09-17 20:34 – Updated: 2026-09-17 20:34
VLAI
Summary
Grav: Path Traversal in MediaUploadTrait::deleteFile() Allows Arbitrary File Deletion
Details

Path 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:

  1. FlexMediaTrait::setUpdatedMedia() (line 386) iterates form flash data where $filename is the array key - user-controlled
  2. 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)
  3. The raw filename is stored in $this->_uploads at line 414
  4. 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).

  1. Create a target file:
echo "DELETE_ME" > /var/www/grav/user/data/target.txt
  1. 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)
  1. When saveUpdatedMedia() processes the deletion queue:
  2. $filename = ../../data/target.txt
  3. deleteFile("../../data/target.txt") is called
  4. $basename = target.txt (passes checkFilename())
  5. $pathname = ../../data/
  6. $name = ../../data/target.txt
  7. doRemove() calls unlink("/var/www/grav/user/pages/mypage/../../data/target.txt")
  8. Which resolves to unlink("/var/www/grav/user/data/target.txt")

  9. 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.php lines 332-365, 521-582
  • Caller: system/src/Grav/Framework/Flex/Traits/FlexMediaTrait.php lines 386-414, 490-499
  • Sibling: system/src/Grav/Common/Media/Traits/MediaUploadTrait.php lines 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.

Show details on source website

{
  "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"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

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.


Loading…