Medium-severity findings.

Audited release

1.4.2

Findings

2

Worst severity

medium

Content hash

358dd9ca1353eb46af7d64de… Copy

Findings

• medium Unauthenticated donation-lockout bypass via public GET ?unlock=true

  missing_auth

  On any wp-admin load, enqueue_scripts() calls create_custom_page(), which publishes a public page titled 'Meu Template' with no capability or nonce check (wp_insert_post post_status=publish). the_content then include()s public/templates/lkn-antispam-custom-page.php on that page. Any visitor who requests it with ?unlock=true (PHP loose comparison, so 1/true/yes/false all work except 0) runs give_update_option('lkn_antispam_spam_detected_block_all', false) and unschedules the auto-unlock cron, then wp_redirect()s to https://{SERVER_NAME}/wp-admin/edit.php?... with no current_user_can, nonce, or exit. Admin JS (lkn-antispam-for-givewp-link.js) advertises the permalink+'?unlock=true'. When the 'Block All Donations' feature has locked gateways, Lkn_Antispam_Helper::block_all_payments returns an empty gateway list; this GET immediately re-enables them. The page is enumerable via REST /wp/v2/pages and the predictable slug meu-template. Redirect uses SERVER_NAME rather than admin_url()/wp_safe_redirect.

  public/templates/lkn-antispam-custom-page.php:3-12

  Recommendation

  Do not publish a front-end page for this. Handle unlock on a GiveWP settings admin-post/AJAX action that checks current_user_can('manage_give_settings') (or manage_options) and a dedicated nonce, then wp_safe_redirect(admin_url(...)) and exit. Remove create_custom_page() from admin_enqueue_scripts; if a helper page is required, create it privately and capability-gate the template. Delete any existing 'Meu Template' page on upgrade.

• medium reCAPTCHA v3 skipped on Visual Form Builder donations when give_ajax is present

  unsafe_input

  validate_donation_react_form() is hooked to givewp_donate_controller_donation_created (GiveWP DonateController::donate, which persists the donation then continues to the gateway). It always runs IP/rate checks, but recaptcha is delegated to validate_recaptcha($donation, $_POST). That helper returns early unless is_plugin_active_and_not_ajax() is true, which is simply 'enabled' === antispam option && !isset($data['give_ajax']). An unauthenticated client posting to ?givewp-route=donate can omit g-recaptcha-response and set give_ajax=1; recaptcha is not verified while the donation still proceeds. On legacy give_checkout_error_checks the same skip exists, but GiveWP treats give_ajax as a validation-only preflight and give_die()s before charging, so that path does not complete a payment. The v3 controller does not.

  public/partials/lkn-antispam-for-givewp-actions.php:116-172

  Recommendation

  Never treat an attacker-controlled give_ajax flag as a recaptcha skip on DonateController. Verify g-recaptcha-response (urlencode it, fail closed on missing/invalid JSON) on every request that can create a payment. If a legacy AJAX preflight must skip a one-time token, key that off wp_doing_ajax() combined with GiveWP's own is-preflight behavior, not isset($_POST['give_ajax']).

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.