CVE-2026-108066

Executive Summary

CVE-2026-108066 is an object-level authorization flaw (CWE-639) in the WP 2FA WordPress plugin before version 4.2.0. The plugin executes the two-factor authentication (2FA) removal routine without verifying that the requesting actor has edit capability over the target account, so a site administrator on a WordPress Multisite network can strip 2FA from users belonging to other sites. Impact is limited — confidentiality and availability are unaffected (C:N/A:N) and the integrity loss is scoped to the security state of a subset of accounts (I:L) — but the weakened authentication posture materially enables downstream account takeover.

Technical Analysis

The defect is a missing object-level capability check on the 2FA deconfiguration path. Functionally, the plugin exposes an administrative action that removes a user's stored 2FA configuration (in WordPress terms, the user-meta record holding the plugin's TOTP/2FA enrolment state). That action verifies that the caller is an administrator — a role gate — but does not verify that the caller is authorized to edit the specific user object the action targets. This is the classic object-reference/authorization split mapped to CWE-639 (Authorization Bypass Through User-Controlled Key): the target user is selected by a client-supplied identifier rather than by a server-side check of the caller's relationship to that object.

WordPress ships current_user_can( 'edit_user', $user_id ) precisely for this boundary. It is a meta-capability that resolver logic maps against blog membership: a Multisite administrator holds edit rights over users of their own site and not over users of sibling sites (outside the network super-admin role). A role-only check such as a bare administrator capability test therefore returns true on Multisite for the wrong reason, and the plugin proceeds to remove the 2FA configuration of a user outside the caller's authority.

Attack surface and preconditions:

• Vector is Network (AV:N), complexity Low (AC:L), no user interaction required from the victim (UI:N).
• Privileges Required are High (PR:H): the actor must already be an administrator on one site within the Multisite installation.
• Scope is Unchanged (S:U) — the effect is confined to the target user's plugin configuration state, not to a broader security authority of the plugin.
• No confidentiality (C:N) or availability (A:N) impact; only integrity (I:L), because a security control on the target account is removed.

The description explicitly narrows the trust-boundary crossing to WordPress Multisite. On a conventional single-site install the administrator already holds blanket user-management authority, so the missing object-level check is latent rather than exploitable — there is no privilege the actor does not already legitimately possess. CVSS 2.7 reflects this: the vulnerability is real and cross-tenant on Multisite, but it neither discloses data nor degrades availability and requires an already-high-privileged actor. EPSS is 0.00220 (≈11.7th percentile), indicating no observed exploitation volume.

Important scoping note for detection and response: because no public advisory text, changelog diff, or CVE-to-commit mapping was supplied, the exact request method, nonce handling, AJAX action name, or REST route involved in the removal routine is not derivable from the available data. This report does not speculate on those identifiers. The mechanism above is fully derivable from the NVD description; implementation-level naming is not, and is left deliberately unspecified.

Exploitation Scenarios

No public proof-of-concept, Nuclei template, or exploit code was identified for this CVE. The following chain is inferred from the vulnerability class (CWE-639 object-level authorization bypass) and the vendor-supplied description; it uses only the behavior and boundary the description states.

1. Reconnaissance and target identification. The adversary must first hold an administrator account on at least one site within a WordPress Multisite network. In this deployment it is normal for a site administrator to see, through the network's user listings, that other sites and other users exist — the administrator function is per-site, not network-wide, but the user base is shared in the network tables. The adversary enumerates user identifiers belonging to other sites in the network, focusing on accounts they are not permitted to edit (site administrators, privileged operators, or any account that is a 2FA-enrolled target of interest on a sibling site).

2. Triggering the flaw class. The adversary invokes the plugin's 2FA-removal action while supplying an identifier for a target user outside their own site. The plugin authorizes the request on the basis of the caller's administrator role but never evaluates whether that caller holds edit authority over the referenced user object. The authorization decision thus succeeds for the wrong object, and processing continues against the out-of-scope account.

3. Payload and execution at the class level. The "payload" is not code execution; it is a single authorized-looking administrative request whose only distinguishing property is that the referenced user object lies outside the caller's site. Because there is no user interaction (UI:N) and complexity is low (AC:L), success hinges solely on the request reaching the handler with a valid administrator session. No victim action — no clicking, no OTP prompt — is required for the removal to take effect.

4. Post-exploitation impact. The target account loses its second authentication factor. The direct integrity impact is bounded (I:L), but the strategic consequence is disproportionate to the base score: any account whose 2FA is stripped becomes reachable with a single factor. From there an adversary can attempt credential stuffing, password spraying, or credential replay against the now-single-factor account, and any subsequent 2FA-dependent policy (privileged-access gating, conditional access for administrators) silently stops applying to that account. On a Multisite network, this allows a low-tier site administrator to systematically downgrade the authentication strength of accounts on other tenants — a cross-tenant trust failure in an otherwise segregated deployment.

