Description

The MotoPress Hotel Booking plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the Stripe Webhook event object 'id' in all versions up to, and including, 6.2.4 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The premium Stripe webhook listener only verifies the webhook signature when an optional Stripe signing secret has been configured; because that secret is empty by default, a forged webhook is accepted without cryptographic verification, and the attacker-controlled event object 'id' (e.g. a forged 'refund.created' refund id) is written unescaped into the payment log and later echoed unsanitized when an administrator views the payment. An attacker must know a valid Stripe PaymentIntent ID for an existing payment to route the forged webhook to a payment record. Note: The vulnerable webhook handler (webhook-listener.php) is part of the premium Stripe gateway integration and is not present in the lite plugin directory.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.2",
  "pubDate": "2026-09-15T15:17:29.117Z",
  "pubdate": "2026-09-15T15:17:29.117Z",
  "executiveSummary": "The MotoPress Hotel Booking plugin for WordPress is susceptible to a Stored Cross-Site Scripting (XSS) vulnerability residing within its Stripe webhook integration, affecting all versions up to and including 6.2.4.\nThe vulnerability originates from a failure to perform adequate input sanitization and output escaping on the Stripe Webhook event object 'id' parameter.\nAn unauthenticated attacker can exploit this flaw by submitting a forged webhook request to the vulnerable endpoint, leading to the injection of arbitrary malicious scripts into the application's payment logs.\nBecause the Stripe signing secret is not configured by default, the webhook listener fails to perform cryptographic signature verification, permitting unauthorized requests.\nWhen an administrator accesses the payment logs within the WordPress dashboard, the injected script executes within the context of their session. This presents a critical risk, potentially leading to unauthorized administrative actions, session hijacking, or exfiltration of sensitive site data.\nSuccessful exploitation requires the attacker to possess knowledge of a valid Stripe PaymentIntent ID associated with an existing payment record to target the forged webhook effectively.",
  "technicalDetails": "The root cause of this vulnerability is the improper handling of user-supplied data within the webhook-listener.php file, which is a component of the premium Stripe gateway integration for the MotoPress Hotel Booking plugin.\nThe application processes incoming Stripe webhook events but fails to enforce cryptographic validation due to an optional and frequently unconfigured Stripe signing secret. In the absence of this secret, the plugin accepts and processes forged webhook payloads without verifying their authenticity or origin.\nWhen a forged 'refund.created' event (or similar event types) is sent to the webhook endpoint, the attacker can supply a malicious string within the event object 'id' field. This value is subsequently persisted directly into the database as part of the payment log records without sanitization.\nThe exploitation flow proceeds as follows: First, the attacker identifies a valid Stripe PaymentIntent ID existing within the target system. Second, the attacker crafts a malicious webhook payload containing a Cross-Site Scripting (XSS) payload embedded within the 'id' field. Third, the attacker transmits this forged POST request to the plugin's webhook-listener.php. Fourth, the system parses the forged data and writes the malicious script to the payment log database table.\nThe final stage of the attack occurs when a privileged user, typically an administrator, navigates to the payment management section of the WordPress dashboard. The plugin retrieves the compromised payment logs and renders the unescaped, malicious 'id' content directly into the administrator's browser DOM.\nThe injected JavaScript executes with the permissions of the authenticated administrator. This allows the attacker to perform operations such as executing administrative functions, modifying plugin settings, or stealing session cookies via document.cookie access.\nThe vulnerability is limited to the premium Stripe gateway integration; the lite version of the plugin does not contain the vulnerable webhook-listener.php component. The flaw demonstrates a significant lack of security controls for inbound API integrations, where failure to validate integrity and sanitize inputs leads directly to persistent client-side code execution."
}