If you received an email from me pointing you to this page, it is because your website appears to be running a version of Bookly (the WordPress appointment-booking plugin bookly-responsive-appointment-booking-tool) that falls within the affected range of a known security issue. This page explains what the issue is, how to check which version you have, how to update, and the one follow-up step worth taking afterwards.

The issue is CVE-2026-13395, an unauthenticated SQL injection in the plugin’s front-end booking flow. It affects versions 11.3 through 27.7 and is fixed in 27.8, released on 10 July 2026. If you are running an affected version, update Bookly to 27.8 or later (27.9 is the current release and also contains the fix). There is no indication that this issue is being exploited against any site, and no public report of it being exploited anywhere; this page is a precautionary heads-up, not an incident report.

Unlike some of the other notices I have sent, this one does not depend on how your site is configured. There is no setting that has to be switched on for the flaw to be reachable: the affected request path is open to visitors who are not logged in, on an ordinary installation. If your Bookly version is in the affected range, the update is worth doing promptly.

This is a plugin flaw, not a WordPress core flaw. A fully up-to-date WordPress does not protect you if the Bookly plugin itself is on an affected version.

Is this message legitimate?

Yes. This is a good-faith, responsible-disclosure notice from an independent security researcher. I am not asking you for money, passwords, or access to your site, and I have not attempted to break into it, submit anything to it, or exploit anything.

All I did was look at publicly visible files that your website serves to every visitor (the same way your homepage is public) and note the version number that the Bookly plugin publishes. I specifically did not send anything to your booking form or to the request path this issue concerns, and nothing about this check touches your data, your admin area, or any private part of your site (more detail under What I did and did not do below).

If you would like to verify who I am, see the contact details at the bottom of this page and the About page.

Why this matters

Bookly is one of the most widely used appointment-scheduling plugins for WordPress, in the official directory since 2014 and running on tens of thousands of sites. It publishes a booking form on the front end of your site so visitors can pick a service, a staff member and a time slot without needing an account.

In affected versions, one of the values that form sends back, the identifier of the staff member a visitor selected, is stored exactly as it arrives, without being checked, and is later placed straight into a database query rather than being passed as a parameter. A visitor who sends a crafted value instead of an ordinary staff identifier can therefore change the meaning of that query. The practical effect: someone with no account and no login could read data from your site’s database that the query was never meant to return, including the password hashes of your WordPress user accounts.

Two things are worth stating plainly, in both directions.

First, keeping it in perspective: this is a data-read issue, not a server or administrator takeover. It does not by itself let an attacker run code on your server or log into your admin area. A password hash is not a password; it still has to be cracked before it becomes access. And there is no evidence of exploitation: the authority that assigned the CVE published no severity score, it is not in CISA’s Known Exploited Vulnerabilities catalog, its exploitation-likelihood score (EPSS) is unscored, and I am aware of no exploitation reports anywhere.

Second, not soft-pedalling it: no login, no nonce and no particular plugin setting stands between an anonymous visitor and this path. It is reachable on a default installation of the free plugin. That is why the recommendation here is to update promptly rather than to fold it into your next maintenance window.

If my email cited this issue, it means the version your site reports falls within the affected range. I did not test whether your particular site is exploitable; all I observed is the version.

Am I affected?

It comes down to one question: which version of Bookly are you running? You do not have to take my word for it, and there are two ways to check.

From the WordPress admin area (authoritative):

  1. Log in to your WordPress dashboard (usually at yourdomain.com/wp-admin).
  2. Go to Plugins then Installed Plugins.
  3. Find Bookly, the entry whose folder is bookly-responsive-appointment-booking-tool, and note the version shown beneath its name.

From the public manifest (no login needed): open yourdomain.com/wp-content/plugins/bookly-responsive-appointment-booking-tool/readme.txt in a browser. The Stable tag: line near the top is the version your install reports, and this is the same public file I read.

