GiveWP WordPress plugin vulnerabilities

The GiveWP WordPress plugin before 4.19.0.1 does not perform a capability check when handling donor address changes. This allows users who have been granted donor-report (view) access but not donor-edit access to add, modify, or delete the stored address of any donor on the site.

The GiveWP WordPress plugin before 4.19.0.1 does not correctly determine which page a page-capability request applies to. This allows users with a custom fundraising role to edit, publish and read pages owned by other users, including administrators.

The GiveWP WordPress plugin before 4.19.0.1 does not properly sanitise and escape one of its donation form template settings before outputting it inside an HTML attribute. This allows users with a custom form-editing role to inject arbitrary web scripts that execute in the browser of any visitor or administrator who opens the affected donation form.

The GiveWP WordPress plugin before 4.19.0.1 does not properly validate a user-supplied filename before reading it from disk. This allows users with a high-privilege custom role to perform path traversal, disclose the contents of JSON-parseable files anywhere on the server, and overwrite the plugin's stored configuration.

The GiveWP WordPress plugin before 4.19.0.1 does not perform any status or capability check when rendering a donation form on a public front-end route. This allows unauthenticated visitors to view the content and settings of unpublished (draft, pending, private and scheduled) donation forms that WordPress core otherwise keeps non-public.

The GiveWP WordPress plugin before 4.16.3 does not escape a donation-form template setting before outputting it in an HTML attribute. Users with GiveWP Worker role and above can inject arbitrary web scripts that execute on the public donation form viewed by visitors.

The GiveWP – Donation Plugin and Fundraising Platform plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'name' parameter in all versions up to and including 4.13.0 due to insufficient input sanitization and output escaping. Unauthenticated attackers can inject arbitrary web scripts into pages that execute whenever a user accesses an injected page. Avatars must be enabled in the WordPress install to exploit the vulnerability.