MyHome Core CVE-2026-15980: critical authentication bypass through account activation

CVE-2026-15980 entered NVD on 30 August with a CVSS 3.1 score of 9.8 (Critical). It affects MyHome Core, a component of the commercial MyHome real-estate theme for WordPress, through version 4.4.5 inclusive. Under a specific configuration, an unauthenticated attacker can obtain an activation token for an unconfirmed account and then a valid authentication cookie for that account—even when the account is an administrator.

The mechanism combines two weaknesses: missing authorisation in the send_link() AJAX handler and improper token validation in activate(). Exploitation nevertheless has concrete prerequisites. The theme must use the older legacy/WPBakery mode, front-end registration and confirmation email must be enabled, and the target account must not yet have the myhome_agent_confirmed user metadata value.

That distinction is essential. The CVE does not say that every site with the MyHome theme is automatically compromised. It says that a site with an affected version and reachable activation workflow can expose the session of an arbitrary unconfirmed account. Organisations therefore need to inspect both code version and feature and account state.

Account activation is an authentication protocol

Teams sometimes treat activation-link delivery as an email convenience. It is actually part of a protocol proving control over an identity. An endpoint generating or resending a token must decide who may request the operation, for which account, and whether delivery goes exclusively to a previously established channel.

The second boundary is the token consumer. activate() should bind a random, single-use, expiring secret to one user and one operation. It should compare that secret safely, reject replay and change account state only after successful verification. Merely presenting a token-shaped value cannot be sufficient to issue an authenticated cookie.

The CVE shows what happens when both ends place too much trust in the request. An anonymous client reaches activation-link functionality, while the activation handler does not correctly enforce proof. The final asset is not an “email confirmed” flag; it is a complete WordPress session carrying the role already assigned to the selected account.

Exploitation prerequisites and practical blast radius

The first prerequisite is MyHome Core 4.4.5 or earlier. Checking only the parent theme version in the dashboard is insufficient. The core plugin or component may have a separate update lifecycle, and the executable copy on disk may differ from the package stored in a deployment repository.

The second prerequisite is legacy/WPBakery mode. Installations using another registration flow may not expose the vulnerable handler combination. Front-end registration and email confirmation form the third requirement. The fourth is an unconfirmed target account without myhome_agent_confirmed.

The most severe scenario involves an administrator left in an unconfirmed state. It may be an account created during migration, a break-glass account, a user manually added before onboarding completed or a test remnant. Once an administrator is impersonated, an attacker may install or change plugins and themes, create users, read customer information, alter content and establish persistence.

Taking over a lower-privilege account still matters. On a property platform, an agent may access leads, contact details, unpublished listings, messages and files. Further impact depends on other plugins, CRM integrations, role customisations and secrets visible in the administration interface.

What to establish today

Inventory every production site, staging environment, demonstration copy and fallback domain. Staging is often less protected while sharing the same database or credentials. Determine the MyHome Core version from the dashboard, filesystem, package manifest and integrity scanner. If sources disagree, the PHP code actually loaded by the site is authoritative for exposure.

Check whether WordPress permits registration, whether MyHome exposes a front-end form, whether email confirmation is required and whether legacy/WPBakery mode is active. Then count unconfirmed accounts and their roles without placing personal details in a broadly accessible report. Usernames and email addresses should be handled as sensitive data.

Review AJAX exposure at the CDN, WAF and reverse proxy. Do not assume that a path called admin-ajax.php is restricted to administrators. WordPress intentionally exposes some AJAX actions to signed-out visitors. The callback and its checks—not the shared endpoint name—define security.

Updating and temporary controls

Install a vendor release explicitly documented as correcting CVE-2026-15980. At publication time, the CVE record confirms affected versions through 4.4.5 but does not explicitly identify a fixed release number. Do not assume that any package with a higher version necessarily contains the remedy. Check the vendor changelog, advisory or support channel, create a backup and test registration after deployment.

Until a verified update is deployed, disable front-end registration and confirmation through the affected mechanism if the business can operate temporarily without them. Consider deactivating MyHome Core on the public site or moving away from legacy mode, but assess content impact first. Remove or disable unconfirmed administrative accounts that the organisation does not need.

A WAF can temporarily restrict unauthenticated calls to the specific send_link-related action, but test the rule against legitimate onboarding. Blocking all of admin-ajax.php will break unrelated features and is not a sensible remedy. Rate limiting reduces automation but does not fix the logic flaw if a single correctly shaped sequence is sufficient.

Retesting without risking real users

After updating, create only a dedicated test user with the minimum role. Verify that a token request cannot select another account, delivery uses the correct channel, the token is random and expires, and replay is rejected. An activation attempt with one changed character must fail without issuing a cookie.

Confirm that a session created by legitimate activation belongs to exactly the intended account and has the expected role. Do not test against a real administrator or customer. The suite should also cover registration disabled, email confirmation disabled, non-legacy mode and a direct endpoint request missing required parameters.

Detection and response to possible takeover

Review AJAX requests related to link delivery and activation, especially sequences targeting several account identifiers, responses followed immediately by session creation and sources with no preceding registration activity. Correlate these requests with email delivery, mail-provider events and login logs.

Look for sessions created for a previously unconfirmed user without a corresponding click through the delivered link. For administrators, inspect plugin installation, file changes, new accounts, role modifications, option edits, application-password creation and unusual exports. PHP files changed after a suspicious login may indicate persistence beyond the stolen cookie.

If privileged account takeover cannot be ruled out, invalidate all WordPress sessions, reset passwords and application passwords, rotate salts and secrets accessible through the dashboard, and compare files against trusted packages. Inspect the database for new administrators, scheduled tasks and modified options. Updating the component does not remove a backdoor installed before remediation.

Design lesson for WordPress and other platforms

Activation tokens, password resets, magic links and invitation codes are credentials. Each requires high entropy, a short lifetime, single use, binding to one user and purpose, and a complete audit trail. A token-generation endpoint must not let an anonymous party select an arbitrary target without additional proof.

The authenticated cookie should be issued only after an atomic transition from “pending” to “confirmed”. Distributing that decision across callbacks increases the chance of race conditions and inconsistent checks. Security testing should cover the complete account-state graph, not only the login form.

Source facts and Breachroad conclusions

The two affected functions, configuration prerequisites, version range and score come from the CVE record authored by Wordfence as CNA and from NVD. Blast-radius scenarios, telemetry, retesting and response guidance are Breachroad conclusions. The sources do not report confirmed active exploitation of CVE-2026-15980.

Sources

Activation is part of the authentication boundary and belongs in developer and administrator education. Breachroad provides cybersecurity training and can assess comparable state and identity flaws in a web and API penetration test.