Gravity Forms Payfast Gateway Add-On WP Registry grade C-. High-severity findings · 1 findingWP RegistryHigh-severity findings · 1 findingOpen the reportC-

High-severity findings.

Audited release

2.7.0

Findings

1

Worst severity

high

Content hash

52fb2c7f4fa25f8f26573346… Copy

Findings

• high Unauthenticated return POST stores PAY_REQUEST_ID and admin Edit Entry reflects it unescaped

  xss_stored

  maybe_thankyou_page always calls GFAPI::update_entry_property($lead_id, 'transaction_id', $pay_request_id) from POST PAY_REQUEST_ID after only validating the checkout-minted gf_paygate_return token (no sanitization, no CHECKSUM). A payer who reaches the return URL (including after cancel) can set transaction_id to an HTML break-out. When a user with Gravity Forms entry-edit access opens that lead and clicks Edit, admin_edit_payment_transaction_id prints the stored value into an input value attribute with no esc_attr(). PaygateGFForm::get_edit_fields() does the same for legacy GF < 1.8.17.4. Observable: POST PAY_REQUEST_ID='" onfocus=alert(document.domain) autofocus="' on the return URL, then open wp-admin entry editor in Edit mode. Script runs in the administrator origin.

  src/PayGateGF.php:109-110,1368-1376

  Recommendation

  Sanitize transaction_id to a conservative charset before save. Escape with esc_attr() (and the date/amount siblings) in admin_edit_payment_transaction_id, admin_edit_payment_date, admin_edit_payment_amount, and PaygateGFForm::get_edit_fields(). Do not copy raw POST into entry properties on the return URL.

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.