CVE-2026-6498: WordPress Restaurant Plugin Auth Bypass

CVE-2026-6498 Overview

The Five Star Restaurant Reservations plugin for WordPress contains a critical payment bypass vulnerability caused by PHP type juggling in versions up to and including 2.7.16. This vulnerability exists in the valid_payment() function, which uses a PHP loose comparison (==) between the attacker-controlled payment_id POST parameter and the booking's stripe_payment_intent_id property. When the Stripe payment intent has not yet been created for a booking, the stripe_payment_intent_id property remains null, and PHP's loose comparison evaluates sanitize_text_field('') == null as TRUE, allowing the payment verification check to pass without actual payment.

Critical Impact
Unauthenticated attackers can mark any existing payment_pending booking as paid without completing a Stripe payment, resulting in financial loss for restaurant owners and potential service theft.

Affected Products

Five Star Restaurant Reservations plugin for WordPress versions up to and including 2.7.16
WordPress installations with the vulnerable plugin enabled with Stripe payment integration
Restaurant reservation systems using the rtb_stripe_pmt_succeed AJAX handler

Discovery Timeline

2026-04-30 - CVE CVE-2026-6498 published to NVD
2026-04-30 - Last updated in NVD database

Technical Details for CVE-2026-6498

Vulnerability Analysis

This vulnerability is classified under CWE-345 (Insufficient Verification of Data Authenticity). The flaw stems from a fundamental misunderstanding of PHP's type comparison behavior in the payment verification logic.

The vulnerability exploits a race condition window between when a booking is created with payment_pending status and when the Stripe payment intent ID is stored in the post meta. During this window, the stripe_payment_intent_id property on the booking object is null. An attacker who submits a request to the nopriv AJAX handler rtb_stripe_pmt_succeed with an empty payment_id parameter can exploit PHP's loose comparison behavior.

In PHP, when using the loose comparison operator (==), an empty string sanitized through sanitize_text_field('') compared against null evaluates to TRUE. This allows the payment verification check to pass without any actual payment being processed through Stripe.

The attack requires no authentication and can be performed by any external attacker with knowledge of existing booking IDs, making this a significant business logic flaw with direct financial implications.

Root Cause

The root cause is the use of PHP's loose comparison operator (==) instead of the strict comparison operator (===) in the valid_payment() function within PaymentGatewayStripe.class.php. PHP type juggling causes unexpected behavior when comparing different data types:

Empty string '' loosely equals null
Integer 0 loosely equals string '0'
Boolean false loosely equals empty string ''

The vulnerable code compares user-supplied input directly against potentially uninitialized object properties without proper type checking, allowing attackers to bypass the payment validation entirely.

Attack Vector

The attack exploits the network-accessible rtb_stripe_pmt_succeed AJAX endpoint which is registered with nopriv (no authentication required). An attacker can craft a POST request with an empty payment_id parameter targeting a booking that is in payment_pending status but has not yet had its Stripe payment intent created.

The attack flow involves:

Identifying or creating a booking in payment_pending status
Sending a POST request to the vulnerable AJAX handler before the legitimate JavaScript-triggered create_stripe_pmtIntnt() call executes
Submitting an empty payment_id parameter that bypasses the loose comparison check
The booking status is updated to paid without any actual Stripe transaction

For technical details on the vulnerable code, see the WordPress Code Review at Line 404 and Line 458.

Detection Methods for CVE-2026-6498

Indicators of Compromise

Unusual POST requests to admin-ajax.php with action=rtb_stripe_pmt_succeed and empty or missing payment_id parameters
Booking records marked as paid without corresponding Stripe transaction IDs in the database
High volume of AJAX requests targeting the payment confirmation endpoint from non-browser user agents
Discrepancies between WordPress booking payment statuses and Stripe dashboard transaction records

Detection Strategies

Monitor web application logs for requests to admin-ajax.php containing the rtb_stripe_pmt_succeed action with empty POST parameters
Implement correlation rules between WordPress booking database and Stripe transaction logs to identify orphaned "paid" bookings
Deploy Web Application Firewall (WAF) rules to flag or block requests with empty payment_id parameters to the vulnerable endpoint
Set up alerting for booking status changes from payment_pending to paid without associated Stripe webhook confirmation

Monitoring Recommendations

Enable detailed logging for all WordPress AJAX requests, particularly those targeting payment-related endpoints
Implement automated reconciliation between booking payment statuses and Stripe payment records on a regular schedule
Configure rate limiting on the rtb_stripe_pmt_succeed AJAX endpoint to prevent automated exploitation attempts
Monitor for unusual patterns of bookings being marked as paid in rapid succession or outside business hours

How to Mitigate CVE-2026-6498

Immediate Actions Required

Update the Five Star Restaurant Reservations plugin to version 2.7.17 or later immediately
Audit all existing bookings marked as paid to verify corresponding Stripe transactions exist
Temporarily disable Stripe payment integration if immediate patching is not possible
Review web server logs for evidence of past exploitation attempts against the vulnerable endpoint

Patch Information

The vulnerability has been addressed in version 2.7.17 of the Five Star Restaurant Reservations plugin. The fix replaces the loose comparison operator (==) with a strict comparison operator (===) in the valid_payment() function, ensuring proper type checking during payment verification.

Review the WordPress Changeset 3518833 and the version comparison between 2.7.16 and 2.7.17 for complete technical details on the remediation. Additional vulnerability information is available in the Wordfence Vulnerability Report.

Workarounds

Implement a Web Application Firewall rule to block POST requests to admin-ajax.php with action=rtb_stripe_pmt_succeed that contain empty payment_id values
Temporarily require manual payment verification by restaurant staff for all new bookings until the patch is applied
Add server-side validation to reject requests where payment_id is empty before reaching the plugin code
Consider disabling the plugin's Stripe payment functionality and using alternative payment collection methods temporarily

bash

# Example .htaccess rule to block empty payment_id requests (Apache)
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} admin-ajax\.php
RewriteCond %{QUERY_STRING} action=rtb_stripe_pmt_succeed [OR]
RewriteCond %{THE_REQUEST} action=rtb_stripe_pmt_succeed
RewriteCond %{HTTP:Content-Length} ^0$ [OR]
RewriteCond %{REQUEST_BODY} ^$
RewriteRule .* - [F,L]