s2Member ≤ 260814 – Unauthenticated Remote Code Execution

s2Member installations running version 260814 or earlier are vulnerable to unauthenticated remote code execution under a specific, documented configuration. The issue is tracked as CVE-2026-19804 and carries a CVSS score of 8.8 (High). Update to 260829 or later; the current WordPress.org release is newer still.

Vulnerability summary

• Product: s2Member – Membership Plugin for WordPress
• Affected versions: 260814 and earlier
• Fixed version: 260829
• Current WordPress.org version at publication: 260917
• CVE: CVE-2026-19804
• Severity: High, CVSS 8.8
• Attack class: Code injection leading to remote code execution
• Authentication required: No
• Researcher: Supakiad S. (m3ez), credited by Wordfence

When a site is exposed

The vulnerable path is in s2Member’s PayPal proxy return and Signup Tracking Codes feature. Exploitation requires all of the following conditions:

• s2Member 260814 or an earlier version is active.
• A Signup Tracking Codes template is configured with the documented %%first_name%% replacement code.
• The site’s PayPal Checkout flow exposes the site-global proxy verification key to the requester.

Wordfence reports that the affected value was not sufficiently sanitized before it was substituted into a PHP-evaluated tracking-code template. Because the verification key could be obtained from a PayPal Checkout AJAX response, an unauthenticated attacker could satisfy the return verification and reach the dangerous template path.

Immediate remediation

1. Update s2Member to 260829 or later immediately. WordPress.org currently offers 260917, which includes the fix.
2. If an immediate update is impossible, temporarily disable s2Member or remove the %%first_name%% replacement code from all Signup Tracking Codes templates. This is only a temporary mitigation.
3. Invalidate page, object, and CDN caches after updating so old frontend checkout responses are not retained.
4. Rotate credentials and application secrets if there is evidence of compromise. The exposed proxy verification key is site-global, so treat prior public exposure as meaningful.

Verify the installed version

With WP-CLI, confirm the installed version and update it:

wp plugin get s2member --field=version
wp plugin update s2member
wp plugin get s2member --field=version

The final command should report 260829 or a newer release. Sites using s2Member Pro should also update the Pro component and verify that its files match the vendor’s current package.

Configuration review

Review the Signup Tracking Codes setting in WordPress Admin under s2Member’s general options. If the vulnerable replacement code is present, preserve a screenshot for incident records, remove it until the plugin is patched, and then test legitimate signup attribution after the update.

You can also locate the replacement code defensively without changing data:

wp db query "SELECT option_name FROM {prefix}options WHERE option_value LIKE '%first_name%' LIMIT 50"

This SELECT-only check is a broad indicator, not proof of exploitable configuration. Confirm any result in the s2Member administration screen rather than editing serialized options directly.

Compromise checks

Because successful exploitation can execute server-side code, do not limit the response to deleting a suspicious WordPress user. Review the affected window for:

• Unexpected administrator accounts or role changes.
• New PHP files in uploads, cache, mu-plugins, or active theme directories.
• Modified plugin or WordPress core files.
• Unfamiliar scheduled tasks, active plugins, must-use plugins, or persistent database options.
• PayPal proxy-return requests followed by unusual PHP errors, outbound connections, or file writes.

Useful integrity checks include:

wp core verify-checksums
wp plugin verify-checksums --all
wp user list --role=administrator --fields=ID,user_login,user_registered
wp plugin list --status=active
wp plugin list --status=must-use
wp cron event list

Premium plugin checksum failures can be inconclusive because WordPress.org may not have reference hashes for those packages. Compare paid components with fresh vendor downloads.

Incident response

If logs or file-integrity results indicate exploitation, take the site out of public service, preserve logs and a filesystem/database snapshot, replace compromised files from trusted packages, rotate WordPress administrator passwords and hosting/database/API credentials, review all users and scheduled persistence, then restore service only after a clean verification pass.

Sources

• Wordfence Intelligence vulnerability record
• Patchstack vulnerability record
• s2Member on WordPress.org
• CVE-2026-19804 record

This article summarizes public vulnerability research and provides defensive remediation guidance. WPDeeply did not discover this vulnerability.