CVE-2026-84374

### 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 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 r