CVE-2026-16310 lets an unauthenticated visitor set the password on any WordPress account, administrators included, with no notification to the victim. NVD names no fixed version, the vendor’s release-notes page returns HTTP 410 Gone, and the record’s only vendor reference redirects to a sales page.
What happened
Wordfence published CVE-2026-16310 to the National Vulnerability Database at 3:17 a.m. UTC on Sunday, September 6, 2026, scored CVSS v3.1 9.8 on the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H and classified CWE-639, Authorization Bypass Through User-Controlled Key. The affected product is the commercial WordPress membership plugin MemberDash, listed in NVD under the vendor name LearnDash, in versions “0 through 1.8.5.”
The description states the problem plainly. MemberDash “is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 1.8.5 via the ‘id’ parameter due to missing validation on a user controlled key. This makes it possible for unauthenticated attackers to change the password of any WordPress user, including administrators, by supplying an arbitrary user ID during registration, and take over their account without any notification sent to the victim.”
Three things in that sentence do the work. The entry point is registration, which is by design a path open to people who do not yet have an account. The parameter is a raw user ID, supplied by the requester and used without a check that it belongs to them. And the account whose password changes receives nothing — no reset email, no “your password was changed” notice. The signal a site owner would normally rely on to notice this happening is absent by construction.
What the record does not contain is a fixed version. NVD’s configuration data gives an affected range with no upper bound below 1.8.5 and names nothing to upgrade to. The record carries exactly two references: the Wordfence threat-intelligence entry for the vulnerability, and https://www.memberdashwp.com, the product’s own domain.
That second reference does not lead to an advisory. Requested on the afternoon of September 6, www.memberdashwp.com answered HTTP 302 and redirected to https://www.liquidweb.com/software/learndash/memberdash/, a Liquid Web product page that markets MemberDash as “The most flexible membership plugin for WordPress” across three purchase tiers — Essentials, Pro, and Elite. The page carries no version number, no changelog link, no release-notes link, and no security notice of any kind.
The product’s release-notes page, at https://memberdashwp.com/release-notes/, returns HTTP 410 Gone. A 410 is not a broken link. It is the server stating that the resource is intentionally no longer available and is not expected to return, which is a deliberate configuration rather than a missing file.
There is relevant background here, and it needs labeling as secondary. MemberDash is a LearnDash add-on, and LearnDash’s ownership has changed during 2026. A WisdmLabs briefing published on May 28, 2026 states that “MemberDash has been folded into LearnDash. It’s no longer sold as a standalone product,” with existing subscriptions continuing until renewal. That piece reproduces no statement from Liquid Web or from the product’s maintainers, and its author acknowledges that “the longer-term roadmap for each add-on hasn’t been published in detail yet.” It also sits in direct tension with the Liquid Web page reached this afternoon, which is still selling MemberDash in three tiers. This publication has found no vendor statement — on end-of-life, on support status, or on this vulnerability — and does not treat the consolidation account as established.
Why it matters
Strip away the ownership question and the operational position is simple and bad. There is a 9.8 unauthenticated administrator takeover in a paid plugin, published today, and the authoritative record does not name a build that fixes it.
For a plugin distributed through WordPress.org, that gap is survivable, because the repository is itself a primary source. Earlier today this publication covered a comparable 9.8 in Frontend Admin by DynamiApps, disclosed by the same CNA at the same minute. In that case the fixed version, its release date, and the changelog text were all publicly checkable, and the source tree for every tagged release is browsable line by line. An administrator can determine their exposure without asking anyone.
MemberDash is commercial, so none of that exists. There is no public repository, no tag history, no changeset, no version-by-version download. The only way to learn which build fixes CVE-2026-16310 is to be told, and the two places a customer would look — the product’s release notes and the product’s website — return a 410 and a marketing page respectively. A paying customer with MemberDash 1.8.5 installed can read their own version number in wp-admin and then has nowhere to compare it against.
This is the third story on this site this week in which the absence of a fixed version was the operative fact rather than an incidental gap in the data. It ran with Coolify’s OAuth email-match flaw and with the AVideo batch. The pattern is worth naming: an empty fixed-version field in NVD is increasingly not a lag in the record catching up to a patch. It is the record accurately describing a situation in which there is nothing to install. Treating it as a data-entry delay, and waiting for the field to fill in, is a decision to stay exposed.
The missing notification deserves separate attention, because it changes what detection looks like. Most WordPress account-takeover scenarios leave a trace in the victim’s inbox: a reset link they did not request, or a confirmation that their password or email changed. Here the CVE states there is none. Whatever a site’s incident timeline normally hangs on — user complaints, a flood of reset emails, a support ticket — will not fire. The compromise is silent until someone looks at the database or notices the consequences of an administrator session they did not create.
There is also a structural point about registration endpoints. Registration is the one authenticated-user workflow that has to accept input from strangers, which makes it the natural place for an identifier-confusion bug to become an unauthenticated one. A membership plugin exists to run registration; that is its function. Any authorization mistake in that path starts at the maximum blast radius, because the pre-authentication reachability is not a misconfiguration to be tightened but the feature working as intended.
What to do
Determine whether MemberDash is installed and at what version. From WP-CLI, wp plugin list --status=active will show it; the affected range as published is everything at or below 1.8.5, and no fixed build is named, so a site at 1.8.5 has no upgrade target it can verify from public sources.
The attack runs through registration, so the practical mitigation is to close that path. Disable or gate public registration on any site running MemberDash — WordPress’s own “Anyone can register” setting under Settings, General, plus whatever MemberDash registration forms are published — until a fixed build is named. If the site’s business depends on open registration, put the registration endpoints behind a rate limit and a review step, and treat the plugin’s deactivation as the option to weigh against continuing to accept new signups.
Audit for prior abuse rather than assuming none, given that the normal notification signal is absent. Compare the user_pass hash modification pattern in wp_users and the password-change timestamps in your backups against your own reset request logs; any administrator whose password changed without a corresponding request is a finding. Review web server logs for requests to MemberDash registration endpoints carrying an id parameter, and check administrator accounts for changed email addresses and for sessions from unfamiliar addresses.
Rotate administrator passwords and application passwords now, not after a fix ships. Enable two-factor authentication if it is not already on; it does not prevent the password write, but it gates the login that would follow one. And open a support ticket with Liquid Web asking for the build number that fixes CVE-2026-16310 — with no public changelog, a vendor answer is currently the only way to establish it.
Sourcing note
Checked: the NVD record for CVE-2026-16310, which supplied the description quoted in full, the CVSS vector and score, CWE-639, the affected range, and the two-item reference list, and which was published and last modified at 3:17 a.m. UTC on September 6, 2026, with Wordfence as the CNA of record. The HTTP behavior of both vendor URLs was checked directly this afternoon: www.memberdashwp.com returned 302 to the Liquid Web product page, and memberdashwp.com/release-notes/ returned 410 Gone. The Liquid Web page was read for version, changelog, and security information and contained none.
Not reached: the rendered Wordfence threat-intelligence entry for this CVE, which loads its content with JavaScript and returned no text to automated fetching, so the researcher credit, Wordfence’s own publication date, and any fixed version Wordfence may list separately from NVD were not confirmed. No LearnDash or Liquid Web security advisory for CVE-2026-16310 was found. Because MemberDash is commercial, no source tree or release archive was available to inspect for a fix.
Unresolved: whether a fixed build exists at all. The ownership and consolidation background above comes from a single secondary source, WisdmLabs, dated May 28, 2026, quotes no vendor statement, and conflicts with the live Liquid Web page still selling the product; it is reported here as context and not as established fact. No exploitation of CVE-2026-16310 has been reported by any source reviewed for this story.