Description

The Royal Elementor Addons plugin for WordPress is vulnerable to Server-Side Request Forgery in versions up to, and including, 1.7.1064 via the Form Builder widget's 'webhook_url' setting. The widget's render() method persists the attacker-controlled URL into the wpr_webhook_url_{widget_id} option on every render (including a Contributor previewing their own draft), and the wpr_form_builder_webhook AJAX handler — registered for both authenticated and unauthenticated callers — reads that option and dispatches the outbound request via the non-safe wp_remote_post(), with no host allowlist, no scheme restriction, and no private/loopback IP filter (the plugin's existing wpr_is_blocked_remote_host / wpr_is_private_or_local_ip helpers are not called on this path). This makes it possible for authenticated attackers, with Contributor-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-16T05:16:48.033Z",
  "pubdate": "2026-08-16T05:16:48.033Z",
  "executiveSummary": "The Royal Elementor Addons plugin for WordPress is susceptible to a Server-Side Request Forgery vulnerability affecting versions up to, and including, 1.7.1064. The flaw exists within the Form Builder widget's webhook functionality, specifically via the 'webhook_url' setting. This security deficiency allows authenticated attackers with Contributor-level access and above to force the underlying WordPress application to initiate unauthorized outbound HTTP requests to arbitrary destinations.\nThe root cause stems from insufficient input validation and the absence of destination restrictions within the request handling logic. Specifically, the application fails to enforce host allowlists, restrict URL schemes, or filter private and loopback IP addresses. Consequently, malicious actors can leverage this capability to interact with internal network resources, query sensitive metadata services, or modify information on internal services that are otherwise inaccessible from the external network perimeter.\nThe risk profile is elevated due to the exposure of the vulnerable AJAX handler to unauthenticated callers, combined with state persistence mechanisms that update the stored webhook configuration during standard rendering operations, such as a Contributor previewing a draft post. Remediation requires updating the plugin to a patched version once available, implementing strict destination validation routines, and applying defensive hardening controls.",
  "technicalDetails": "The vulnerability resides in the Royal Elementor Addons plugin, specifically within the Form Builder widget handling routines. The affected component processes the 'webhook_url' setting defined in the widget parameters. When the widget is rendered—which includes routine actions such as a Contributor-level user previewing their own draft post—the render() method executes and persistently stores the attacker-controlled URL directly into the WordPress database as the wpr_webhook_url_{widget_id} option.\nThe attack vector is exposed through the wpr_form_builder_webhook AJAX handler. This handler is registered to process requests from both authenticated and unauthenticated callers. Upon invocation, the handler reads the previously persisted wpr_webhook_url_{widget_id} option from the database and immediately dispatches an outbound HTTP request using the non-safe wp_remote_post() function.\nCrucially, the code path executing this outbound request lacks essential security controls. There is no host allowlist implemented, URL schemes are not restricted, and filters for private or loopback IP addresses are entirely omitted. Although the plugin contains existing helper functions designed to mitigate such risks—namely wpr_is_blocked_remote_host and wpr_is_private_or_local_ip—these helpers are not called along this specific execution path.\nThe step-by-step attack flow proceeds as follows: First, an authenticated attacker with Contributor-level privileges (or above) creates or edits a post containing the Form Builder widget, configuring the 'webhook_url' parameter to point to an internal resource or loopback address (e.g., http://127.0.0.1/ or an internal service endpoint). Second, the attacker triggers the widget's render() method, causing the malicious URL to be saved in the WordPress options table. Third, the attacker interacts with or triggers the wpr_form_builder_webhook AJAX handler. Finally, the application reads the stored URL and executes wp_remote_post() toward the targeted internal IP or service without validation, returning the response or facilitating internal network pivoting and information disclosure."
}