On this page (7 sections)
A critical flaw, tracked as CVE-2026-116557, affects the WP Booking System - Booking Calendar plugin for WordPress in versions up to and including 2.1.0.5. A function that removes calendar notes does not check what the logged-in user is allowed to do, so an account with only Subscriber-level access can delete notes belonging to any calendar.
If you run a booking site that allows public registration, or you simply have many low-privilege accounts, this is worth checking today. The details below are based on the GitHub Advisory Database entry; the NVD record repeats the same description.
What happened
The plugin exposes an AJAX handler, wpbs_action_ajax_calendar_remove_note(), that deletes notes attached to booking calendars. According to the advisory, that function lacks a capability check. In WordPress, a capability check is the step where the code asks whether the current user is actually permitted to perform the action. Without it, being logged in is enough.
The advisory says authenticated attackers with Subscriber-level access and above can delete arbitrary calendar notes belonging to any calendar. Subscriber is the lowest default WordPress role, and on many sites anyone can obtain it by registering.
Technical details
This is a classic broken access control issue, classified as CWE-862 (Missing Authorization). The product does not perform an authorization check when an actor attempts to perform an action. The advisory lists the CVSS v3.1 vector as AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H.
One thing to note: the written description requires an authenticated Subscriber account, while the vector lists privileges required as None. The sources do not explain the difference, so treat the practical requirement as at least a logged-in account and do not assume anonymous visitors are safe.
The advisory points to the vulnerable code in version 2.1.0.5 of the plugin's notes file and to a WordPress.org changeset on trunk touching the same file. The sources do not state that this changeset is the official fix or which release contains it, so confirm this on the plugin page before relying on it. A Wordfence entry is also referenced.
Who is affected
Any WordPress site with the plugin installed at version 2.1.0.5 or earlier is in scope. Risk is highest where:
- Public registration is enabled and new users default to the Subscriber role.
- The site has many customer accounts, such as membership or WooCommerce sites that also use bookings.
- Staff rely on calendar notes for operational details such as guest requests or room instructions.
The stated impact is deletion of notes, which is a loss of data integrity. The CVSS vector also rates availability impact as high, but the sources describe nothing beyond note deletion, so avoid assuming broader consequences.
How to check your exposure
First find out whether the plugin is installed and which version you run. The WP-CLI command below lists the plugin with its status and version; run it from your WordPress root. Look for a version of 2.1.0.5 or lower.
wp plugin list --name=wp-booking-system --fields=name,status,version,update_versionThe plugin directory slug wp-booking-system comes from the file paths in the advisory references. If the command reports that the plugin is not installed, you are not affected by this issue.
Next, see how many low-privilege accounts exist. This read-only command lists users with the Subscriber role so you can look for unfamiliar registrations.
wp user list --role=subscriber --fields=ID,user_login,user_email,user_registeredWhat to do now
The advisory does not name a patched version, so the first job is to find out whether one exists. Check the plugin's page and changelog in your WordPress dashboard, then update.
wp plugin update wp-booking-system0 of 7 done
Detection and monitoring
The sources do not describe any signs of exploitation, so look for indirect signals. Staff reporting that calendar notes have vanished is the most obvious one. Check your web server access logs for unusual POST requests to admin-ajax.php from accounts that should not be using the booking features.
grep 'POST /wp-admin/admin-ajax.php' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | headA single IP sending many such requests is worth a closer look, though this pattern is not specific to this flaw and normal plugins also use that endpoint. For ongoing hygiene, Webforta Scan can run read-only checks on sites you verify, and our guide on WordPress plugin vulnerabilities explains how to keep track of known issues in what you have installed.
What we do not know yet
- No patched version is named in the advisory.
- No exploitation in the wild is reported in the sources, but absence of reports is not proof of safety.
- Only one independent publisher covers this so far; the NVD entry repeats the same text.
- The GitHub entry is marked Unreviewed, so details may be updated.
We will treat the version and fix details as provisional until the plugin author or a further source confirms them. For a broader routine, see the WordPress security checklist.
Sources
This article is based on the public sources below. Details can change as vendors and researchers publish more; check the original advisories before acting on version numbers.