Stored XSS in CoverManager
We identified a persistent Cross-Site Scripting (XSS) vulnerability in CoverManager, the booking platform used by thousands of restaurants in Spain and beyond. We worked with the vendor through to the fix and published the advisory in coordination with INCIBE-CERT.
Advisory facts
- CVSS v4.0
- 5.3
- CWE
- CWE-79
- Severity
- Medium
- Vendor
- CoverManager
- Product
- CoverManager (software de reservas)
- Affected versions
- Versiones anteriores al parche del fabricante (2025)
- Fix
- Versión actualizada por CoverManager tras coordinación con INCIBE-CERT
- Status
- Parcheada
- Discovered by
- Javier Paradelo
- NVD published
- 2025-05-26
- Vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N
Quick summary
An unauthenticated remote attacker could inject JavaScript that persisted inside CoverManager and ran in the browser of any user who later opened the affected page (including restaurant staff with elevated privileges). The vendor shipped the fix and the case was tracked at NVD and INCIBE-CERT under identifier INCIBE-2025-0267.
Why this matters
CoverManager handles reservations for thousands of restaurants and, by extension, personal data about their guests (name, phone number, email, allergy notes, special requests). A stored XSS on a system like that is not a theoretical concern: any injected payload is then served to every employee or guest who loads the affected page.
Real-world impact depends on where the payload lands. On an internal restaurant panel, hijacking the manager's session unlocks the full guest list, the ability to alter reservations, or to export data. On a public-facing widget, the script runs in the end customer's browser. Either way it is a GDPR matter, because the data exposed is personal data.
What sets stored XSS apart from a classic reflected XSS is persistence. The attacker doesn't need to trick anyone into clicking a suspicious link: the normal product page, accessed from a bookmark or from the staff's daily workflow, already delivers the payload. Detection from the defensive side is harder because the behaviour looks legitimate.
Technical detail
The flaw maps to CWE-79 (Improper Neutralization of Input During Web Page Generation). An attacker-controlled input was stored in the product's database and returned without sanitisation when later pages were rendered, allowing arbitrary JavaScript execution in the CoverManager domain context.
Under our coordinated disclosure policy we don't publish the exact parameter, the endpoint, or a reproducible payload while there may still be unpatched deployments. What we can say is that the exploitation flow did not require attacker authentication, but did require victim interaction (loading the affected page). That is reflected in the CVSS:4.0 vector with AT:N (no attack conditions), PR:N (no privileges) and UI:P (passive interaction).
Confidentiality and integrity impact on the vulnerable product itself are null (VC:N, VI:N), but the impact on the subsequent system (the victim loading the page) is low in both confidentiality and integrity (SC:L, SI:L). That is the typical signature of modern stored XSS under CVSS v4.0: the real damage is downstream, inside the user's browser.
Reading the CVSS vector
A nominal score of 5.3 hides nuance. These are the components that weigh the most and why.
AV:N (Network)Remote attacker
The payload is delivered over the network. No physical access or LAN foothold required.
PR:N (None)No prior auth
Whoever drops the malicious content does not need a valid CoverManager account to plant the payload.
UI:P (Passive)Passive interaction
The victim only needs to open the affected page during normal use. No active deception (clicking a weird link) required.
SC:L · SI:LSubsequent system impact
Damage is shifted to the victim's browser: cookies, tokens, data rendered on the page.
Disclosure timeline
Q1 2025
The Secra team identifies the vulnerability during an internal research session.
Q1 2025
Detailed report sent to the vendor through their official channel.
Q2 2025
CoverManager confirms the finding and ships the fix.
May 26, 2025
Coordinated advisory publication on NVD (CVE-2025-40652) and INCIBE-CERT (INCIBE-2025-0267).
Mitigation and recommendations
The vendor patch closes the specific case. If your restaurant or hospitality group uses CoverManager, just confirm that the platform serves a version that includes the fix from advisory INCIBE-2025-0267 (since it is a SaaS, most tenants are already on the patched version transparently).
If you build a comparable product, the structural defences against stored XSS are still the ones we have been recommending for years: contextual encoding at render time (not only at input), strict Content Security Policy with nonces or hashes, and targeted review of every point where content moves from a database row into HTML returned to the client.
Closing checklist
- 1Confirm with CoverManager that your tenant is on a patched version (reference INCIBE-2025-0267).
- 2Review activity logs for unusual behaviour on restaurant manager accounts during the last 30 days.
- 3If you maintain code for a similar product, audit output encoding at every render point handling user content.
- 4Harden CSP: block inline scripts without a nonce, restrict load origins.
- 5Publish a clear responsible disclosure process (security.txt, /security page) so that researchers like our team can report findings without friction.
What this means if your business runs on SaaS
When you depend on a SaaS to process personal data, part of your attack surface is operated by the vendor. But the regulatory accountability stays with you: in front of the data protection authority, you are still the data controller even if the technical fault sits with the provider. That is why we recommend periodic security reviews of critical providers, especially those touching personal or financial data.
For internal pieces (your own booking site, your mobile app, your customer portal) the pattern flips: the code is yours, and the audit has to dig into every vector in detail. That is exactly what we cover in our web and mobile audit service under OWASP Top 10 and MASVS, with a focus on bugs like this stored XSS but also IDOR, SSRF, deserialisation and the full OWASP API Top 10 family.
About the researcher
The finding is signed by Javier Paradelo, CEO and co-founder of Secra Solutions, certified OSCP, OSEP, OSWE and CRTO. Javier leads the firm's web audit and red team practice and runs an internal research programme where the team dedicates time to widely deployed products in the Spanish market.
Meet the Secra teamWould your platform survive an audit like this one?
Audit your applications with the team that signs NVD-tracked advisories. OWASP Top 10, OWASP API Top 10 and OWASP MASVS coverage, with a proof of concept and a prioritised remediation plan for every finding.