GHSA-cv65-7cg8-r623

Summary

The static file controllers in FacturaScripts decide whether a request is authorized by looking at the URL string instead of the canonical filesystem path. A request that starts with an allow-listed folder name but contains a ../ segment in the middle ends up serving a file from a different directory than the one the URL pretended to point at. This makes any file inside the FacturaScripts installation readable without authentication as long as the file's extension is on the controllers' allow-list (pdf, xlsx, docx, csv, sql, zip, xml, json, xsig, etc.). In practice this leaks the documents the application is specifically designed to protect: customer invoices, supplier invoices, document attachments and database backups stored under MyFiles/Private/ and other non-public subfolders.

The two vulnerable controllers are Core/Controller/Files.php (used by the /Plugins/*, /Core/Assets/*, /Dinamic/Assets/* and /node_modules/* routes) and Core/Controller/Myfiles.php (used by /MyFiles/*). Both share the same root cause: a strpos() / substr() prefix check on the raw URL is treated as proof that the resolved file lives inside an authorized directory.

The /Plugins/* route via Files.php is the cleanest exploit path because Plugins/ is part of every FacturaScripts installation, so no precondition is required. The /MyFiles/* route via Myfiles.php is a second path with the same root cause: when the URL starts with /MyFiles/Public/, the controller exits early and skips the per-file myft token check, which can be combined with ../ to read tokenless files outside Public/.

Tested live on commit de01369 (master, 2026-05-11) and on tag v2026.2, with PHP 8.0.30 on Apache 2.4.56.

Details

Path 1, in Core/Controller/Files.php

Files::__construct concatenates the project folder with the request URL and then runs two safety checks before serving the file:

$this->filePath = Tools::folder() ....