SureCart < 4.6.3 - Subscriber Account Takeover via Customer Update Access Control Flaw

CVE-2026-18480 affects SureCart before 4.6.3. A subscriber-level user can change another user's email address, including an administrator account, and trigger account takeover through password reset. Update SureCart to 4.6.3 or newer and audit customer/user mappings.

CVE-2026-18480 is a newly published broken access control vulnerability in the SureCart WordPress ecommerce plugin. The issue affects SureCart versions before 4.6.3 and can let a subscriber-level user take over another WordPress account, including an administrator account, through the customer update flow.

This is worth prioritizing because SureCart is used on ecommerce sites and has 80,000+ active installations on WordPress.org. The vulnerable path combines account/customer record confusion, user identifier exposure, and insufficient authorization checks around which WordPress account a customer update is allowed to modify.

Table of Contents

Vulnerability summary

Plugin: SureCart – ecommerce, digital downloads, subscriptions, donations, and payments
Slug: surecart
CVE: CVE-2026-18480
Affected versions: SureCart before 4.6.3
Fixed version: 4.6.3 or newer
Severity: high, with CVE Brief listing CVSS 8.8 and VulDB listing CVSS 6.3 at publication time
Attack class: broken access control / IDOR leading to account takeover
Required privilege: subscriber-level account
User interaction: none after the attacker has an account
CISA KEV: not listed at publication time

Technical cause

The CVE description says SureCart before 4.6.3 does not guarantee that the account being modified by a customer update is the same account that passed the permission check. That creates an authorization gap where a low-privileged user can target another WordPress user record instead of being restricted to their own customer profile.

The same record describes two supporting weaknesses: an attacker-controlled customer record can be associated with an arbitrary WordPress user, and customer identifiers plus email addresses can be disclosed to authenticated users. Together, those details make the takeover path reachable from a subscriber account.

The most dangerous outcome is administrator account takeover. If a subscriber can change the email address on an administrator account, the attacker can then start the normal WordPress password reset process and receive the reset message at an email address they control.

Immediate remediation

Update SureCart to 4.6.3 or newer. The current WordPress.org version is newer than the patched baseline.
Review all administrator accounts for recent email address changes.
Audit SureCart customer records that are linked to WordPress administrator, shop manager, or other privileged users.
Review new users and password reset activity since the vulnerable SureCart version was installed.
Invalidate sessions for administrator accounts if suspicious customer/user mappings or email changes are found.
Enable multi-factor authentication for administrator users to reduce the impact of email-based account recovery abuse.

WP-CLI checks

Confirm the installed SureCart version first:

wp plugin get surecart --fields=name,version,status
wp plugin update surecart
wp plugin get surecart --field=version

Then review privileged users and recent registrations:

wp user list --role=administrator --fields=ID,user_login,user_email,roles,user_registered
wp user list --role=shop_manager --fields=ID,user_login,user_email,roles,user_registered
wp user list --fields=ID,user_login,user_email,roles,user_registered --orderby=registered --order=DESC --number=50

Database review

If you need a read-only check for recent WordPress account changes, adjust the date window for your incident timeline:

wp db query "SELECT ID, user_login, user_email, user_registered FROM {prefix}users WHERE user_registered >= '2026-08-25' ORDER BY user_registered DESC LIMIT 100;"

SureCart database table names can vary by installation and plugin version. If your site has SureCart customer tables, review customer rows linked to privileged WordPress user IDs and investigate any mapping that changed unexpectedly.

Log review

Search access logs for customer update, account, and password reset activity around the suspected exploitation window. These are defensive review patterns, not exploit instructions:

grep -Ei 'surecart|customer|account|resetpass|lostpassword|wp-json' /var/log/nginx/access.log*
grep -Ei 'surecart|customer|account|resetpass|lostpassword|wp-json' /var/log/apache2/access.log*

Temporary mitigation

The correct fix is the SureCart patch. If updating is delayed, disable public account/customer profile update functionality in SureCart and require manual review for customer email changes. If the site uses custom WAF rules, restrict low-privileged access to SureCart customer update endpoints until the plugin is upgraded.

At the application level, the defensive rule is simple: every customer update must compare the authenticated WordPress user ID with the target user/customer record before changing account email, user linkage, or recovery-critical identity fields.

// Defensive validation outline only.
if ( (int) $current_user_id !== (int) $target_user_id ) {
    return new WP_Error( 'forbidden_customer_update', 'Customer record does not belong to the current user.', array( 'status' => 403 ) );
}