| Package | Affected versions | Patched versions |
|---|---|---|
| facturascripts/facturascripts | ≤ 2025.92 |
A stored Cross-Site Scripting (XSS) vulnerability exists in the product search modal of sales and purchases documents. An authenticated user with access to the warehouse module can create a product with a malicious reference that executes arbitrary JavaScript in the browser of any other user who opens the product search modal inside an invoice, order, or delivery note.
Core/Lib/AjaxForms/SalesModalHTML.phpCore/Lib/AjaxForms/PurchasesModalHTML.phpThe referencia field of a product variant is injected directly into an HTML onclick attribute string without JavaScript context escaping:
// SalesModalHTML.php ~line 102
$tbody .= '<tr onclick="return salesFormAction(\'add-product\', \''
. $row['referencia'] // no htmlspecialchars() applied
. '\');">';
When a product is saved, noHtml() encodes ' → '. This appears safe in static HTML context. However, the modal HTML is later returned as a JSON response and inserted into the DOM via innerHTML:
// SalesDocument.html.twig line 118
document.getElementById("findProductList").innerHTML = data.products;
The browser HTML parser decodes ' → ' during the innerHTML assignment, breaking out of the JavaScript string literal in the onclick attribute and executing the injected code.
Attack payload stored in database: x'+alert(1)+'
Resulting onclick after innerHTML decode:
return salesFormAction('add-product', 'x'+alert(1)+'')
// ^^^^^^^^^^ executes before the function call
Step 1 — Inject the payload
/EditProducto and create a new product with the following values:| Field | Value |
|---|---|
| Reference | x'+alert(1)+' |
| Description | test |
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeStep 2 — Trigger the XSS
/EditFacturaCliente?codcliente=<customer_code>alert(1)Although session cookies (fsLogkey, fsNick) have the HttpOnly flag set and cannot be read directly via document.cookie, the injected script runs in the victim's authenticated browser context, meaning the attacker can make arbitrary authenticated requests on their behalf, create new admin users via AJAX POST to /EditUser, exfiltrate any business data visible in the DOM, or redirect the user to an external site. The most critical scenario is privilege escalation: a low-privilege employee with only warehouse
access can execute JavaScript in an administrator's session without knowing their password.
Apply htmlspecialchars() with ENT_QUOTES before inserting referencia into the onclick attribute in both affected files.
Core/Lib/AjaxForms/SalesModalHTML.php
// Before (vulnerable):
$tbody .= '<tr onclick="return salesFormAction(\'add-product\', \''
. $row['referencia']
. '\');">';
// After (safe):
$tbody .= '<tr onclick="return salesFormAction(\'add-product\', \''
. htmlspecialchars($row['referencia'], ENT_QUOTES, 'UTF-8')
. '\');">';
Core/Lib/AjaxForms/PurchasesModalHTML.php
Apply the same change to the equivalent line.
Why ENT_QUOTES is required: ENT_QUOTES encodes both " and ' characters. This ensures that ' is stored as ' and — critically — remains ' after innerHTML assignment, because htmlspecialchars produces a form that the HTML parser does not decode back into a raw quote inside a JS string context.
Alternative mitigation: replace innerHTML with innerText or a DOM-based rendering approach that never parses injected strings as HTML. This would eliminate the entire class of HTML-injection-via-innerHTML vulnerabilities in the sales and purchases
forms.
Omar Ramirez