CVSS v4.0 6.9 puts CVE-2026-11960 in the medium range. That score fits a flaw that leaks account existence but does not directly bypass authentication. Risk management still needs to ask how useful that leak is to a specific attacker. For FacturaScripts 2025.61, the answer can change the priority of an internet-facing finance portal.
INCIBE published the advisory on October 20, 2026, identifies version 2025.61 as affected, and lists no observed exploitation. The source describes differences in response timing, error messages and HTTP status when a login uses a valid username versus an invalid one.
Reading the score in context
The advisory gives the vulnerability a medium rating. The leak is unauthenticated in the sense that a visitor can test usernames without a valid account. The advisory's exploitability table separately marks exploitation as "No," meaning no observed exploitation was reported.
A score cannot describe the value of every asset. An isolated development instance with no real users has little account-discovery value. A public accounting portal with administrative accounts, customer records and weak rate limits has a more consequential exposure. The second case deserves a faster validation even though both run the same code.
What the attacker actually gains
A confirmed username is a targeting input. It helps an attacker decide which names to use in password spraying, brute force, credential stuffing or social engineering. INCIBE lists those outcomes as possible consequences, not as events that already occurred.
The vulnerability does not create a reusable password, grant a session or expose invoice data. Account takeover requires a later success. Phishing requires a person to respond. Credential stuffing requires a password that matches the FacturaScripts account. Risk owners should separate the information leak from the eventual impact so that detection and response can test each link in the chain.
Affected scope and evidence quality
The advisory names FacturaScripts 2025.61. It does not provide a full version matrix, so other releases need a source check against commit ac32f1e2f5ca8b16b5c8f023a3d8824faa693155. That commit introduces generic failure messages and a dummy bcrypt password check for missing users.
The source evidence is specific enough for triage: the product and version are named, the CNA assigns a score, and the upstream diff shows the fix. The absence of a public exploit is not a guarantee that no attacker has tested the behavior. It is a reason not to label the environment compromised without evidence.
On October 29, 2026 in Beijing time, ZoomEye returned 104 product matches for title="FacturaScripts". The CVE query vul.cve="CVE-2026-11960" returned zero. The first result describes a visible product fingerprint; the second says the CVE field produced no indexed matches. Neither result confirms a vulnerable deployment.
ZoomEye FacturaScripts product search
A defensible risk decision
Use four questions for each deployment. Is it reachable by untrusted clients? Does it expose the login or password-change flow? Does it run FacturaScripts 2025.61 without the upstream fix? Does it lack compensating controls such as rate limiting, multi-factor authentication and authentication monitoring?
A public system with all four conditions should be treated as a higher operational priority than the medium score alone suggests. A closed internal deployment with verified patch provenance can be evaluated lower. These are risk decisions, not claims that the vulnerability becomes high severity or that compromise is certain.
If the system is internet-facing but patching is delayed, restrict access to expected networks and add edge rate limits. Monitor for account-name sweeps followed by password attempts. Those steps reduce the ability to turn an enumeration result into a successful login, but the source fix remains the direct remediation.
Closure criteria
Record the package version and source provenance. Confirm the updated login, password-change and two-factor failure paths produce neutral responses. Test a nonexistent name, a disabled account and a valid account with an incorrect password under controlled conditions. Preserve the date and result so later reviewers can reproduce the decision.
Do not close the issue solely because a public exploit is absent. Do not reopen it solely because a scanner shows a product fingerprint. The correct evidence sits between those extremes: an affected version, a reachable authentication surface and a response difference, followed by a verified change.