CVE-2026-107694

Executive Summary

CVE-2026-107694 is a broken access control vulnerability (CWE-639, Authorization Bypass Through User-Controlled Key) in the Dokan: AI Powered WooCommerce Multivendor Marketplace Solution WordPress plugin, affecting all versions before 5.2.0. The plugin fails to verify that the vendor for whom a commission calculation is requested is the same vendor making the request, allowing an authenticated vendor to disclose the commission rate and fixed fee the marketplace administrator configured for other vendors. The impact is limited to information disclosure of marketplace-wide commission configuration, but it exposes sensitive business logic that underpins vendor payouts, pricing strategy, and platform monetization.

Technical Analysis

The Dokan plugin implements a multivendor marketplace on top of WooCommerce, where each vendor is a distinct user role with its own products, orders, and payout terms. Commission configuration — the percentage rate and fixed fee the marketplace administrator applies to each vendor — is a core piece of platform business logic. The vulnerability lies in the commission calculation path: when a commission calculation is requested, the plugin does not verify that the vendor identifier supplied in the request is the same vendor identity as the requesting user. This is a classic IDOR/authorization-bypass condition.

The CWE mapping (CWE-639) is appropriate: the application uses a user-controlled key (the vendor identifier) to select which vendor's configuration is read, and it fails to cross-check that key against the authenticated session's vendor identity. From the NVD description alone, the exact parameter or route name is not disclosed, and no function names, REST endpoints, or admin-ajax actions are provided. What can be stated with confidence is the vulnerability class and mechanism: a vendor-authenticated request can supply an arbitrary target vendor identifier, and the plugin will return or compute a result based on the target vendor's stored commission rate and fixed fee.

The attack surface is the plugin's commission-calculation functionality, which is reachable by any user with vendor-level privileges. Because the disclosure is of marketplace administrator-configured values rather than customer PII or payment data, the confidentiality impact is scoped (CVSS C:L), but it is a genuine authorization failure that leaks per-vendor business terms across tenant boundaries.

Note: no public PoC, Nuclei template, or exploit code was available at the time of collection, and the NVD description does not enumerate the vulnerable code path. Any claim about specific parameter names, nonce handling, or endpoint routes would be speculative and is deliberately omitted.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred strictly from the vulnerability class (CWE-639 authorization bypass via user-controlled key) and the NVD description.

1. Reconnaissance / target identification: The attacker identifies a WordPress site running the Dokan multivendor marketplace plugin. Registration or approval as a vendor on the marketplace provides the required authenticated, low-privileged foothold. The attacker enumerates candidate vendor identifiers (e.g., sequential user/vendor IDs) as permitted for the marketplace.

2. Triggering the flaw class: With an authenticated vendor session, the attacker invokes the plugin's commission calculation functionality while supplying a vendor identifier that differs from their own. Because the plugin does not verify that the requested vendor matches the requesting vendor, the authorization check is bypassed at the request-validation layer.

3. Payload/execution method: At the vulnerability-class level, this is a parameter/key substitution attack. The attacker substitutes the user-controlled vendor key in a request to the commission calculation path. The plugin processes the request without binding the key to the session identity and returns a commission result — the rate and fixed fee — for the target vendor. No memory corruption, injection, or remote code execution primitive is involved; this is a pure logic flaw.

4. Post-exploitation impact: The attacker accumulates commission rates and fixed fees configured for other vendors, revealing marketplace monetization terms, negotiation baselines, and per-vendor deal structures. This intelligence can be used for competitive positioning, for social engineering against the marketplace operator or other vendors, and for identifying the most profitable vendors to target in follow-on fraud. The flaw is repeatable and non-destructive, making detection difficult without request-level authorization monitoring.

Impact Assessment

Business impact centers on confidentiality of marketplace business logic. Competing vendors on the same platform can learn each other's negotiated commission rates and fixed fees, which is commercially sensitive and can be leveraged in vendor negotiation, dispute escalation, or off-platform competitive maneuvering. The marketplace operator's monetization strategy and vendor-tier definitions are exposed.

Blast radius is the entire vendor population of a given Dokan installation: any authenticated vendor can potentially enumerate terms for all other vendors, making the affected systems the full set of eligible vendor accounts on the marketplace. Customer data, payment instruments, and order contents are not directly implicated by the description, so integrity and availability impact are assessed as none/negligible.

CVSS subscores (per the estimated vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N): network-exploitable, low complexity, requires low privileges (an approved vendor account), no user interaction, unchanged scope, low confidentiality impact, no integrity or availability impact. Note the official CVSS score from NVD was not provided (N/A); the vector above is an analytical estimate consistent with the described flaw class, not an authoritative score.

Detection Guidance

Dokan commission endpoints are typically invoked via WordPress admin-ajax actions or plugin REST/userdashboard routes. Because the description does not name a specific route, the detections below use behavioral and generic patterns and should be tuned to the site's observed endpoint names.

Sigma Rule

title: Potential Dokan Commission IDOR - Cross-Vendor Commission Lookup
id: 3f9c1a72-0c44-4c9d-9a10-d0kancve107694
status: experimental
description: Detects repeated commission calculation/lookup requests where the vendor identifier differs from the authenticated session, indicative of CVE-2026-107694 in Dokan before 5.2.0.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-107694
author: valtersit.com Threat Intelligence
date: 2026-01-01
logsource:
  category: webserver
  product: apache
  service: access_combined
