GHSA-8HW4-7QJR-3WXG

Vulnerability from github – Published: 2026-08-20 18:38 – Updated: 2026-08-20 18:38
VLAI
Summary
Laravel Backpack CRUD: SingleBase64Image accepts any base64 payload behind a `data:image` prefix — SVG-with-script lands on the public disk
Details

Summary

SingleBase64Image::uploadFiles — the uploader bound to image-typed fields via withFiles() — only verifies that the submitted value starts with the string data:image. The MIME subtype and the base64-decoded bytes are never inspected or validated. A related bug in FileNameGenerator causes the stored file to receive an extensionless filename, because mime_content_type() returns false when given a data URI instead of a filesystem path.

The combination allows an authenticated admin to store a file of arbitrary type on the configured disk under a name without a recognizable extension.

Details

// src/app/Library/Uploaders/SingleBase64Image.php
if (Str::startsWith($value, 'data:image')) {
    // MIME subtype and decoded bytes are not validated
    $base64Image = Str::after($value, ';base64,');
    $finalPath   = $this->getPath() . $this->getFileName($value);
    Storage::disk($this->getDisk())->put($finalPath, base64_decode($base64Image));
    return $finalPath;
}

// src/app/Library/Uploaders/Support/FileNameGenerator.php
private function getExtensionFromFile(string|UploadedFile $file): string
{
    return is_a($file, UploadedFile::class, true)
        ? $file->extension()
        : Str::after(mime_content_type($file), '/'); // returns false on data URIs → empty string
}

The stored filename ends with a trailing dot and no extension.

Impact

An authenticated admin submitting a malicious payload to a Backpack image field stored with withFiles() can write arbitrary file content to the configured storage disk. Depending on server configuration and how stored files are served, this may lead to stored XSS or other unintended behavior when the file is later accessed.

Fix

The fix validates the declared MIME subtype against an allowlist, decodes the base64 payload, and verifies the actual file bytes with finfo before storing. The extension is derived from the detected MIME type rather than the data URI string. Applied in SingleBase64Image::uploadFiles and uploadRepeatableFiles; FileNameGenerator::getExtensionFromFile now rejects inputs that produce an empty extension.

Setting X-Content-Type-Options: nosniff on admin responses is a useful defense-in-depth complement.

Affected versions

  • >= 6.0.0, < 6.8.14
  • >= 7.0.0, < 7.0.38

Patched versions

  • 6.8.14
  • 7.0.38
Severity
4.4 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "backpack/crud"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.0.0"
            },
            {
              "fixed": "6.8.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "backpack/crud"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.0.38"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54179"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-20T18:38:43Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\n`SingleBase64Image::uploadFiles` \u2014 the uploader bound to `image`-typed fields via `withFiles()` \u2014 only verifies that the submitted value starts with the string `data:image`. The MIME subtype and the base64-decoded bytes are never inspected or validated. A related bug in `FileNameGenerator` causes the stored file to receive an extensionless filename, because `mime_content_type()` returns `false` when given a data URI instead of a filesystem path.\n\nThe combination allows an authenticated admin to store a file of arbitrary type on the configured disk under a name without a recognizable extension.\n\n### Details\n\n```php\n// src/app/Library/Uploaders/SingleBase64Image.php\nif (Str::startsWith($value, \u0027data:image\u0027)) {\n    // MIME subtype and decoded bytes are not validated\n    $base64Image = Str::after($value, \u0027;base64,\u0027);\n    $finalPath   = $this-\u003egetPath() . $this-\u003egetFileName($value);\n    Storage::disk($this-\u003egetDisk())-\u003eput($finalPath, base64_decode($base64Image));\n    return $finalPath;\n}\n\n// src/app/Library/Uploaders/Support/FileNameGenerator.php\nprivate function getExtensionFromFile(string|UploadedFile $file): string\n{\n    return is_a($file, UploadedFile::class, true)\n        ? $file-\u003eextension()\n        : Str::after(mime_content_type($file), \u0027/\u0027); // returns false on data URIs \u2192 empty string\n}\n```\n\nThe stored filename ends with a trailing dot and no extension.\n\n### Impact\n\nAn authenticated admin submitting a malicious payload to a Backpack `image` field stored with `withFiles()` can write arbitrary file content to the configured storage disk. Depending on server configuration and how stored files are served, this may lead to stored XSS or other unintended behavior when the file is later accessed.\n\n### Fix\n\nThe fix validates the declared MIME subtype against an allowlist, decodes the base64 payload, and verifies the actual file bytes with `finfo` before storing. The extension is derived from the detected MIME type rather than the data URI string. Applied in `SingleBase64Image::uploadFiles` and `uploadRepeatableFiles`; `FileNameGenerator::getExtensionFromFile` now rejects inputs that produce an empty extension.\n\nSetting `X-Content-Type-Options: nosniff` on admin responses is a useful defense-in-depth complement.\n\n### Affected versions\n\n- `\u003e= 6.0.0, \u003c 6.8.14`\n- `\u003e= 7.0.0, \u003c 7.0.38`\n\n### Patched versions\n\n- `6.8.14`\n- `7.0.38`",
  "id": "GHSA-8hw4-7qjr-3wxg",
  "modified": "2026-08-20T18:38:43Z",
  "published": "2026-08-20T18:38:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Laravel-Backpack/CRUD/security/advisories/GHSA-8hw4-7qjr-3wxg"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Laravel-Backpack/CRUD"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Laravel-Backpack/CRUD/releases/tag/6.8.14"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Laravel-Backpack/CRUD/releases/tag/7.0.38"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Laravel Backpack CRUD: SingleBase64Image accepts any base64 payload behind a `data:image` prefix \u2014 SVG-with-script lands on the public disk"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





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.


Detection rules are retrieved from Rulezet.