CVE-2023-5652

What it actually does

WP Hotel Booking for WordPress versions before 2.0.8 exposes functionality hooked into WordPress admin initialization without proper authorization checks, CSRF protection, or SQL parameterization/escaping. Because attacker-controlled input is incorporated into SQL statements, an unauthenticated remote attacker can inject SQL through crafted HTTP requests. Successful exploitation can allow reading sensitive database contents, modifying WordPress data, creating or changing administrator accounts, and potentially disrupting site availability through destructive or expensive database queries.

Why it matters to the business

A vulnerable site can be compromised remotely without credentials. The impact may include theft of customer, booking, user, and payment-adjacent data stored in WordPress; unauthorized changes to reservations or site content; administrator account takeover; malware or web shell deployment after database-level compromise; SEO spam; downtime; and incident response costs. The risk is elevated because the vulnerability is network-exploitable, requires no authentication or user interaction, has a critical CVSS score, high EPSS likelihood, and is described as weaponized despite not being listed in CISA KEV.

How an attack unfolds

An attacker first identifies WordPress sites running the WP Hotel Booking plugin, commonly by checking public plugin paths, asset references, or plugin metadata. If the installed version is earlier than 2.0.8, the attacker sends crafted unauthenticated requests to WordPress administrative endpoints that trigger the vulnerable admin_init-hooked function. Malicious parameters are supplied so that the plugin builds a SQL statement containing attacker-controlled SQL syntax. The attacker may begin with boolean-based or time-based tests to confirm injection, then enumerate database metadata, extract WordPress user records and password hashes, read booking/customer data, or modify records. In a higher-impact scenario, the attacker uses database write capability to create or elevate an administrator account, alter plugin/theme options, plant malicious content, or support follow-on compromise of the WordPress application.

How to fix it

Upgrade WP Hotel Booking to version 2.0.8 or later. If an exact package-management fixed version is not available, use the latest release from the vendor/WordPress plugin repository and confirm the installed plugin version is no longer below 2.0.8. If immediate upgrade is not possible, disable and remove the plugin until it can be updated, restrict access to WordPress administrative endpoints with a web application firewall or reverse proxy rule, and monitor/block SQL injection patterns targeting WordPress admin-ajax/admin-post traffic. Mitigations are not a substitute for patching because the flaw is unauthenticated and in application logic. After patching, rotate WordPress administrator credentials if compromise is suspected, review all administrator accounts, audit unexpected plugin/theme changes, and restore from known-good backups if database tampering is found.

How to confirm the fix worked

Confirm that the installed WP Hotel Booking plugin version is 2.0.8 or later from the WordPress admin plugin page, the plugin readme/version metadata, WP-CLI, or filesystem inspection of the plugin directory. Verify that the vulnerable plugin is not present in backups or alternate web roots that remain publicly reachable. Review web server and WAF logs for unauthenticated requests to WordPress admin endpoints containing SQL metacharacters, SQL functions, time-delay payloads, UNION-based probes, or references to database metadata. If using a vulnerability scanner, rescan the site after updating and confirm the finding is cleared. For high-assurance validation, perform an authorized non-destructive test for the previously vulnerable request pattern and verify injected SQL syntax is rejected, sanitized, or has no effect.

Typical attack path

1. Scan the internet or target domains for WordPress installations exposing WP Hotel Booking assets such as the wp-hotel-booking plugin directory.
2. Determine whether the plugin version is older than 2.0.8 using public metadata, cached assets, readme files, or behavioral probing.
3. Send unauthenticated crafted HTTP requests to WordPress admin-related endpoints that invoke the vulnerable admin_init logic.
4. Inject SQL syntax through vulnerable request parameters and validate execution using boolean, error-based, or time-delay behavior.
5. Enumerate database schema and extract sensitive WordPress and booking-related data.
6. Use database write access, where possible, to modify users, create an administrator account, alter site options, or stage persistence.
7. Perform follow-on activity such as web shell deployment through WordPress admin access, spam injection, data theft, or destructive database changes.

How to detect it

Check historical web server, CDN, reverse proxy, WAF, and WordPress security plugin logs for unauthenticated requests to WordPress administrative endpoints, especially /wp-admin/admin-ajax.php and /wp-admin/admin-post.php, containing SQL injection syntax or abnormal query parameters. Look for time-based probing such as SLEEP or BENCHMARK, UNION SELECT attempts, references to information_schema, MySQL error-function payloads such as updatexml or extractvalue, and encoded variants of these strings. Correlate suspicious requests with response status, response size changes, long response times, repeated parameter fuzzing, and requests from the same source across multiple WordPress sites. On the host, review WordPress user records for new or modified administrator accounts, plugin/theme files for unexpected PHP additions, recent changes under wp-content, and database records for injected scripts, spam links, or altered site options. Because exploitation can lead to database access rather than obvious file creation, absence of web shells does not rule out compromise.

• /wp-content/plugins/wp-hotel-booking/
• wp-hotel-booking
• /wp-admin/admin-ajax.php
• /wp-admin/admin-post.php
• UNION SELECT
• union%20select
• information_schema
• SLEEP(
• sleep%28
• BENCHMARK(
• benchmark%28
• EXTRACTVALUE(
• extractvalue%28
• UPDATEXML(
• updatexml%28
• @@version
• concat(
• concat%28
• /*!50000
• OR 1=1
• %27%20OR%201%3D1
• AND 1=1
• %27%20AND%201%3D1
• -- -
• %2D%2D%20%2D

What your security team should do

• Patch or remove WP Hotel Booking immediately on all WordPress sites; prioritize internet-facing sites and any site processing reservations, customer data, or payments.
• Confirm all instances are running WP Hotel Booking 2.0.8 or later; do not rely only on the main production site, as staging, archived, and marketing sites are frequently overlooked.
• Enable or tune WAF rules for SQL injection attempts against /wp-admin/admin-ajax.php, /wp-admin/admin-post.php, and other WordPress admin endpoints.
• Hunt web server, WAF, CDN, and WordPress logs for exploitation attempts dating back to at least the vulnerability publication window and any recent EPSS increase or scanning activity.
• Review WordPress administrator accounts, recently modified plugins/themes, site options, and unexpected content for signs of post-exploitation persistence.
• If suspicious SQL injection activity is found, preserve logs and filesystem artifacts, rotate privileged credentials, and consider database integrity review and malware scanning.
• Reduce WordPress plugin attack surface by removing unused plugins, disabling public access to readme/version files where feasible, and maintaining automated plugin update monitoring.