New24/7 monitoring and daily cloud backups now included in every Shield Pro plan.

Security14 August 20268 min read

Wishlist Member account takeover: unauthenticated mergewith bug in 3.34.1

Share

Wishlist Member account takeover is possible without logging in on WishList Member X through 3.34.1. Wordfence reports that a mergewith parameter can be pointed at a WordPress user the attacker does not own. If that user is an administrator, they own the site. Update first. Then look at who is on the Users screen.

Running WishList Member?

Update the plugin first. If you cannot get a build newer than 3.34.1, or the site already has mystery admins, we can do a full WordPress malware removal from £99.99.

Get the site checked

What this Wishlist Member account takeover actually is

WishList Member is a commercial membership plugin. Course sites, coaching programmes, and paid communities use it to gate content and take payments. If it is installed, it is usually doing the money part of the site, not sitting unused in a forgotten folder.

Wordfence published an advisory titled Wishlist Member X 3.34.1: unauthenticated account takeover via the mergewith parameter. Their naming matches the rest of the WishList Member X intel list: versions up to and including 3.34.1 are in scope. Unauthenticated means the attacker does not need a membership, an admin session, or a stolen password. Reaching the site is enough.

In plain English: the plugin has a way to attach a new registration or payment to an existing WordPress user so someone does not end up with two logins. That attachment is what mergewith is for. The bug is that the plugin trusted that value without proving the requester owned the target account. Point it at the wrong user and you are sitting in their session. Point it at an administrator and the site is gone.

We are not going to walk through a request. You do not need one to defend the site. Patch, then audit users. That is the job.

Who is at risk

If WishList Member (WishList Member X) is active and the version is 3.34.1 or older, treat the site as in scope. Check Plugins > Installed Plugins, or the version string inside the WishList Member screens. Premium plugins often update from the vendor, not from wordpress.org, so “I click Update All on Tuesdays” is not a guarantee this one moved.

This is worse than “a subscriber can be annoying.” The May 2026 WishList Member bugs (CVE-2026-6419, CVE-2026-6895, and neighbours) needed a Subscriber-level login first. This one does not. Open registration is not a prerequisite. A membership paywall does not save you. The public front of the site is the front door.

Two extra gotchas that matter on real membership sites:

  • Levels can map to WordPress roles. WishList Member can assign a WordPress role when someone joins a level. If any level grants Administrator (or even Editor), a taken-over member account is not “only” a content leak. It is wp-admin.
  • Duplicate-account handling is a feature, not a hidden switch. The vendor documents preventing duplicate shopping cart registrations and letting existing members add a level without a second login. That is legitimate product behaviour. The vulnerability is the unauthenticated abuse of the parameter that glues those flows together, not the idea of merging itself.

How the mergewith bug fits together

You do not need an exploit write-up. The shape is enough, and it is the same shape we keep seeing in membership plugins.

  1. A public flow accepts a user identifier. Registration, a payment return, or a related front-end request includes a mergewith value that names an existing WordPress user.
  2. The plugin does not prove you own that user. No login. No capability check that would stop a stranger. The value is trusted.
  3. Accounts get glued together, or the attacker is treated as that user. Membership levels, profile data, and the WordPress role travel with the account.
  4. Aftermath. From an administrator session the rest is ordinary: new admin users, plugin ZIPs, must-use droppers, wp-config.php in someone’s pocket. Same cleanup story as the BdThemes supply chain mess last week, minus the poisoned JSON.

If that last stretch sounds adjacent to WordPress XSS2Shell, it is only from a site-owner point of view: security issue published, patch available or imminent, do not wait for a quiet Sunday. XSS2Shell started on wp-login.php. The WordPress 7.0.4 Postscript bug started in the Media Library. This one starts in the membership plugin you installed on purpose.

This plugin has had a rough year

WishList Member is not a one-CVE product. In May, Wordfence disclosed a cluster of High issues through 3.30.1 where a Subscriber could pull or rotate the plugin’s REST API secret, create a membership level mapped to Administrator, and register a new admin. Patches landed in 3.31.x. The wlm3_export_settings advisory is the readable one if you want the older chain in one place.

3.33.0 (June) had a Security section in the vendor changelog: tighter payment notifications, team and API access, login and profile hardening. 3.34.0 (6 July) hardened secrets used by some payment integrations. None of that is a reason to assume 3.34.1 is fine. A later unauthenticated account takeover means those earlier fixes did not cover this path.

Check the WishList Member changelog for anything newer than 3.34.1 and take that build. Wordfence’s slug uses 3.34.1 as the last affected release, the same way their 3.30.1 listings worked. If Dashboard > Updates does not offer a newer package yet, pull it from your WishList Member account. Do not sit on 3.34.1 because the public notes page still looks quiet.

What to do about this Wishlist Member account takeover today

  1. Update WishList Member past 3.34.1. Confirm the version under Plugins > Installed Plugins, or inside WishList Member itself. If the plugin is inactive but still installed, update or delete it. Inactive is not the same as gone, and leftover copies get forgotten.
  2. Audit WordPress users. Users > All Users. Sort by registered date. Look at Administrators first, then anyone with a role you did not assign. WP-CLI is the honest view if you have SSH: wp user list --role=administrator. The dashboard can lie after a takeover. See managing WordPress user roles if you need a refresher on what each role can actually do.
  3. Look at membership levels and role maps. In WishList Member, check which levels grant a WordPress role. A “Gold” level that quietly assigns Administrator is a loaded gun even after the plugin is patched. Change that mapping. Then re-check the Users screen.
  4. Reset remaining admin passwords and turn on two-factor authentication. Reset the admin password, then enable WordPress 2FA. If you also keep site credentials in BugShield, the same habit applies to our own 2FA and Active Sessions.
  5. If you were late: review unexpected plugins (including mu-plugins), Application Passwords, and new users from the last few weeks. For a proper pass, see WordPress malware removal and Fixing a Hacked Site.
  6. Take a clean backup after you patch, so you are not rolling back onto a known-bad plugin build. Managed backups exist so that step is not a ZIP on someone’s laptop.

How to tell if someone already used it

There is no magic log line labelled “mergewith attack.” Look for the residue instead.

  • Administrator accounts you did not create, especially recent ones with throwaway emails
  • Existing admins whose email or password suddenly “stopped working” for the real owner
  • Members who gained a WordPress role they never had
  • Plugin folders you did not install, and anything under wp-content/mu-plugins
  • Payment or registration traffic that does not match real customers

Unknown does not mean safe. If WishList Member was on 3.34.1 or older and exposed to the internet, do the user audit even if the dashboard looks calm. File integrity tools will not catch an account takeover. The files can be clean. The Users table is where this one lives first.

If anything on that list shows up, stop poking at random files. Half-cleaning a backdoor is how it comes back next week. The work is the same as our hacked WordPress site case study: files, database, and the entry point. Deleting one user and hoping is not that.

Wishlist Member account takeover and BugShield

Premium membership plugins are easy to leave a version behind. The update is not in the wordpress.org button. It sits in a vendor account someone last logged into in 2024. That is how a site stays on 3.34.1 while the advisory is already public.

On Shield plans we treat plugin updates as part of managed updates, next to monitoring and backups. That includes commercial plugins when we have the licence in the Password Vault. Shield Pro adds malware scanning when you need a second pair of eyes on files after a scare. Broader reading: website security and WordPress security in the knowledge base.

If you only need this one plugin updated, or the site already looks compromised, request a one-off fix or go straight to malware removal. August has been busy enough without leaving a membership plugin as the unlocked door.

Update WishList Member past 3.34.1. Then look at who can still log in as administrator. That is the whole job for most sites today.