Description

The WP Booking System – Booking Calendar plugin for WordPress is vulnerable to time-based SQL Injection via the 'current_month' parameter in all versions up to, and including, 2.1.0.1 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with subscriber-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. This is a regression vulnerability — a capability check introduced in versions 2.0.19.11–2.0.19.14 to address CVE-2024-50425 was removed in version 2.1, meaning any authenticated subscriber-level account can reach the vulnerable handler with no nonce validation required.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-10-10T07:16:40.700Z",
  "pubdate": "2026-10-10T07:16:40.700Z",
  "executiveSummary": "The WP Booking System – Booking Calendar plugin for WordPress contains a time-based SQL injection vulnerability affecting versions up to and including 2.1.0.1. This vulnerability arises from inadequate sanitization and parameterization of the 'current_month' input, exacerbated by a regression where previously implemented capability checks were removed.\nThe flaw allows authenticated users with subscriber-level privileges or higher to execute arbitrary SQL commands against the WordPress database. This creates significant security implications, including the potential for unauthorized data exfiltration, database structure exposure, and sensitive information leakage.\nThe attack is characterized as a regression, as the vendor failed to maintain security controls introduced in versions 2.0.19.11–2.0.19.14 regarding CVE-2024-50425. Because the vulnerable handler lacks nonce validation and proper access control, any authenticated user can trigger the injection. The risk level is critical for affected environments, as it permits lateral movement within the data layer without requiring administrative permissions.",
  "technicalDetails": "The root cause of this vulnerability is improper neutralization of special elements used in an SQL command within the plugin's query construction logic. Specifically, the 'current_month' parameter is passed directly into a database query without sufficient escaping or the use of prepared statements. This failure allows an attacker to break out of the intended query syntax and append malicious SQL statements.\nA secondary, critical component of this vulnerability is a regression in the plugin's access control logic. Previous iterations of the software (versions 2.0.19.11–2.0.19.14) introduced capability checks to mitigate CVE-2024-50425; however, these protections were inadvertently removed in version 2.1. Consequently, the affected handler no longer enforces nonce validation or checks if the requester possesses adequate administrative privileges.\nThe attack flow proceeds as follows: First, an attacker authenticates as a subscriber-level user. Second, they craft a malicious HTTP request targeting the vulnerable handler, injecting SQL syntax into the 'current_month' parameter. Because the handler lacks input validation, the malicious input is concatenated directly into the database query.\nThe exploitation method relies on time-based blind SQL injection techniques. By injecting conditional SQL statements (e.g., using sleep functions or heavy queries), the attacker can infer the contents of the database based on the server's response latency. Since the query is executed with the privileges of the database user configured for the WordPress site, the attacker can perform arbitrary 'SELECT' operations. This enables the exfiltration of sensitive information, such as user credentials, plugin configurations, and other private data stored within the WordPress database tables.\nThe lack of prepared statements ensures that the injected SQL code is parsed and executed by the database engine as part of the primary query logic. Post-exploitation impact is severe, as it facilitates data breach scenarios and potentially provides a foothold for further escalation if the database user possesses excessive permissions within the database management system."
}