Absent evidence of in-the-wild exploitation: EPSS places this CVE in the low-probability band, it is not in CISA KEV, and no exploit artifacts were found. Treat the chain above as the plausible abuse path, not an observed campaign.

Impact Assessment

Business impact is best characterized as authentication-integrity erosion rather than data breach. CVSS subscores — AV:N / AC:L / PR:H / UI:N / S:U / C:N / I:L / A:N — yield 2.7: remotely triggerable with low skill, but requiring a pre-existing administrator foothold and producing only low-severity integrity loss with no confidentiality or availability effect. The qualitative picture is more serious in one specific deployment model, WordPress Multisite with per-site tenants: a customer administrator on one site can degrade the security posture of a neighboring tenant's operators. For a managed WordPress host, a large multisite intranet, a university deployment, or any multi-tenant network where tenant isolation is contractually or regulatorily expected, that is a cross-tenant security-control bypass even though the raw score is low. Affected systems are any WordPress Multisite installation running WP 2FA prior to 4.2.0. Blast radius is bounded to the 2FA configuration state of users the actor is not entitled to edit; it does not extend to filesystem access, code execution, or credential disclosure. On single-site installs the defect is latent and non-exploitable. Aggravating factors: 2FA-stripped administrator accounts become single-factor and are attractive targets for credential attacks; the action may not generate the alerts normally associated with account modification because it removes a factor rather than adds or resets one. Mitigating factors: no PoC, no KEV, no observed exploitation, and a low EPSS.

Detection Guidance

Detection for this CVE is behavioral: there is no network signature for a missing authorization check, no patch diff to hunt for, and no exploit artifact to match. The high-value signals are (a) anomalous removal of 2FA enrolment for users outside the actor's site and (b) the request pattern against the plugin's administrative endpoints. Because the concrete action name/route is not derivable from the supplied data, the web-layer rules below are generic plugin-request detections and must be tuned to the observed handler on your deployment.

Sigma Rule

title: WP 2FA Configuration Removal by Cross-Site Multisite Administrator
id: 6f4c1a72-9d2b-4e88-b5a1-0c3d7e9f1b44
status: experimental
description: >
  Detects the removal of a WP 2FA configuration (CVE-2026-108066) where the
  acting WordPress Multisite administrator is not the target user, consistent
  with a missing object-level capability check on the 2FA removal routine.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-108066
author: Security Analytics
date: 2026-01-01
logsource:
  product: wordpress
  service: audit
detection:
  selection_plugin:
    plugin:
      - 'wp-2fa'
      - 'wp-2fa-*'
  selection_action:
    action|contains:
      - 'remove_2fa'
      - 'disable_2fa'
      - 'delete_2fa'
      - 'deactivate_2fa'
      - '2fa_remove'
      - 'reset_2fa'
  selection_cross_user:
    actor_user_id: '*'
    target_user_id: '*'
  condition: selection_plugin and selection_action and selection_cross_user
  # Post-filter in the SIEM: alert only when actor_user_id != target_user_id AND
  # the actor does not hold edit_user capability over target_user_id (multi-site).
falsepositives:
  - Legitimate network super-admin resetting a locked-out user's 2FA
  - Automated account lifecycle or IAM-driven 2FA offboarding
level: medium
tags:
  - attack.credential_access
  - attack.defense_evasion
  - attack.t1556
  - attack.t1562.001
  - cve.2026-108066

YARA Rule