detection:
  selection_endpoint:
    cs_uri_query|contains:
      - 'dokan'
      - 'commission'
  selection_key:
    cs_uri_query|re: '(?i)(vendor_?id|seller_?id|vendor)='
  filter_prefetch:
    cs_uri_query|contains: 'prefetch'
  condition: selection_endpoint and selection_key and not filter_prefetch
fields:
  - c_ip
  - cs_uri_query
  - cs_username
falsepositives:
  - Legitimate admin operations querying multiple vendor commissions
  - Automated reporting or accounting jobs
level: medium
tags:
  - attack.t1190
  - cve.2026-107694

YARA Rule

rule CVE_2026_107694_Dokan_Commission_IDOR
{
    meta:
        description = "Detects Dokan plugin versions potentially vulnerable to CVE-2026-107694 (commission IDOR)"
        author = "valtersit.com Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-107694"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $plugin = "dokan" ascii nocase
        $slug1 = "dokan-lite" ascii nocase
        $slug2 = "dokan-pro" ascii nocase
        $commission = "commission" ascii nocase
        $vendor = "vendor" ascii nocase
        $version = /Stable tag:\s*([1-4]\.[0-9]+\.[0-9]+|5\.[01]\.[0-9]+)/ ascii

    condition:
        uint32(0) == 0x04034b50 and
        $plugin and
        ($slug1 or $slug2) and
        $commission and
        $vendor and
        $version
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-107694 Dokan Commission IDOR Attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"dokan"; nocase; http.uri; content:"commission"; nocase; http.uri; pcre:"/(vendor|seller)_?id=\d+/i"; reference:cve,2026-107694; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-107694; classtype:attempted-recon; sid:2026107694; rev:1;)

Elastic Detection

sequence by user.name, source.ip with maxspan=5m
  [http where url.path : "*commission*" and url.query : ("*vendor_id=*" or "*vendor=*" or "*seller_id=*")]
  [http where url.path : "*commission*" and url.query : ("*vendor_id=*" or "*vendor=*" or "*seller_id=*")]

Splunk SPL Query

index=web sourcetype=access_combined
| eval uri_lower=lower(uri_query)
| where (like(uri_lower, "%commission%") OR like(uri_lower, "%dokan%"))
| rex field=uri_query "(?i)(vendor_?id|seller_?id|vendor)=(?<target_vendor>\d+)"
| where isnotnull(target_vendor)
| stats count values(target_vendor) as target_vendors by src_ip, user
| where count > 5 OR mvcount(target_vendors) > 3
| sort - count

Wazuh OSSEC Rule

<group name="web,dokan,attack,">
  <rule id="107694" level="10">
    <if_sid>31100</if_sid>
    <url>dokan</url>
    <url>commission</url>
    <regex status="PCRE2">(?i)(vendor|seller)_?id=\d+</regex>
    <description>CVE-2026-107694: Possible Dokan cross-vendor commission lookup (IDOR) from $(srcip)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>cve_2026_107694,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The NVD description references "before 5.2.0" as the fixed threshold, but no vendor advisory, commit hash, or download artifact confirming an actual fix was supplied in the collected data. Treat this as an unverified fix boundary and validate independently.

1. Immediate mitigations (no code patch required):

• Restrict vendor registration/approval so that only vetted accounts can reach commission functionality, reducing the pool of actors able to exercise the flaw.
• Enforce least privilege and monitor vendor sessions for anomalous, high-volume commission-lookup patterns; the Splunk and Elastic detections above support this.
• Where possible, disable or gate the commission-calculation feature for vendor roles until a verified fix is applied.
• Add a WAF/pre-render heuristic to flag requests carrying a vendor identifier that does not match the authenticated session's vendor mapping (custom rule; plugin-specific route names must be observed in situ).

2. Patch / upgrade steps:

• Before upgrading, capture the currently installed Dokan version and confirm a target release exceeding 5.2.0 is genuinely available from the vendor.
• Back up the WordPress database and wp-content/plugins/dokan-* directories, then update Dokan via the WordPress admin or WP-CLI (wp plugin update).
• Because no authoritative patch reference was supplied, verify the fixed release notes and test the authorization path post-upgrade with two vendor accounts to confirm cross-vendor commission disclosure is closed.

3. Long-term hardening:

• Implement server-side authorization checks that bind every requested resource key to the authenticated principal, and add unit/integration tests for authorization boundaries in custom plugins.
• Adopt a vendor-plugin review process that inspects access-control logic before deployment.
• Maintain an SBOM of WordPress plugins and monitor NVD/WPScan feeds for Dokan advisories.

References

1. NVD — CVE-2026-107694: https://nvd.nist.gov/vuln/detail/CVE-2026-107694
2. Dokan — AI Powered WooCommerce Multivendor Marketplace Solution (official plugin site): https://wedevs.com/dokan/
3. WordPress Plugin Directory — Dokan (version history and changelog): https://wordpress.org/plugins/dokan-lite/
4. CWE-639 — Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html
5. OWASP — Insecure Direct Object Reference (IDOR) guidance: https://owasp.org/www-community/vulnerabilities/Insecure_Direct_Object_Reference

Exploit-in-the-wild evidence: none observed. CISA KEV: not listed. Public PoC: none available. Threat actor campaign attribution: none.