Please report security vulnerabilities privately using GitHub's Report a vulnerability button. Do not open public issues for security matters.

Please include the affected version, the steps to reproduce, a proof-of-concept and the impact you were able to demonstrate.

We aim to acknowledge reports within 5 business days.

Only the latest stable release of FacturaScripts receives security fixes.

• Vulnerabilities exploitable by an unauthenticated attacker.
• Vulnerabilities that allow a low-privilege authenticated user (e.g. a regular employee role) to gain privileges they should not have, access other users' data, or compromise the server.
• Vulnerabilities that let an attacker act through another user's session, including an administrator's, such as CSRF or XSS targeting them.
• SQL injection, stored or reflected XSS affecting other users, authentication bypass, CSRF on state-changing endpoints, insecure direct object references, path traversal reachable without admin privilege, and similar.

The following are not considered vulnerabilities and reports will be closed without action:

1. Administrator-to-RCE via the plugin system. Administrators can install plugins, and plugins contain PHP code that executes inside FacturaScripts. This is the documented, intentional purpose of the plugin system — it is not a privilege escalation, because the attacker must already be an administrator (the highest privilege inside the application). This mirrors the behavior of WordPress, PrestaShop, Magento, Moodle, Drupal, Joomla and essentially every extensible PHP application. Protect the administrator account; do not expect the application to restrict what administrators can do.

2. Any finding whose PoC requires the attacker to already have an administrator account, including but not limited to: installing or uploading plugins, editing settings, importing data, or using any other page restricted to administrators, or an API key that an administrator made administrator-equivalent (see API keys below). This does not cover attacks in which the administrator is the victim (see In scope), nor non-administrator users who were granted access to a page through their role.

3. Self-XSS (the attacker injects a payload into their own session).

4. Vulnerabilities caused by server misconfiguration, such as running PHP-FPM/Apache/nginx as root, world-writable directories, missing TLS, or exposing .git/ publicly. These are deployment issues, not application issues.

5. Missing security headers, cookie flags, or best-practice hardening without a demonstrated exploit.

6. Clickjacking on pages without sensitive state-changing actions.

7. Denial of service via resource exhaustion, large payloads, or regex complexity, unless a clearly disproportionate amplification is shown.

8. Vulnerabilities in third-party dependencies — please report those to the upstream project. We track advisories via Composer and update dependencies on release. If the vulnerable code is reachable through FacturaScripts by a non-administrator, report it to us as well.

9. Reports generated by automated scanners without a working proof-of-concept demonstrating real impact.

10. Social engineering, physical attacks, and attacks against FacturaScripts infrastructure (our hosting, email, accounts).

This is the most frequently reported non-issue. Please read it before reporting anything about the REST API (/api/3/...).

• API keys are not users and do not inherit any user's permissions. A key can do exactly what an administrator granted it: full access, or GET/POST/PUT/DELETE on specific resources.
• Only administrators can create, edit or grant access to API keys.
• A key with full access, or with write access to users, apikeys or apiaccess, is administrator-equivalent by design. Using such a key to set admin, change passwords, enable or disable users, or grant itself more access is not privilege escalation, and neither is mass assignment through it.
• A 403 on some other resource does not make a key "low-privilege" for the resources it was granted.

API findings are in scope when they bypass these grants: a key reaching a resource or method it was not granted, reading fields the API hides, or affecting data outside the resource it can access.

Researchers who report valid, in-scope vulnerabilities will be credited in the release notes of the fixed version, unless they prefer to remain anonymous.