FacturaScripts EUVD-2026-104834

Exploitation requires only network reachability to the FacturaScripts login interface, which must exhibit observable differences in response time, error messages, or HTTP status codes between valid and invalid usernames - this is the specific triggering condition and is present in default behavior per the description. The description states the attacker is unauthenticated and requires no user interaction, which directly contradicts the input CVSS vector's PR:L and UI:P. Limiting factors: the flaw only discloses valid usernames and does not itself provide authentication, access, or code execution; its practical impact is capped where the instance enforces account lockout/rate limiting, strong password policy, and multi-factor authentication, and where the login portal is not exposed to untrusted networks.

This is a low-to-moderate real-world risk information-disclosure issue, not a critical priority. The vulnerability is a username enumeration weakness in FacturaScripts 2025.61 where the login endpoint returns distinguishable responses (timing, error messages, or HTTP status codes) for valid versus invalid usernames. Signal comparison reveals conflicts that must be flagged: the provided CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:N/VA:N) scores 6.9 and encodes PR:L (authenticated) plus UI:P (user interaction) and VC:H (high confidentiality) - this does NOT match the description, which explicitly describes an UNAUTHENTICATED attacker systematically probing the login form with NO user interaction and only leaking usernames (low confidentiality). The CVSS vector appears to have been copied from a different finding in the same multi-vulnerability advisory (likely the XSS issue implied by the CWE-79/XSS tag) rather than describing this enumeration flaw - verify with vendor. No EPSS score was provided; KEV=NO and no POC is referenced, so there is no evidence of active exploitation. Crucially, this is a precursor/enabler weakness: it does not grant access by itself but feeds targeted brute-force, password spraying, credential stuffing, and social-engineering campaigns. Real priority is therefore modest and depends heavily on whether the deployment enforces strong password policies, rate limiting, and MFA.

An unauthenticated attacker scripts repeated login attempts against a public-facing FacturaScripts instance, submitting a wordlist of candidate usernames and measuring response time, error text, and HTTP status differences to determine which accounts exist. Having confirmed a list of valid usernames (e.g., administrators or accountants), the attacker launches a password-spraying campaign against only those real accounts, significantly improving efficiency over blind guessing. No public exploit code is referenced, but the technique is trivial to automate with standard tooling.