Description

The Restaurant Menu and Food Ordering WordPress plugin before 2.4.12 does not verify that a PayPal payment notification genuinely originates from PayPal, allowing unauthenticated attackers to forge a payment notification and mark their own order as paid and completed without making any payment.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-04T10:17:13.570Z",
  "pubdate": "2026-09-04T10:17:13.570Z",
  "executiveSummary": "The Restaurant Menu and Food Ordering WordPress plugin is susceptible to an improper input validation vulnerability within its PayPal IPN (Instant Payment Notification) handling mechanism. This flaw exists in all versions prior to 2.4.12.\nThe vulnerability originates from the plugin's failure to verify the authenticity of incoming POST requests directed at its payment listener endpoint. Specifically, the system processes payment notifications without performing a back-channel handshake or cryptographic signature validation with PayPal’s servers to confirm the transaction's legitimacy.\nAn unauthenticated, remote attacker can exploit this by crafting a malicious HTTP request that mimics a successful PayPal payment notification. By injecting specific parameters, the attacker can manipulate the internal order state of the plugin, effectively signaling the application to mark a transaction as 'Paid' and 'Completed' without any funds being transferred.\nThe impact of this vulnerability is severe, as it facilitates direct financial theft and unauthorized procurement of goods or services. Because the exploitation process requires no prior authentication or administrative privileges, it represents a significant threat to the integrity of the e-commerce workflow and store revenue. Successful exploitation grants the attacker full fulfillment of orders, leading to immediate financial loss for the site administrator.",
  "technicalDetails": "The root cause of this vulnerability lies in the insecure implementation of the PayPal IPN listener. PayPal’s Instant Payment Notification service requires that developers verify the integrity of the data received by sending the received payload back to PayPal’s servers via a secure HTTPS POST request. The server must then receive a 'VERIFIED' response before proceeding with order fulfillment.\nIn the affected versions of the Restaurant Menu and Food Ordering plugin, this verification step is omitted. The code assumes that any request hitting the IPN endpoint is legitimate. When the plugin receives a POST request, it parses the payload—which typically contains fields such as 'payment_status', 'txn_id', and 'mc_gross'—and immediately updates the database to reflect a successful transaction based solely on the provided input.\nThe attack flow proceeds as follows: First, the attacker identifies the plugin's endpoint responsible for processing IPN messages. Second, the attacker generates a forged HTTP POST request containing key-value pairs that correspond to the fields the plugin checks to determine order completion. This payload includes a 'payment_status=Completed' parameter and a spoofed 'txn_id'. Third, the attacker transmits this crafted request to the plugin’s listener URL. Fourth, the plugin receives this malicious request and, lacking a verification routine, directly processes the data by querying its internal database to find the associated order ID. Finally, the plugin updates the order record to 'Completed' status, triggering whatever downstream processes are configured, such as email notifications or status changes visible to the end-user.\nBecause the plugin does not implement nonces or cryptographic signature validation (such as verifying the 'verify_sign' parameter provided by PayPal), it is impossible for the system to distinguish between a genuine notification from PayPal’s infrastructure and an attacker-controlled request. This constitutes an Insecure Direct Object Reference (IDOR) related issue combined with a failure to perform trust-boundary verification. The exploitation is trivial, requiring only the knowledge of the plugin's endpoint and the expected POST parameter keys. No administrative access, cross-site scripting (XSS) vectors, or user interaction is required to achieve full unauthorized order completion, making this a critical flaw in the plugin’s payment processing architecture."
}