CVE-2026-54179 in CRUD
Summary
by MITRE • 08/31/2026
backpack/crud provides Create, Read, Update & Delete (CRUD) functions for Backpack, a collection of Laravel packages that help users build custom administration panels. From 6.0.0 until 6.8.14 and 7.0.37, the src/app/Library/Uploaders/SingleBase64Image.php methods SingleBase64Image::uploadFiles and SingleBase64Image::uploadRepeatableFiles, used by image fields through withFiles(), accept any data URI beginning with data:image without validating the declared MIME subtype or decoded bytes, while src/app/Library/Uploaders/Support/FileNameGenerator.php method FileNameGenerator::getExtensionFromFile applies mime_content_type() to the data URI instead of the decoded content. An authenticated administrator can therefore store arbitrary file content under an extensionless filename on the configured disk, which can cause stored cross-site scripting or other unintended behavior when the file is served and accessed. This issue is fixed in version 7.0.38 and 6.8.14.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified within the backpack/crud package affects versions ranging from 6.0.0 through 6.8.14, as well as version 7.0.37 of the framework. This software is a widely used collection of Laravel packages designed to facilitate the creation of custom administration panels by providing robust Create, Read, Update, and Delete functionalities. The specific flaw resides in the file upload handling mechanisms, particularly within the SingleBase64Image class located at src/app/Library/Uploaders/SingleBase64Image.php. This component is responsible for processing image fields that utilize the withFiles() method to manage media assets uploaded by administrators through the administrative interface.
The core technical deficiency lies in how the uploadFiles and uploadRepeatableFiles methods validate incoming data URIs. When a user submits an image via these endpoints, the system checks only if the URI begins with the string "data:image". It fails to perform any subsequent validation on the declared MIME subtype or inspect the actual decoded bytes of the payload. This lack of deep inspection allows attackers to bypass standard file type restrictions by crafting malicious data URIs that appear valid at a superficial level but contain executable code rather than legitimate image data.
Compounding this issue is a critical error in the FileNameGenerator class found at src/app/Library/Uploaders/Support/FileNameGenerator.php. The getExtensionFromFile method attempts to determine the appropriate file extension for storage by applying the PHP function mime_content_type() directly to the raw data URI string rather than decoding it first and analyzing the binary content. Since mime_content_type() expects a file path or stream, its application to an encoded URI string yields unreliable results or fails entirely, leading the system to store files without appending any extension. This behavior is particularly dangerous because many web servers and browsers rely on file extensions to determine how to handle served resources.
An authenticated administrator can exploit this flaw to upload arbitrary file content under an extensionless filename to the configured disk storage. While the requirement for authentication limits the attack surface, it does not eliminate risk, as administrative accounts are often targeted or compromised through other vectors such as credential stuffing or session hijacking. Once stored, these files lack extensions that would typically trigger safe handling by web servers. When the system serves these files back to a user's browser, the absence of an extension combined with potentially misleading content headers can cause the browser to interpret the payload incorrectly.
The primary operational impact is the potential for Stored Cross-Site Scripting. If an attacker uploads a file containing JavaScript code and it is served without proper sanitization or correct MIME type enforcement by the web server, the script may execute in the context of other users viewing the administration panel. This can lead to session hijacking, defacement, or further lateral movement within the application environment. Beyond XSS, this vulnerability represents an Unrestricted File Upload flaw that could potentially be leveraged for remote code execution if the hosting infrastructure allows execution of files with ambiguous types or specific configurations are present on the web server.
This issue aligns closely with CWE-434, which describes the unrestricted upload of file with dangerous type, and CWE-20, indicating improper input validation where external data is not sufficiently verified before use in security decisions. In terms of the MITRE ATT&CK framework, this vulnerability facilitates techniques associated with Initial Access via Valid Accounts and Execution through Web Shell or Scripting Interpreter activities, depending on how the uploaded content is ultimately processed by the server infrastructure.
The recommended mitigation strategy involves upgrading to version 7.0.38 or 6.8.14 of backpack/crud, where these validation gaps have been addressed. For organizations unable to upgrade immediately, implementing a robust file upload middleware at the application level can provide temporary relief. This should include strict allow-listing of permitted MIME types based on actual content inspection rather than extension checking, ensuring that decoded binary data is analyzed using reliable libraries like libmagic or PHP's finfo before storage. Additionally, configuring web servers to serve uploaded files with a Content-Disposition header set to attachment and enforcing correct Content-Type headers can mitigate the risk of unintended execution in client browsers.