Packagist · maatwebsite/excel
Laravel Excel writes exports outside the configured filesystem disk when given a caller-controlled path
Excel::store() resolved the destination path against the process working
directory rather than the configured filesystem disk. When that path resolved to
an existing file, the export was written straight to it with fopen(),
bypassing the disk entirely. An application that passes a user-controlled value
as the export path could therefore be made to overwrite an arbitrary existing
file that the PHP process can write to, with content the user controls.
Maatwebsite\Excel\Files\Disk::copy() contained two paths:
if (realpath($destination)) {
$tempStream = fopen($destination, 'rb+');
$success = stream_copy_to_stream($readStream, $tempStream) !== false;
} else {
$success = $this->put($destination, $readStream);
}
$destination is the $filePath argument given to Excel::store(),
$export->store() or ->storeExcel(). realpath() resolves it against the
current working directory — public/ for a typical web request — not
against the disk root. On a hit, the write went directly to the filesystem and
never reached Flysystem, which would otherwise have rejected ../ traversal and
confined absolute paths to the disk root. The disk argument was effectively
ignored for those paths, including for remote disks such as S3.
Two consequences follow:
'rb+', which does not truncate, so a shorter export
left trailing bytes of the previous file behind.Because the file must already exist, the primitive is an overwrite rather
than an arbitrary file creation. Overwriting a PHP file that is reachable by the
web server (for example a front controller or a cached view) turns
attacker-controlled row content into code execution, since CSV and HTML writers
emit cell values verbatim. Passing an explicit writer type to store() bypasses
the extension-based type detection that would otherwise reject a .php target.
Exploitation requires the application to pass an unsanitized, user-controlled value as the export path. Applications that pass a fixed or server-derived path are not affected.
Arbitrary overwrite of existing files writable by the PHP process, with partially attacker-controlled content, leading to remote code execution where the overwritten file is executed by the web server.
Fixed in 3.1.70. Disk::copy() now always writes through the configured
filesystem disk, so Flysystem enforces the disk root for every export.
Note the behaviour change: passing an absolute path to store() previously
wrote to that path once the file existed. Paths now always resolve relative to
the disk root. Applications that relied on that should configure a disk rooted
at the target location.
For anyone unable to upgrade, validate the path before passing it to store() —
reject absolute paths and any .. segment, or derive the filename server-side
and never build it from request input:
$name = basename($request->input('filename')); // strips any directory part
Excel::store($export, 'exports/' . $name, 'local');
Reported responsibly by @seck19 via the contact address in SECURITY.md.
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.