Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.2",
  "pubDate": "2026-09-14T13:19:31.523Z",
  "pubdate": "2026-09-14T13:19:31.523Z",
  "executiveSummary": "LaraDashboard, spanning versions 0.9.2 through 1.2.2, is susceptible to a critical path traversal vulnerability within its core-upgrade backup management functionality.\nThe vulnerability arises due to improper input validation and insufficient sanitization of user-supplied filenames in the BackupService and CoreUpgradeController components.\nAn attacker possessing the delegated settings.edit permission can exploit this flaw to manipulate file system operations, allowing for the deletion of arbitrary files on the host or the restoration of malicious ZIP archives.\nThis impact extends beyond the application directory, potentially facilitating Remote Code Execution (RCE) by overwriting sensitive system files or application logic with attacker-controlled content.\nThe core of the issue lies in the direct concatenation of unvalidated user input to backend file paths, bypassing directory constraints and security boundaries.\nThis vulnerability poses a severe risk to the integrity and availability of the hosting environment, as it allows non-administrative users to exceed their intended privilege scope.\nExploitation requires authenticated access to the application with specific delegated permissions, after which the attacker can interact with file system paths using standard traversal sequences such as '../'.",
  "technicalDetails": "The vulnerability originates from a failure to perform input normalization or path sanitization within the core-upgrade backup handling workflow, specifically identified in CoreUpgradeController and BackupService::deleteBackup().\nIn the affected versions, the application logic takes a user-supplied string (backup_file/filename) and directly appends it to the base directory path defined for backups, typically 'storage/app/core-backups'.\nBecause the application does not utilize functions like basename() to strip directory traversal sequences, or perform path resolution checks to verify that the final path remains confined within the designated directory, the filesystem API treats the entire concatenated string as a legitimate path.\nThe vulnerability was introduced in the v0.9.7 release line. While the application's form requests perform validation to ensure the input is a bounded string, this validation is insufficient as it fails to inspect the character content for path traversal sequences like '../'.\nAn authenticated user with settings.edit permissions can leverage this logic to achieve two primary attack vectors. First, by supplying crafted strings, the user can trigger delete operations on files located outside the 'storage/app/core-backups' directory, enabling arbitrary file deletion and potential service disruption.\nSecond, the vulnerability allows for the restoration of arbitrary ZIP archives. By pointing the restoration service to a ZIP file located elsewhere on the filesystem or an attacker-controlled location, the application will extract the contents into the application's core directories.\nBy overwriting existing application files (e.g., PHP controller files or configuration files) with malicious payloads contained within the ZIP archive, an attacker can achieve Remote Code Execution (RCE) within the context of the web server user.\nThe attack flow involves: 1) Authenticating with the required settings.edit privilege; 2) Intercepting or crafting a request to the backup management endpoint; 3) Injecting directory traversal sequences into the filename parameter; 4) Triggering the BackupService to perform a delete or restore operation on the targeted path.\nBecause the application runs with the privileges of the web server, the post-exploitation impact includes full control over the application's source code, access to environment variables, and the potential to escalate privileges or move laterally if the server is improperly configured."
}