CVE-2026-84374: Laravel Excel writes exports outside the configured filesystem disk when given a caller-controlled path
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 streamcopytostream(), 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Maatwebsite\Excelto a version that resolves this vulnerability.Fixed in 3.1.70
Event History
Frequently Asked Questions
Which applications are realistically exposed?
Applications using Maatwebsite\Excel versions 3.1.8 through 3.1.69 are exposed if untrusted application input can influence the destination path passed to Excel::store(), $export->store(), or storeExcel(). The issue affects writes to existing files that are writable by the application process.
What does an attacker need to exploit this?
An attacker needs low-privileged access to an application feature that lets them control, directly or indirectly, an export destination path. The target file must already exist and be writable by the process running the application.
Are default filesystem-disk restrictions sufficient protection?
No. The vulnerable Disk::copy() behavior resolves the supplied destination against the process working directory rather than the configured filesystem disk, bypassing Flysystem path confinement.
What can be done before upgrading?
Ensure export destination paths are not derived from user-controlled input and restrict them to application-generated filenames within an intended export location. Also limit the application process's write permissions, especially for PHP or other executable files.
How can I identify potentially affected code?
Review uses of Excel::store(), $export->store(), and storeExcel() for destination paths influenced by request parameters, user profile data, imported values, or other untrusted input. Check whether the application runs a version from 3.1.8 through 3.1.69; version 3.1.70 fixes the issue.