rule CVE_2026_108066_WP2FA_Object_Authz_Gap
{
    meta:
        description = "Hunts WP 2FA plugin builds predating the object-level capability check on the 2FA removal routine (CVE-2026-108066, CWE-639)"
        author      = "Security Analytics"
        reference   = "https://nvd.nist.gov/vuln/detail/CVE-2026-108066"
        date        = "2026-01-01"
        severity    = "medium"

    strings:
        // Plugin identity markers (present in all WP 2FA builds)
        $p1 = "wp-2fa" ascii wide nocase
        $p2 = "WP_2FA" ascii wide nocase
        // Risk indicators: capability-check primitives that MUST guard the
        // object-level removal path when present.
        $c1 = "current_user_can" ascii
        $c2 = "edit_user" ascii
        // Removal-path indicators (Plugin family naming, not a specific action)
        $r1 = "remove_2fa" ascii nocase
        $r2 = "disable_2fa" ascii nocase
        $r3 = "delete_2fa" ascii nocase
    condition:
        uint16(0) == 0x3C3F or uint32(0) == 0x464C457F or true
        and any of ($p1, $p2)
        and 1 of ($r1, $r2, $r3)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-108066 WP 2FA potential out-of-scope 2FA removal request (plugin endpoint)"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"wp-admin"; http.uri; content:"wp-2fa"; http.uri; pcre:"/(remove|disable|delete|deactivate|reset)[_-]?2fa/iR"; http.request_body; content:"user"; nocase; classtype:attempted-user; reference:cve,2026-108066; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-108066; metadata:service http, affected_product "WP 2FA < 4.2.0"; sid:2026108066; rev:1;)

Elastic Detection

sequence by user.id with maxspan=30s
  [ authentication where event.outcome == "success" and user.roles : "administrator" ]
  [ any where event.category : "web" and url.path : "*wp-2fa*" ]
  [ any where event.category : "web" and
      url.path : ("*remove*2fa*", "*disable*2fa*", "*delete*2fa*", "*deactivate*2fa*", "*reset*2fa*") and
      http.request.method == "POST" ]

Splunk SPL Query

index=web OR index=wordpress sourcetype IN (access_combined, wordpress_audit, wordpress)
| eval actor=coalesce(wp_user_id, user_id, user)
| eval target=coalesce(target_user_id, affected_user_id, target)
| where (like(lower(_raw), "%wp-2fa%") OR like(lower(uri),"%(remove|disable|delete|deactivate|reset)%2fa%"))
| where isnotnull(actor) AND isnotnull(target) AND actor!=target
| stats count min(_time) AS first_seen max(_time) AS last_seen
        values(uri) AS endpoints values(status) AS http_status
        BY actor target src_ip
| where count >= 1
| convert ctime(first_seen) ctime(last_seen)
| sort - count
| table first_seen last_seen actor target src_ip count endpoints http_status

Wazuh OSSEC Rule

<group name="wordpress,wp-2fa,web,">
  <rule id="108066" level="10">
    <if_sid>31100,31101,31533</if_sid>
    <decoded_as>web-accesslog</decoded_as>
    <url>wp-2fa</url>
    <match>POST</match>
    <regex>(remove|disable|delete|deactivate|reset)[_-]?2fa</regex>
    <description>CVE-2026-108066: WP 2FA 2FA-configuration removal request targeting plugin endpoint - verify acting administrator is authorized for the target user (Multisite object-level authz bypass).</description>
    <mitre>
      <id>T1556</id>
      <id>T1562.001</id>
    </mitre>
    <group>cve_2026_108066,authentication_bypass,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix, workaround, or affected-version list is corroborated in the supplied data beyond the statement that the defect exists in WP 2FA before 4.2.0. None of the rules below depend on patch availability.

1. Immediate mitigations

• Patch posture: the description indicates the fix line is 4.2.0; treat "install/upgrade to 4.2.0 or later" as the only version-based remediation. Until a tracked source corroborates this artifact, verify the vendor changelog directly before relying on it.
• Multisite blast radius: on any WordPress Multisite network running WP 2FA below the fixed version, restrict administrator grants to a tightly controlled population and treat every site administrator as a potential cross-tenant actor for this issue.
• Compensating control at the network edge: temporarily block or monitor requests to the plugin's 2FA-removal endpoint from site-administrator sessions to users outside their own site using the Suricata/WAF rules above. This is an interim control, not a substitute for the fix.
• Detection-first posture: enable the Sigma/Splunk/Wazuh rules above and alert on any 2FA removal where actor != target.

2. Patch / upgrade steps

• Confirm the installed WP 2FA version; if below 4.2.0, create a full backup and stage the upgrade.
• Upgrade to 4.2.0 or later on a staging instance, validate that the object-level capability check now blocks cross-site removal, then roll out to production.
• Re-verify 2FA enrolment state for all privileged accounts after upgrade, since an earlier exploitation may have silently stripped enrolments.

3. Long-term hardening

• Enforce the principle of least privilege on Multisite: minimize site administrators, and reserve super-admin for network operators only.
• Adopt a user-capability (object-level authorization) test pattern in internal plugin review — specifically require current_user_can( 'edit_user', $user_id )-style checks on every per-user action.
• Apply network-level conditional access so that any account with reduced factors is treated as high-risk and denied privileged operations.
• Continuously monitor for 2FA-removal events and alert on those that are not requested by, or on behalf of, the affected user.

References

• NVD — CVE-2026-108066: https://nvd.nist.gov/vuln/detail/CVE-2026-108066
• CWE-639 — Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html
• WordPress capability reference — edit_user / current_user_can(): https://developer.wordpress.org/reference/functions/current_user_can/
• WP 2FA plugin project page (vendor changelog for the 4.2.0 release line): https://wordpress.org/plugins/wp-2fa/
• CISA Known Exploited Vulnerabilities catalog (verified absent for this CVE at time of writing): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat actor and exploit-in-the-wild status: no Named Threat Actor campaign has been attributed to CVE-2026-108066 as of this report; no public PoC, Nuclei template, or exploit code was identified; the CVE is not listed in CISA KEV; EPSS 0.00220 (≈11.7th percentile) indicates no material exploitation activity.