CVE-2026-84374 in Laravel Excel
Summary
by MITRE • 09/01/2026
Laravel Excel provides supercharged Excel exports and imports in Laravel. From 3.1.8 until 3.1.70, in src/Files/Disk.php the Maatwebsite\Excel\Files\Disk::copy() method resolves the caller-controlled $destination supplied through Excel::store(), $export->store(), or storeExcel() against the process working directory with realpath() instead of the configured filesystem disk. If the path names an existing writable file, Disk::copy() opens it with fopen() in rb+ mode and uses stream_copy_to_stream(), bypassing Flysystem path confinement and allowing an attacker whose application input controls the export path to overwrite arbitrary existing files with export content. The rb+ behavior creates a non-truncating overwrite and trailing bytes when the new export is shorter, and overwriting an executable PHP file can lead to remote code execution. This issue is fixed in version 3.1.70.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified within Laravel Excel versions ranging from 3.1.8 through 3.1.70 represents a critical path traversal and arbitrary file write flaw rooted in the improper handling of filesystem paths during export operations. The core technical deficiency resides in the Maatwebsite\Excel\Files\Disk::copy() method, which is responsible for writing exported data to disk. When an application utilizes methods such as Excel::store(), $export->store(), or storeExcel() to initiate a file operation, it passes a destination path parameter that is ultimately controlled by user input. Instead of resolving this path against the configured filesystem disk root directory using Flysystem's confinement mechanisms, the vulnerable implementation resolves the path relative to the process working directory via realpath(). This deviation from secure defaults effectively bypasses the intended sandboxing and isolation provided by the underlying storage abstraction layer, allowing an attacker who can influence the export destination path to target files outside of the expected application directories.
The operational impact of this flaw is severe due to the specific file handling mode employed during the write operation. The vulnerable code opens the targeted file using fopen() with rb+ permissions and subsequently utilizes stream_copy_to_stream() to transfer data. This approach results in a non-truncating overwrite, meaning that if the exported content is shorter than the existing file's size, trailing bytes from the original file remain intact at the end of the new content. While this behavior alone can lead to data corruption or unexpected application states depending on the target file type, the primary risk arises when an attacker targets executable files such as PHP scripts. By overwriting a web-accessible PHP file with malicious export content that includes injected code, an attacker achieves remote code execution on the server. This capability allows for complete compromise of the underlying system, including access to sensitive data, lateral movement within the network, and persistence mechanisms.
From a classification perspective, this vulnerability aligns closely with CWE-22: Improper Limitation of a Pathname to a Restricted Directory, as it involves path traversal leading to unauthorized file writes outside intended boundaries. Furthermore, the exploitation technique corresponds to CWE-94: Improper Control of Generation of Code (Code Injection), specifically through server-side code injection via arbitrary file write. In terms of adversary tactics, this aligns with MITRE ATT&CK techniques such as T1059 Command and Scripting Interpreter for executing injected payloads, and potentially T1105 Ingress Tool Transfer if the exported content is used to stage additional malware. The failure to validate or sanitize user-supplied paths against a strict allowlist of allowed directories constitutes a fundamental input validation error that undermines the security model of the application framework.
Mitigation strategies for this vulnerability are straightforward and primarily involve upgrading the Laravel Excel package to version 3.1.70 or later, where the path resolution logic has been corrected to respect filesystem disk configurations rather than relying on relative working directory paths. For organizations unable to immediately patch due to dependency constraints, temporary mitigations should focus on strict input validation of any parameters passed to export functions. Developers must ensure that destination paths are validated against a whitelist of allowed directories and filenames, rejecting any path components that attempt to traverse upward using dot-dot sequences or absolute path indicators. Additionally, implementing file upload restrictions at the web server level can provide an additional layer of defense by preventing execution of files in directories where exports might inadvertently land, although this is not a substitute for fixing the root cause within the application code.