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.

Affected: Packagist: maatwebsite/excel

### Summary

`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.

### Details

`Maatwebsite\Excel\Files\Disk::copy()` contained two paths:

```php 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:

* the destination could be any existing file the PHP process can write, in or out of the disk root; * the stream was opened `'rb+'`, which does not truncate, so a shorter ex…