Overview
A stored cross-site scripting (XSS) vulnerability, tracked as CVE-2026-103305, has been disclosed in Prenotazioni, a WordPress booking/reservation plugin. Versions through 1.7.5 save plugin settings without any authorization check or CSRF protection, and fail to escape some of those settings when they're later rendered — allowing an unauthenticated attacker to perform stored XSS attacks against both site administrators and ordinary visitors.
The exploit path requires some user interaction (getting a logged-in user to trigger the forged settings-save request), but no credentials of the attacker's own — a combination WPScan classifies as "easy" to exploit.
Technical Details
| Field | Value |
|---|---|
| CVE ID | CVE-2026-103305 |
| CWE | CWE-79 (Cross-Site Scripting) and CWE-352 (Cross-Site Request Forgery) |
| Attack Vector | Network |
| Authentication | None Required (attacker side) |
| User Interaction | Required (victim must be lured into triggering the forged request) |
| Affected Versions | Prenotazioni 1.7.0 through 1.7.5 |
| Fixed Version | Not published at time of writing — see Mitigation |
| Assigner | WPScan |
How It Works
Prenotazioni's settings-save routine has two independent gaps that combine into one vulnerability:
- No authorization or CSRF check — the handler that persists plugin settings doesn't verify the requester holds the right capability, nor does it validate a WordPress nonce confirming the request originated from the plugin's own admin form.
- No output escaping — when those settings are later rendered on the frontend or in the admin dashboard, some fields are printed without HTML-escaping.
Because the save endpoint has no CSRF protection, an attacker can craft a malicious page that silently submits a forged settings-update request. If a logged-in user — ideally an administrator — visits that page, their browser sends the forged request with their authenticated session, and the attacker's injected <script> payload is written into the plugin's stored settings. The next time anyone views the page where that setting is rendered, the unescaped payload executes in their browser.
Impact Assessment
| Impact Area | Description |
|---|---|
| Confidentiality | Medium — stored XSS can exfiltrate session cookies or admin nonces when rendered in an authenticated context |
| Integrity | Medium — a successful payload can modify page content, redirect visitors, or chain into further account compromise |
| Availability | Low — this flaw alone does not directly disrupt site availability |
| Exploitation Barrier | Requires a logged-in user to visit an attacker-controlled page while authenticated to the target site |
Who Is At Risk
- Sites running Prenotazioni through 1.7.5 with the plugin's settings pages reachable
- Site administrators who browse the open web while remaining logged into their WordPress dashboard in the same browser session
Mitigation
Immediate Actions
- No patched release has been published as of this writing. Until one lands, treat the plugin's settings pages as untrusted and limit who has access to them.
- Deploy a WAF rule to strip or block
<script>and other HTML-tag payloads submitted to the plugin's settings-save endpoint. - As a general hygiene measure, avoid browsing the open web in the same browser session used for WordPress administration.
Detection Opportunities
- Review Prenotazioni's stored settings for unexpected HTML or
<script>tags that weren't entered through normal administrative use. - Monitor for settings-save requests to the plugin that don't carry a valid WordPress nonce, where server-side logging permits.
Defence-in-Depth
- Enable a browser extension or WAF-level XSS filter as a secondary layer, since this relies on the browser or network layer catching what the plugin itself does not.
- Keep administrator sessions short-lived (short cookie/session timeouts) to reduce the window during which a forged CSRF request could succeed.
Key Takeaways
- CVE-2026-103305 affects Prenotazioni through 1.7.5, combining missing CSRF protection with missing output escaping to produce stored XSS.
- No attacker authentication is required, but exploitation depends on a logged-in user triggering the forged request.
- No fix is available yet — track the plugin's changelog and consider restricting access to its settings pages in the meantime.