Description

The Royal Addons for Elementor WordPress plugin before 1.7.1066 does not perform any capability or ownership check (relying only on a publicly-scrapeable nonce) before writing like-count and visitor-tracking post meta keyed on an arbitrary post ID, allowing unauthenticated users to modify that metadata on any post, including private and draft posts.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-26T06:16:24.593Z",
  "pubdate": "2026-08-26T06:16:24.593Z",
  "executiveSummary": "The Royal Addons for Elementor plugin is susceptible to an improper authorization vulnerability that allows unauthenticated remote attackers to modify post metadata.\nThe vulnerability stems from the plugin's failure to perform adequate capability or ownership checks when updating like-counts and visitor-tracking information.\nBecause the plugin relies solely on a publicly accessible nonce for request validation, an attacker can manipulate metadata for any post ID, including content that is set to private or draft status.\nThis unauthorized write access poses a significant security risk, enabling integrity violations across the WordPress database.\nSuccessful exploitation requires no authentication or special privileges, as the vulnerable endpoint is exposed to the public internet.\nThe primary risk involves the unauthorized modification of arbitrary post meta, which can be leveraged to alter site-wide metrics or potentially influence logic dependent on metadata values.",
  "technicalDetails": "The vulnerability resides within the request handling logic for the Royal Addons for Elementor plugin. Specifically, the functionality responsible for incrementing like-counts and tracking visitor engagement fails to verify the identity or permissions of the requesting user.\nRoot Cause Analysis: The plugin implements a validation mechanism that relies exclusively on a nonce token. Because this nonce is publicly available to any site visitor—often embedded in the HTML source code of pages utilizing the plugin—it fails to provide any meaningful security boundary. The implementation lacks the necessary call to current_user_can() or an equivalent authorization check to confirm that the requester possesses the appropriate capabilities to modify metadata for a specific post object.\nAttack Flow: An attacker can intercept the legitimate request flow intended for metadata updates. By observing the AJAX or REST API calls made by the plugin, the attacker identifies the endpoint and the required parameters, including the post ID and the insecure nonce. Because the backend does not validate the ownership of the target post, the attacker can supply any arbitrary numeric ID in the post_id parameter. The backend proceeds to execute an update_post_meta() operation using the attacker-supplied data.\nExploitation Scope: The vulnerability is not limited to public-facing posts. The logic fails to differentiate between public, private, or draft posts. Consequently, an attacker can inject or modify metadata on unpublished or administrative-only content. While the current impact is limited to meta-key manipulation, this demonstrates a critical failure in authorization architecture that violates the Principle of Least Privilege.\nPost-Exploitation: By weaponizing this capability, an attacker could potentially conduct large-scale metadata manipulation. Depending on how other plugins or theme functions interact with the affected metadata fields, this could lead to unintended behavioral changes within the WordPress environment, such as skewing analytics, manipulating view counts for social proof, or potentially triggering secondary vulnerabilities if the metadata is processed unsafely by other components."
}