Then apply this rule, and note that versions compare numerically, not alphabetically:

  • 11.3 through 27.7: affected. Update now.
  • 27.8 or newer: already fixed. This includes 27.9, which keeps the fix.
  • Older than 11.3: not affected by this issue. The unsafe query construction did not exist in those releases: the staff identifiers went through the plugin’s parameterised query builder instead. A release that old has plenty of other reasons to be updated, but this notice is not one of them.
  • Do not read version numbers as text. Bookly is on a two-digit major version, so text ordering gives the wrong answer twice over: 3.3 looks larger than 27.8 alphabetically but is far older, and 27.10 looks smaller than 27.7 but is newer. Compare each number in turn.

A note on Bookly’s add-ons. Bookly’s paid extensions (Pro, and the various bookly-addon-* packages) install as separate plugins with their own version numbers, and their asset URLs can carry the core plugin’s version rather than their own. The version that matters for this notice is the one on the core Bookly plugin, from either of the two checks above, not a number read off an add-on’s files.

If you cannot see any Bookly files from outside. Bookly has a setting that controls whether its scripts and styles load on every page or only on the pages that carry a booking form. If yours is set to the latter, much less of the plugin is visible to an outside observer. That setting affects only what a visitor can see; it has no bearing on whether the flaw is present or reachable. Check your version in the admin area.

How to upgrade

The safest path is to update through WordPress itself, and to back up first:

  1. Back up your site (files and database) before making changes. Most hosting providers offer one-click backups, or use a WordPress backup plugin.
  2. In the WordPress admin, go to Dashboard then Updates, or Plugins then Installed Plugins. If a Bookly update is listed, install it from here.
  3. If you prefer the command line, WP-CLI does the same thing: wp plugin update bookly-responsive-appointment-booking-tool.
  4. If no update appears, you can get the latest release directly from the plugin’s page on the WordPress.org directory, Bookly, and update via Plugins then Add New Plugin then Upload Plugin.
  5. After updating, confirm the new version number (27.8 or later) using the steps above, and check that your booking form and existing appointments still work normally.

If you use Bookly’s paid add-ons, update those alongside the core plugin, as their releases are usually paired.

While you are in there, it is worth confirming that WordPress core and your other plugins are up to date, since the same principle applies to all of them.

After updating

Updating to 27.8 or later closes the issue, and there is no indication this flaw has been exploited anywhere, so no emergency response is implied: you do not need to treat your site as compromised or take it offline.

One follow-up is worth doing rather than filing away, and it is specific to what this particular flaw could reach. Because WordPress password hashes were among the data the query could return, and because a hash captured earlier stays useful to an attacker after you have updated, the sensible precaution is to reset the passwords on your administrator accounts once the update is in place. Two smaller steps go naturally with it:

  • Have a look over your administrator and editor accounts for any you do not recognise, in the ordinary way you would review site access.
  • Regenerate WordPress’s secret keys and salts in wp-config.php (new values are one click away at the official secret-key generator; swapping them signs all users out once).

Treat this as ordinary security housekeeping, not incident response.

What I did and did not do

To be fully transparent about the check behind my email: I only read public files that your site already serves to every visitor, specifically the Bookly plugin’s public readme.txt file and your homepage. I did not access your WordPress admin area, your database, or any private part of the site.

In particular, I never sent anything to your booking form or to the request path this issue concerns; nothing was submitted, tested, or exploited. That matters more here than on most of these pages: the flaw is an unauthenticated request to that path, so “I did not touch it” is the whole difference between a disclosure and an intrusion.

This is a version-based observation: your site reports a version in the affected range. A site in that range may already be protected by other means, such as a web application firewall or a backported fix. This notice is not a statement that your site was exploitable at the time I checked.

I do not have a webmaster / I am stuck

If you are not the person who maintains the site, please forward this page to whoever does (your web developer, agency, or hosting provider). They will recognize the steps above quickly.

If you are maintaining the site yourself and get stuck, I am happy to help point you in the right direction at no cost. Reach out using the contact details below.

Contact

Evan Harris, Security Researcher

I reach out about issues like this purely to help operators secure their sites. If you would prefer not to be contacted again, just let me know and I will honor that.

References

Official advisories and tracking

Vendor / plugin