SURIQ
A booking plugin running on more than 60,000 WordPress sites now hands a passing stranger a foothold inside the site owner's own browser. CVE-2026-13424 is an unauthenticated stored cross-site scripting bug in Bookly, the appointment and scheduling plugin published by Ladela. Wordfence, which assigned the CVE, rates it 7.2 on the CVSS scale. There is no login step for the attacker, and at the time of writing no public exploit and no report of exploitation in the wild. Treat it as work for today anyway, because the interesting part is not the injection. It is when the payload fires.
The injection is easy. The timing is the point.
Cross-site scripting comes in two shapes. Reflected XSS needs the victim to click a rigged link in the same request. Stored XSS is patient: the attacker plants the payload once, it sits in the database, and it runs whenever someone loads the page that renders it. This is the stored kind, and the page that renders it is one only an administrator sees.
The sequence is what makes it worth patching before the weekend. An anonymous request reaches the bookly_speed_up_update_addons action, which is exposed without authentication. The script content is saved into the plugin's log records without being neutralized. Nothing happens yet. The site looks fine. Then an administrator opens Bookly's Diagnostics and Logs view, the stored markup is written into that page unescaped, and the attacker's script executes with that admin's session in front of it.
- 1Anonymous request to the Bookly AJAX action, no login neededDetection point
- 2Script content saved into the plugin's log recordsDetection point
- 3Admin opens Diagnostics then Logs, the script runs in their sessionDetection point
Two traits in the CVSS scoring matter more than the 7.2 headline. Wordfence marks it as needing no privileges, which confirms the attacker plants the payload without any account. It also marks the scope as changed, the tell that the script breaks out of the plugin's own context and can act against the wider admin session. A cross-site script running as a WordPress administrator is not the prize by itself. It is the stepping stone to the prize: the session, a new admin account, or a plugin edit that turns the site into something the owner no longer controls.
Who runs Bookly, and why a dormant payload is worse here
Bookly has been on WordPress.org since 2014 and reports more than 60,000 active installations. The people running it are mostly not security teams. They are salons, clinics, tutors, coaches, and consultants who installed a booking form and moved on. That profile changes the risk math in the attacker's favor for one reason: the trigger is a support action.
When a booking stops working, the first thing a non-technical owner or their helper does is open the plugin's diagnostics to see what broke. That is precisely the page that detonates a stored payload here. The victim is not tricked into clicking anything unusual. They do the normal troubleshooting step, and the trap they never saw planted goes off. A site with no analyst, no web application firewall, and a habit of opening the logs when something misbehaves is the ideal target for a bug whose whole design is to wait.
This is also not the first cross-site scripting issue catalogued in Bookly. Vulnerability databases including Wordfence and Patchstack list several across the plugin's history, a reminder that a booking form which accepts input from the public is a large surface to keep escaped. None of that is a reason to panic about the plugin; it is a reason to keep it current and to watch the input paths that reach an admin screen. We have seen the same pattern in other WordPress plugins, from a link an admin clicks that spins up a rogue admin account to hijacked plugins that planted hidden admin accounts and a webshell.
Exploitation status and the versions that matter
Here is the state a defender actually needs. Every Bookly version up to and including 27.7 is affected. The vendor's changelog shows the current release is 28.0, past the affected range, so updating to the latest version closes the injection point. There is no public proof-of-concept exploit at the time of writing, the flaw is not on the CISA Known Exploited Vulnerabilities catalog, and no exploitation in the wild has been reported. For a plugin with this reach, that quiet window is exactly when to patch, not a reason to wait.
Update, then check the Bookly log
Updating is step one and it is the important one: move every site off 27.7 or earlier to the current Bookly release. But patching a stored-XSS flaw has a second step that a version bump alone does not cover. The update stops new payloads from being written; it does not remove a payload that was already stored while the site was exposed. If your site ran an affected version on the public internet, the log table may already hold a waiting script that the next admin visit would run.
So after you update, review the Bookly diagnostics log for entries that contain script markup, and clear or discard anything that does not belong. If you find planted content, treat it as a possible admin-session compromise and rotate administrator credentials. For detection going forward, the signal to hunt is an unauthenticated POST to admin-ajax.php calling the bookly_speed_up_update_addons action, and script-like content appearing in the plugin's log records. On a host you monitor centrally, both of those are visible in web-server request logs and worth an alert while the patch rolls out across the sites you run.