CVE-2026-76877: 
WordPress 취약점 분석 및 완화

CVE-2026-76877 is an Authentication Bypass via Race Condition vulnerability in the WPML Multilingual CMS plugin for WordPress, affecting versions up to and including 4.9.7. The flaw resides in the process_iframe_request function's language-per-domain Single Sign-On (SSO) handler, which generates a predictable cross-domain sign-in token during the logout flow that an unauthenticated attacker can independently derive and exploit within a 60-second window. It was published on November 10, 2026, with a patch advisory simultaneously released via the GitHub Advisory Database (GHSA-2mcx-4x33-hmm3). The vulnerability carries a CVSS v3.1 base score of 8.1 (High) (GitHub Advisory).

The root cause is classified as CWE-287 (Improper Authentication). During the logout landing page flow, wp_create_nonce('wpml_sso') is called after the browser has already discarded its authentication cookies, causing wp_get_session_token() to return an empty string. This collapses the generated token to the shared anonymous nonce for the current 12-hour tick — a value that is not user-bound and is independently derivable by any unauthenticated party. The resulting token is stored in the wpml_sso_user_<token>_<sha256('wpml_sso'.$domain)> transient mapped to the victim's user_id with no binding to the specific sign-out action or requesting client. Because the is_iframe_request() gate conditions (the per-domain SSO started transient and domain-hash derived from the public constant SSO_NONCE) are fully computable, an attacker can submit a forged wpml_sso_token_domain parameter with a wpml_user_signed_in status to a secondary language-domain endpoint before the legitimate wpml_user_signed_out iframe fires, causing WordPress to issue authentication cookies for the victim (GitHub Advisory).

Successful exploitation allows an unauthenticated remote attacker to gain full authenticated access to any WordPress user account — including administrator accounts — that is actively in the process of logging out during the 60-second race window. With administrator-level access, an attacker could install malicious plugins, create backdoor accounts, exfiltrate sensitive site data, or deploy web shells, leading to complete site compromise. The confidentiality, integrity, and availability impacts are all rated High (GitHub Advisory).

As of the disclosure date (November 10, 2026), there is no public proof-of-concept exploit code and no evidence of in-the-wild exploitation. No threat actor attribution has been reported, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The attack complexity is rated High due to the requirement to win a 60-second race condition window against an actively logging-out user, which limits opportunistic exploitation but does not eliminate targeted attack scenarios (GitHub Advisory).

1. Reconnaissance: Identify WordPress sites running WPML Multilingual CMS version 4.9.7 or earlier with language-per-domain SSO enabled. This can be done via HTTP response headers, plugin enumeration, or public WordPress plugin scanners.
2. Derive the anonymous nonce: Trigger the logout confirmation flow on the target site at wp-login.php?action=logout from an unauthenticated session. Since wp_get_session_token() returns an empty string at this stage, the resulting wp_create_nonce('wpml_sso') value collapses to the shared anonymous nonce for the current 12-hour tick, which the attacker can independently compute.
3. Compute the transient key: Using the publicly known constant SSO_NONCE, compute the domain hash sha256('wpml_sso'.$domain) for the target secondary language domain. Confirm the per-domain SSO started transient is active (set when a legitimate user begins the logout flow).
4. Race the victim's logout: Monitor or time the attack to coincide with a legitimate privileged user (e.g., an administrator) initiating a logout. The exploitation window is 60 seconds (SSO_TIMEOUT).
5. Submit forged SSO token: Send a crafted HTTP request to the secondary language-domain endpoint with the forged wpml_sso_token_domain parameter and wpml_user_signed_in status before the legitimate wpml_user_signed_out iframe fires.
6. Receive authentication cookies: WordPress processes the forged token, looks up the victim's user_id from the transient, and issues valid authentication cookies for the victim's account to the attacker, granting full authenticated access (GitHub Advisory).

• Network: Unusual HTTP requests to secondary language-domain endpoints containing wpml_sso_token_domain parameters from IP addresses not associated with legitimate users; rapid sequential requests to wp-login.php?action=logout from unauthenticated sessions followed by SSO token submission requests.
• Logs: WordPress authentication logs showing new authenticated sessions for administrator or privileged accounts originating from unexpected IP addresses immediately following a logout event; access logs showing requests to language-domain SSO endpoints with wpml_user_signed_in status from unauthenticated clients.
• File System: Unexpected new WordPress admin accounts, newly installed plugins, or modified theme files following a suspicious authentication event.
• Process/Behavior: Sudden privilege escalation activity in WordPress admin panel (plugin installs, user creation, settings changes) from sessions with no prior login history on the originating IP (GitHub Advisory).

Users should upgrade the WPML Multilingual CMS plugin to a version newer than 4.9.7, which contains the fix for this vulnerability. As an interim measure, administrators can disable the language-per-domain SSO feature if it is not required for site operation, which removes the vulnerable code path. Additionally, reviewing and monitoring authentication logs for suspicious cross-domain sign-in attempts and implementing rate limiting on SSO token validation requests are recommended defensive measures (GitHub Advisory).

The vulnerability was noted on Mastodon via @thehackerwire and the @cve account on infosec.exchange shortly after disclosure on November 10, 2026. Coverage was picked up by standard vulnerability aggregators including VulDB, CVEFeed, and Vulners. No significant vendor statements beyond the patch release or notable independent researcher commentary have been identified at this time (GitHub Advisory).