CVE-2026-84044 in Restaurant Menu and Food Ordering Plugin
Summary
by MITRE • 09/04/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in the Restaurant Menu and Food Ordering WordPress plugin prior to version 2.4.12 represents a critical failure in authentication logic for financial transactions, specifically within the PayPal integration module. This flaw stems from an insufficient verification process where the application accepts payment status updates without validating their source authenticity. In secure web applications handling monetary exchanges, it is imperative that any callback or notification regarding transaction completion originates exclusively from the trusted third-party payment processor. By failing to implement rigorous checks such as verifying digital signatures, IP address whitelisting against known PayPal ranges, or utilizing token-based validation mechanisms provided by the Payment Service Provider API, the plugin leaves a significant attack surface open for exploitation. This architectural oversight allows any external actor with network connectivity to interact directly with the payment notification endpoint without requiring valid user credentials or session tokens.
From an operational perspective, this vulnerability enables unauthenticated attackers to forge PayPal payment notifications and artificially mark their orders as paid and completed. The attacker constructs a malicious HTTP request that mimics the structure of a legitimate IPN (Instant Payment Notification) sent by PayPal but contains fabricated data indicating successful payment for any order ID accessible or guessable within the system. When the plugin processes this forged notification, it updates the database to reflect that the customer has paid and completed their purchase. This results in immediate financial loss as goods or services are delivered without corresponding revenue collection. Furthermore, because no authentication is required, the attack can be automated at scale, potentially allowing attackers to exploit multiple orders simultaneously or target high-value transactions with minimal effort and risk of detection during initial exploitation phases.
The technical classification of this flaw aligns closely with CWE-345, which describes Insufficient Verification of Data Authenticity, as well as CWE-862, Missing Authorization, since the action is performed without proper privilege checks relative to payment verification protocols. In terms of offensive security frameworks, this vulnerability maps directly to MITRE ATT&CK technique T1078, Valid Accounts, although in this specific context it extends beyond traditional account theft into direct manipulation of transaction states via unauthenticated API abuse. It also relates to T1496, Resource Hijacking, if the attacker uses forged payments to consume resources or services intended for paying customers. The core issue lies not just in the lack of input validation but in the fundamental trust model assumed by the application code regarding external data sources.
To mitigate this vulnerability and prevent similar issues in future implementations, developers must enforce strict verification protocols for all payment-related callbacks. This includes implementing server-side validation that checks the IP address of the incoming request against a list of known PayPal IP ranges to ensure it originates from their infrastructure. Additionally, applications should utilize secure token exchange mechanisms where the plugin sends a confirmation back to PayPal with the original transaction ID and receives a verified response confirming the status before updating local records. Hash-based Message Authentication Codes (HMAC) or digital signatures provided by payment gateways must be validated against stored secrets rather than relying on simple parameter matching. Upgrading to version 2.4.12 or later resolves this issue as it incorporates these necessary security controls, ensuring that only genuine notifications from the payment processor are accepted and processed correctly within the application logic.