ifthenpay | Payments for SureCart
Audited at releasev1.0.0WordPress PluginAudited 4 days agokimi-k3 + deepseek-v4-flash
Adds ifthenpay payment methods to SureCart: Multibanco reference, MB WAY, and ifthenpay Gateway (cards, Apple Pay, Google Pay).
D
Stable
Total Findings
85
Security Grade
C
Security Findings
85Critical1
High9
Medium34
Low30
Info11
Executive Summary
Is ifthenpay | Payments for SureCart secure? In WP HealthKit's independent 2026 audit, ifthenpay | Payments for SureCart received an overall risk of CRITICAL and a report-card grade of D across 85 findings (1 critical, 9 high severity).
The audited portion of this SureCart payment gateway integration is generally well-engineered: every admin-post handler and AJAX endpoint enforces both current_user_can('manage_options') and nonce verification via a single shared nonce action, all $_GET/$_POST reads are unslashed and sanitized, output is consistently escaped (esc_html/esc_attr/esc_url/wp_kses_post), and wp_safe_redirect is used for all post-action redirects. The settings UI is read-only-safe (screen-context $_GET checks are properly annotated and perform no state changes), and the API layer cleanly separates three ifthenpay hosts behind a shared transport with WP_Error propagation. The most significant issue is in the webhook anti-phishing validation helper: IfthenpayHelper::is_valid_secret_key() accepts base64(raw_key) as a universally valid callback secret, and for legacy Multibanco accounts that raw key is the 5-digit entity code — a value that is printed on every Multibanco reference shown to customers and is therefore effectively public. An attacker who places (or sees) any legacy Multibanco order can compute base64(entity) and potentially forge payment-confirmation callbacks. The callback controller itself was not among the audited files, so the exploit ceiling depends on additional amount/order validation there. Remaining findings are low-severity logic and hygiene items: a phone-normalization edge case that strips leading zeros before checking the country code, no upper bound enforced server-side on expiry-day settings, and a payment-reference fallback that truncates checkout IDs to 8 characters, risking collisions.