What is the CVSS score of EUVD-2026-26361?

EUVD-2026-26361 has a CVSS 3.1 base score of 5.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N. EPSS exploitation probability: 0.0%.

Five Star Restaurant Reservations EUVD-2026-26361

| CVE-2026-6498 MEDIUM

Insufficient Verification of Data Authenticity (CWE-345)

2026-04-30 Wordfence

WordPress Authentication Bypass PHP

5.3

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

5.3 MEDIUM

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

Low

Availability

None

Lifecycle Timeline

Analysis Generated

Apr 30, 2026 - 10:15 vuln.today

EUVD ID Assigned

Apr 30, 2026 - 10:00 euvd

EUVD-2026-26361

Analysis Generated

Apr 30, 2026 - 10:00 vuln.today

CVE Published

Apr 30, 2026 - 09:29 nvd

MEDIUM 5.3

DescriptionCVE.org

The Five Star Restaurant Reservations plugin for WordPress is vulnerable to a payment bypass via PHP type juggling in versions up to, and including, 2.7.16 This is due to the valid_payment() function using a PHP loose comparison () between the attacker-controlled payment_id POST parameter and the booking's stripe_payment_intent_id property. When an unauthenticated attacker submits a request to the nopriv AJAX handler rtb_stripe_pmt_succeed before the Stripe payment intent has been created for a booking (i.e., before the JavaScript-triggered create_stripe_pmtIntnt() call has stored an intent ID in post meta), the stripe_payment_intent_id property on the booking object remains null. The comparison sanitize_text_field('') null evaluates to TRUE in PHP loose comparison, causing the payment verification check to pass with zero actual payment. This makes it possible for unauthenticated attackers to mark any existing payment_pending booking as paid without completing a Stripe payment by submitting an empty payment_id parameter.

AnalysisAI

Five Star Restaurant Reservations plugin for WordPress versions up to 2.7.16 allows unauthenticated attackers to bypass payment verification through PHP type juggling in the valid_payment() function. The vulnerability exists in the rtb_stripe_pmt_succeed AJAX handler, which uses loose comparison (==) between attacker-supplied payment_id and the booking's stripe_payment_intent_id. When the intent ID is null (before Stripe intent creation), an empty payment_id parameter passes validation, enabling attackers to mark payment-pending bookings as paid without completing actual Stripe payments. This permits unauthorized order fulfillment and revenue loss for affected WordPress sites.

Technical ContextAI

The Five Star Restaurant Reservations plugin integrates Stripe payments into WordPress restaurant booking workflows via the PaymentGatewayStripe class. The vulnerability stems from PHP loose comparison semantics where sanitize_text_field('') null evaluates to TRUE. The valid_payment() function is called by the rtb_stripe_pmt_succeed nopriv AJAX action, which is accessible to unauthenticated users via wp-admin/admin-ajax.php. The root cause is CWE-345 (Insufficient Verification of Data Authenticity), compounded by reliance on POST-controlled payment_id without cryptographic verification. The vulnerability exists in the payment intent verification flow before the JavaScript-triggered create_stripe_pmtIntnt() function completes server-side, leaving stripe_payment_intent_id as null in post meta. The affected code uses loose comparison instead of strict comparison (=) or null-coalescing checks.

RemediationAI

Update Five Star Restaurant Reservations plugin to version 2.7.17 or later, which implements strict comparison (===) or null checks in the valid_payment() function per changeset 3518833 in the plugin SVN repository. Patch is confirmed available; WordPress administrators should apply via the WordPress admin dashboard Plugins > Updates interface. As immediate compensating control, if patching is delayed: disable the Stripe payment gateway feature in plugin settings until patched; or restrict access to wp-admin/admin-ajax.php from public IPs using firewall/WAF rules (trade-off: may impact legitimate booking workflows if JavaScript payment initiation is affected); or monitor post meta for bookings with null stripe_payment_intent_id values that transition to 'paid' status without corresponding Stripe webhook events (detection-only, does not prevent). None of these workarounds are as effective as patching.