CVE-2026-90932 in LaraDashboard
Summary
by MITRE • 09/14/2026
LaraDashboard versions 0.9.2 through 1.2.2 contain a path traversal vulnerability in the core-upgrade backup handling. CoreUpgradeController and BackupService (e.g. BackupService::deleteBackup()) concatenate the user-supplied backup_file/filename value directly onto the backup directory path without normalisation, without applying basename(), and without verifying that the resolved path remains inside storage/app/core-backups; the corresponding form requests only validate the value as a bounded string. An authenticated user holding only the delegated settings.edit permission (not Superadmin) can supply ../ traversal sequences to delete arbitrary files reachable on the host filesystem, including outside the application tree, or to restore a ZIP archive from an arbitrary on-disk location, writing arbitrary files into the application directories and achieving remote code execution. Note: the advisory states the vulnerable concatenation was introduced in the v0.9.7 release line. No patched version was available at the time of publication.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified in LaraDashboard versions 0.9.2 through 1.2.2 represents a critical path traversal flaw within the core-upgrade backup handling mechanism, specifically affecting the CoreUpgradeController and BackupService classes. This security defect was introduced during the v0.9.7 release line and persists through version 1.2.2 due to insufficient input validation and improper path normalization logic. The root cause lies in how these components handle user-supplied filenames for backup operations. Instead of sanitizing or normalizing the provided filename, the application directly concatenates the untrusted input onto a base directory path using standard string manipulation without verifying that the resulting absolute path remains within the intended storage boundaries. This lack of normalization allows an attacker to manipulate file system navigation sequences to escape the designated sandboxed environment.
From a technical perspective, the vulnerability manifests primarily in functions such as BackupService::deleteBackup(), where the application accepts a backup_file or filename parameter from HTTP requests. The corresponding form request handlers only validate this input as a bounded string, checking for length constraints but failing to inspect the content for directory traversal characters like ../. By omitting calls to basename() and neglecting checks against path canonicalization libraries, the software fails to ensure that the resolved file path is strictly contained within the storage/app/core-backups directory. This architectural oversight creates a classic insecure direct object reference scenario where user input directly influences system resource access without adequate boundary enforcement mechanisms in place.
The operational impact of this vulnerability is severe due to its potential for privilege escalation and remote code execution. Although exploitation requires authentication, the required permission level is relatively low; an attacker needs only the delegated settings.edit role rather than full Superadmin privileges. This lower barrier to entry significantly increases the attack surface by allowing less privileged users to exploit the flaw. Once authenticated with this minimal access, a malicious actor can supply carefully crafted path traversal sequences in the filename parameter. In the context of backup deletion, this enables the arbitrary deletion of files anywhere on the host filesystem that is accessible to the web server process, potentially leading to denial of service or data loss by removing critical system or application files outside the intended directory structure.
Furthermore, the vulnerability extends beyond simple file deletion into active code execution capabilities through the restore functionality. An attacker can supply a path pointing to an arbitrary ZIP archive located on the host filesystem rather than within the allowed backup directory. When the application processes this request, it extracts the contents of that external archive directly into the application directories. By pre-placing a malicious PHP script or other executable payload in a location accessible by the web server and referencing it via path traversal, an attacker can force the application to write arbitrary code into writable directories within the LaraDashboard installation. This effectively results in remote code execution, granting the attacker full control over the underlying system with the privileges of the web service account.
This vulnerability aligns closely with CWE-22: Improper Limitation of a Pathname to a Restricted Directory and CWE-94: Improper Control of Generation of Code (Code Injection). In terms of offensive security frameworks, it maps to ATT&CK technique T1059 Command and Scripting Interpreter for execution via file upload or extraction. The lack of input sanitization also reflects weaknesses associated with CWE-20: Improper Input Validation. To mitigate this risk, developers must implement strict path normalization using canonicalization functions before any filesystem operations are performed. It is essential to verify that the resolved absolute path starts with the expected base directory prefix after all symbolic links and relative paths have been resolved. Additionally, implementing allowlists for permitted file extensions and restricting backup storage locations through operating system-level permissions can provide defense-in-depth measures against such traversal attacks until a patched version becomes available.