WPML, the multilingual plugin installed on roughly a million WordPress sites, carries an unauthenticated login bypass that pays out while a user is logging out. The flaw sits in its language-per-domain single sign-on path and can issue an attacker valid session cookies for an administrator.
What happened
The vulnerability is CVE-2026-76877, rated CVSS 8.1 and credited to researcher Yuto Hyakumoto. It affects WPML Multilingual CMS up to and including version 4.9.7; WPML 5.0.0 and later sit outside the affected range.
The mechanism is a race condition in the process_iframe_request handler. When a site serves each language on its own domain, logging out of one domain fires a cross-domain sign-on token so the other domains follow. That token is built on the logout landing page, where the browser has already discarded the authentication cookies, so WordPress returns an empty session token and the nonce collapses to the site-wide anonymous value for the current 12-hour tick. WPML then caches it in a transient keyed to the victim's user ID, with nothing tying it to the specific sign-out or the client that requested it.
Because an unauthenticated visitor can trigger that same logout flow and derive the identical nonce, and because the request gate is built from a publicly known constant, an attacker can submit a forged wpml_sso_token_domain parameter with a signed-in status to a secondary language domain. If that lands inside the 60-second SSO_TIMEOUT window before the legitimate signed-out iframe fires, WordPress issues authentication cookies for the victim.
Who is affected
- WordPress sites running WPML Multilingual CMS 4.9.7 or earlier.
- Only sites using the language-per-domain SSO feature, where each language is served from its own domain rather than a subdirectory or parameter, expose the vulnerable path.
- Any account that logs out during the race window can be captured, and an administrator account is the obvious prize.
- Sites already on WPML 5.x are outside the affected range but should confirm they are current, since the 5.x line is where the fix landed.
What to do now
Update WPML to 5.0.0 or later and bring every WPML add-on to the matching version in the same pass. WPML does not support mixing component versions, and a half-updated stack is its own source of breakage.
- Take a file and database backup before the update, then test the language switcher and a full logout and login cycle on each domain afterwards.
- If you cannot update immediately, disable language-per-domain SSO and serve languages from subdirectories or a URL parameter until the plugin is current.
- Hunt for evidence of use: unexpected administrator accounts, admin logins from unfamiliar addresses, and plugin or theme files modified around a logout event.
- If you find anything, treat the site as compromised rather than patched, and reset the WordPress salts so every existing session cookie dies.
What this means for South African businesses
Multilingual South African sites commonly run English, Afrikaans and isiZulu content, and the agencies that build them often reach for exactly this per-domain configuration. The exposure is narrow but not theoretical: the attacker has to catch a user mid-logout, and automated scanners run that loop continuously against WordPress because a single hit on an administrator account ends the engagement. Most owners will never notice the update prompt, since WPML is a commercial plugin updated outside the normal WordPress repository flow.
Source: Wordfence Intelligence vulnerability record for WPML Multilingual CMS.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.