Description

The GiveWP WordPress plugin before 4.16.9 does not remove shortcode delimiters from donor-supplied values before rendering them on public pages, and the shortcode stripping it applies can be defeated by nesting, allowing unauthenticated users to execute arbitrary shortcodes registered on the site.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-21T09:17:06.040Z",
  "pubdate": "2026-09-21T09:17:06.040Z",
  "executiveSummary": "The GiveWP WordPress plugin, in versions prior to 4.16.9, is susceptible to an arbitrary shortcode execution vulnerability caused by insufficient input sanitization. This vulnerability allows unauthenticated, remote attackers to inject malicious shortcodes into donor-supplied fields, which are subsequently rendered on public-facing pages.\nThe core issue stems from a flawed shortcode stripping mechanism that fails to account for nested shortcode structures, effectively bypassing existing security filters. By crafting specific payloads that leverage this bypass, an attacker can trigger the execution of any shortcode registered within the WordPress installation.\nThe impact of this vulnerability is significant, as it can be leveraged to execute unauthorized administrative actions, exfiltrate sensitive data, or perform other malicious activities depending on the available shortcodes registered on the affected site. This flaw poses a high risk to the confidentiality, integrity, and availability of the WordPress environment. Exploitation requires no authentication or special privileges, making it accessible to any remote attacker capable of submitting input to the affected plugin fields.\nOrganizations using GiveWP are advised to update to version 4.16.9 or later immediately to address this security defect.",
  "technicalDetails": "The vulnerability originates from inadequate input validation and sanitization within the GiveWP plugin. Specifically, the plugin attempts to sanitize user-provided data intended for public display by stripping out shortcode delimiters; however, this implementation relies on a non-recursive or incomplete filtering mechanism. The logic fails to properly sanitize or neutralize nested shortcodes, which are processed by the WordPress do_shortcode() function after the initial, flawed sanitization routine has been applied.\nThe attack flow begins with an unauthenticated attacker identifying donor-supplied input fields that are reflected on the frontend. The attacker crafts a payload that uses nested shortcode syntax to circumvent the simplistic stripping logic. For example, by structuring the payload such that the outer shortcode filter only clears the outermost layer, the inner, malicious shortcode remains intact and is subsequently parsed by the WordPress shortcode engine.\nOnce the attacker submits the payload, it is stored in the WordPress database. When the victim or an administrator visits the page where this input is rendered, the plugin retrieves the stored value. Because the input was not properly sanitized, the underlying shortcode engine interprets the malicious sequence. This results in the arbitrary execution of registered shortcodes.\nThe exploitation process is as follows: 1) The attacker identifies a form or input field controlled by GiveWP that is vulnerable to unsanitized output. 2) The attacker submits a specially crafted payload designed to bypass the ineffective stripping routine, typically involving nesting techniques. 3) The malicious input is stored as legitimate donor data. 4) The plugin renders the malicious input to a public page. 5) The WordPress core processes the rendered content, triggering the execution of the injected shortcode.\nBecause WordPress shortcodes are frequently used to perform privileged operations or access sensitive internal functionality, the ability to execute arbitrary shortcodes without authentication can lead to full site compromise, unauthorized data exposure, or privilege escalation. The vulnerability is present in all versions prior to 4.16.9, affecting the plugin's core data handling logic. The attack is fully network-exposed, requiring only connectivity to the public-facing interface where the vulnerable input fields are hosted."
}