CVE-2026-84374

Laravel Excel's export methods (Excel::store(), $export->store(), ->storeExcel()) resolved caller-supplied destination paths against the PHP process working directory instead of the configured filesystem disk, and when the path resolved to an already-existing file, the export was written directly via fopen(), bypassing Flysystem's containment checks. The flaw is triggered only when the application passes an unsanitized, user-controlled value as the export path, in which case attacker-influenced export content overwrites the targeted file (without truncation, leaving trailing bytes if the new content is shorter). An attacker gains an arbitrary overwrite of any existing file writable by the PHP process, and can achieve remote code execution when the overwritten file is executed by the web server, such as a PHP front controller or cached view, since CSV/HTML writers emit cell values verbatim. Affected are Laravel applications using maatwebsite/excel versions prior to 3.1.70 that pass user-controlled paths to exports; applications with fixed or server-derived paths are not affected. No public proof-of-concept, KEV listing, or confirmed in-the-wild exploitation is known (EPSS 0.6%).

What to do: Upgrade maatwebsite/excel to 3.1.70, which forces all writes through the configured filesystem disk so Flysystem enforces the disk root. If upgrading is not possible, validate and sanitize any user-controlled value before passing it as an export path (rejecting traversal sequences and absolute paths), and audit the codebase for store()/storeExcel() calls whose path argument derives from user input. Note the fix's behavior change: absolute paths previously wrote outside the disk once the file existed, so applications relying on that should configure a disk rooted at the target location.