CVE-2026-5513: Stored XSS in Bookly WordPress Plugin

What happened

CVE-2026-5513 is a stored cross-site scripting vulnerability in the Online Scheduling and Appointment Booking System – Bookly plugin for WordPress. According to the NVD description, the flaw affects versions up to and including 27.2 and is caused by insufficient input sanitization and output escaping of the bookly-customer-full-name cookie.

This matters because stored XSS is usually more serious than reflected XSS in day-to-day operations. If attacker-controlled JavaScript is stored and later rendered to another user, the payload can run in the victim’s browser in the context of the affected site. In a WordPress booking workflow, that can expose administrator sessions, alter page content, redirect users, or perform actions as the victim, depending on browser protections and user privileges.

A key condition limits exposure: exploitation requires the Bookly setting “Remember personal information in cookies” to be enabled. The NVD description states that this option is disabled by default. That does not eliminate risk, but it does change prioritization. Teams should assume that only installations where admins deliberately enabled this feature are directly exposed to the described attack path.

Affected versions and fixed version status

The affected product is the Online Scheduling and Appointment Booking System – Bookly plugin for WordPress, published under the Bookly name. The version range directly supported by the available source material is:

• Affected: <= 27.2
• Current version observed on WordPress.org: 27.7

The exact first fixed version number was not directly recoverable from the advisory sources available in this research session. The WordPress Trac changeset referenced by NVD returned HTTP 403 during retrieval, and the related Wordfence entry content was not available in a form that allowed confirmation of the patch boundary. Because of that, it would be inaccurate to state “fixed in 27.3” or any other specific version without direct evidence.

For defenders, the practical conclusion is still straightforward. If you run Bookly version 27.2 or earlier, treat the instance as vulnerable if the cookie-remembering feature is enabled. Because 27.7 is confirmed to be available on the WordPress plugin page, the safest guidance is to upgrade to the latest available release, rather than trying to target an unconfirmed minimum patch level.

Why this vulnerability matters

The vulnerability is notable for three reasons. First, it is unauthenticated. That lowers the barrier to exploitation because an attacker does not need a valid WordPress or Bookly account to supply the malicious data. Second, it is stored XSS, meaning the payload can persist long enough to affect multiple page views or users. Third, it targets a user-facing workflow that may be exposed on public websites, including SMB booking portals and service businesses.

That said, severity should be interpreted in context. The CVSS score is 7.2, which places it in the high-severity range, but the operational risk depends on whether the optional cookie-based memory feature is enabled. In many environments, admins do enable convenience features without revisiting their security implications, especially on marketing or appointment sites managed by small teams. So while the default configuration helps, it should not be assumed in asset inventories without verification.

Exploitation status

At the time of this write-up, exploitation in the wild is not confirmed from the retrieved sources. The CVE is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, which means there is no CISA confirmation of active exploitation and no associated federal remediation deadline.

Likewise, no public proof of concept (PoC) was confirmed from the source set used here, and no verified GitHub repository or primary-source exploitation write-up was identified during the session. That does not mean exploitation is impossible or unlikely. Stored XSS issues are often straightforward for capable attackers to reproduce once enough implementation detail is known.

In the absence of confirmed exploitation data, defenders should assume the following: if the plugin is internet-facing, the booking form is reachable, and the cookie persistence setting is enabled, this issue is likely reproducible by an attacker with modest web testing capability. That is enough to justify patching on normal change timelines, with accelerated action for high-traffic public sites or admin-heavy workflows.

How the bug works

The NVD description identifies the bookly-customer-full-name cookie as the attack surface. The root cause is a combination of insufficient input sanitization when handling attacker-controlled data and insufficient output escaping when rendering that data into a page later viewed by a user.

In practice, this means an attacker may be able to place JavaScript or HTML event-handler content into the cookie value, and if the plugin later reflects that value into a page without proper contextual escaping, the payload executes in the browser. The impact depends on where and how the value is rendered. If it appears on booking pages viewed by staff, receptionists, or admins, the attacker may gain access to session tokens, trigger unauthorized actions, or manipulate the appointment workflow.

Technical Notes

A simplified example of the dangerous pattern looks like this:

// Unsafe conceptual example
echo $_COOKIE['bookly-customer-full-name'];

A safer pattern would validate and escape output contextually:

// Safer conceptual example
$full_name = isset($_COOKIE['bookly-customer-full-name']) ? sanitize_text_field(wp_unslash($_COOKIE['bookly-customer-full-name'])) : '';
echo esc_html($full_name);

A browser-side test payload often used during validation would resemble this:

Cookie: bookly-customer-full-name="><script>alert(1)</script>

Do not run test payloads against production systems without authorization and change control. Use a staging environment first to verify whether the application stores and later renders the cookie value.

Operational guidance for admins and SMB teams

For most teams, this CVE does not demand incident-mode response unless you already see evidence of suspicious cookie values, odd redirects, unexpected admin actions, or user reports of browser pop-ups on booking pages. However, it should still be treated as a real internet-exposed web application issue because the vulnerability is unauthenticated and affects a public-facing business workflow.

If you manage multiple WordPress sites, prioritize by exposure. Patch internet-facing booking sites first, then lower-traffic or internal staging systems. Confirm whether the vulnerable feature is enabled, because that materially affects risk. If you cannot determine that quickly, proceed as though the vulnerable condition may be present and patch accordingly.

Bottom line

CVE-2026-5513 is a stored XSS flaw in the Bookly WordPress plugin affecting versions up to and including 27.2. The vulnerability is unauthenticated, but exploitation requires the “Remember personal information in cookies” option to be enabled, and NVD says that setting is disabled by default.

There is no confirmed public PoC, no confirmed in-the-wild exploitation, and the CVE is not in CISA KEV based on the retrieved sources. Even so, defenders should not wait for exploitation reports. If you run Bookly on public WordPress sites, verify the setting, inspect logs for suspicious cookie values, and upgrade to a version newer than 27.2, ideally 27.7 or later.

For further information on cybersecurity frameworks, check our article on Cybersecurity Framework and for best practices on SIEM hardening, visit our guide on SIEM Hardening Best Practices.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.