CVE-2025-14075: WP Hotel Booking Information Disclosure

CVE-2025-14075 Overview

The WP Hotel Booking plugin for WordPress contains a Sensitive Information Exposure vulnerability affecting all versions up to and including 2.2.7. The vulnerability exists because the plugin exposes the hotel_booking_fetch_customer_info AJAX action to unauthenticated users without implementing proper capability checks. The plugin relies solely on a nonce for protection, which can be bypassed when the nonce is publicly accessible on the site.

Critical Impact

Unauthenticated attackers can retrieve sensitive customer information including full names, addresses, phone numbers, and email addresses by providing a valid email address and a publicly accessible nonce.

Affected Products

• WP Hotel Booking plugin for WordPress versions up to and including 2.2.7

Discovery Timeline

• 2026-01-17 - CVE CVE-2025-14075 published to NVD
• 2026-01-17 - Last updated in NVD database

Technical Details for CVE-2025-14075

Vulnerability Analysis

This vulnerability is classified as CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). The core issue lies in the plugin's improper implementation of access control for its AJAX endpoint. While the developers implemented nonce verification as a security measure, this approach is fundamentally flawed when the nonce is exposed in the page source or accessible to unauthenticated users.

The hotel_booking_fetch_customer_info function processes requests without validating that the requester has appropriate permissions (such as being logged in as an administrator or the customer themselves). This architectural weakness allows any visitor to the WordPress site to query customer data by simply providing an email address along with a valid nonce token obtained from the public-facing pages.

Root Cause

The root cause is improper authorization logic in the AJAX handler implementation. The plugin registers the AJAX action for both authenticated (wp_ajax_) and unauthenticated (wp_ajax_nopriv_) users but only implements nonce verification rather than proper capability checks. Nonces in WordPress are designed to prevent CSRF attacks, not to control access permissions. Since nonces can be embedded in public pages and are predictable within their validity window, relying on them as the sole authentication mechanism creates a significant security gap.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker can exploit this vulnerability by:

1. Visiting the target WordPress site and extracting a valid nonce from the page source
2. Crafting an AJAX request to the hotel_booking_fetch_customer_info endpoint
3. Providing an email address of a known or guessed customer
4. Receiving the full customer profile data in the response

The vulnerability allows enumeration of customer data if the attacker can obtain or guess valid email addresses. This could be combined with other information gathering techniques to harvest complete customer databases.

The vulnerable code can be examined in the WordPress Plugin Source Code where the AJAX handler is registered and the handler function implementation.

Detection Methods for CVE-2025-14075

Indicators of Compromise

• Unusual spikes in AJAX requests to admin-ajax.php with the action parameter hotel_booking_fetch_customer_info
• Multiple requests from single IP addresses querying different email addresses
• Requests to the vulnerable endpoint from non-authenticated sessions
• Log entries showing sequential or patterned email address queries

Detection Strategies

• Monitor web server access logs for repeated POST requests to admin-ajax.php containing the hotel_booking_fetch_customer_info action
• Implement rate limiting rules on the web application firewall (WAF) for AJAX endpoints
• Configure intrusion detection systems (IDS) to alert on high-frequency requests to the WordPress admin-ajax handler from single sources
• Review WordPress audit logs for customer data access patterns

Monitoring Recommendations

• Enable detailed logging for all AJAX requests in WordPress
• Configure alerts for any access to the hotel_booking_fetch_customer_info endpoint from unauthenticated sessions
• Implement behavioral analysis to detect enumeration attempts based on sequential email queries
• Regularly audit customer data access logs to identify potential unauthorized access

How to Mitigate CVE-2025-14075

Immediate Actions Required

• Update the WP Hotel Booking plugin to a patched version immediately
• Review access logs for signs of exploitation targeting the hotel_booking_fetch_customer_info endpoint
• Consider temporarily disabling the plugin until the update can be applied
• Notify affected customers if evidence of data exposure is discovered

Patch Information

The vulnerability has been addressed in newer versions of the plugin. Administrators should update to the latest available version through the WordPress plugin update mechanism. The security fix involves implementing proper capability checks in addition to nonce verification for the AJAX endpoint. Technical details of the patch can be reviewed in the WordPress Plugin Change Log. Additional vulnerability details are available from Wordfence Vulnerability Intelligence.

Workarounds

• Implement a web application firewall (WAF) rule to block unauthenticated requests to the hotel_booking_fetch_customer_info action
• Use a WordPress security plugin to restrict AJAX endpoint access to authenticated users only
• Add custom code to the theme's functions.php to remove the vulnerable AJAX action until a patch is applied
• Consider using .htaccess rules to block direct access to admin-ajax.php for specific actions from non-logged-in users

# Example .htaccess rule to restrict the vulnerable endpoint
# Add to WordPress root .htaccess file
<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} POST
    RewriteCond %{REQUEST_URI} /wp-admin/admin-ajax\.php
    RewriteCond %{QUERY_STRING} action=hotel_booking_fetch_customer_info [NC,OR]
    RewriteCond %{HTTP:X-Requested-With} !XMLHttpRequest
    RewriteRule ^ - [F,L]
</IfModule>