CVE-2026-84027

Executive Summary

CVE-2026-84027 is a missing authorization vulnerability (CWE-862) in the Directorist WordPress plugin, affecting all versions before 8.9.5. The plugin's REST API order-creation endpoint fails to verify user capabilities, allowing any authenticated user with the subscriber role or above to create paid order and payment records with arbitrary amounts and attribute them to other users. The direct confidentiality and availability impact is limited (CVSS 4.3), but the vulnerability enables payment-record forgery and data-integrity abuse against a widely deployed directory/business-listing plugin.

Technical Analysis

The vulnerability resides in a REST API component of the Directorist plugin — "AI-Powered Business Directory, Listings & Classified Ads" for WordPress. According to the NVD description, the affected code path creates "orders" through the plugin's REST API and does so without performing a user-capability check. This maps directly to CWE-862 (Missing Authorization): the REST route is reachable by authenticated users, but the handler does not enforce a role/capability gate (for example, a current_user_can() check or an authorization_callback on the route registration) before executing its logic.

The attack surface is the plugin's REST API namespace exposed through the standard WordPress REST routing layer (typically reachable at /wp-json/<namespace>/<route>). Because WordPress exposes REST endpoints to any client that can reach the site and present a valid authentication cookie or application password/nonce, a low-privileged account — the subscriber role or any higher role — is sufficient to invoke the vulnerable handler. The plugin does not appear to require elevated capabilities such as manage_options or an administrative role for this particular route.

Two distinct but related weaknesses follow from the missing authorization check:

1. Unrestricted order creation — an authenticated low-privileged user can create order records. The description states these are "paid order and payment records," meaning the records carry a monetary amount and a payment status, not merely a benign listing or metadata row.
2. Mass assignment / parameter tampering of amount and user attribution — the description explicitly states that the user can supply "arbitrary amounts" and "attribute them to other users." This indicates the request handler accepts caller-controlled values for both the monetary amount field and the user-ownership field without validating that the caller is entitled to set them. Consequently, the integrity of the payments/orders data set is violated: records can be forged with any value and pinned to an arbitrary victim account.

There is no public evidence of code execution, privilege escalation beyond the broken access control, or memory corruption. The CVSS subscores are consistent with this: I:L (Low Integrity) and C:N/A:N (no confidentiality or availability impact). The attack is network-reachable (AV:N), requires low privileges (PR:L), needs no user interaction (UI:N), and does not change scope (S:U).

No public proof-of-concept, Nuclei template, or exploit code was available at the time of writing. The exact REST route path, parameter names, and handler function names are not disclosed in the available data and are therefore not specified here.

Exploitation Scenarios

No public PoC is available; the following attack chain is inferred at the vulnerability-class level from the NVD description and CWE-862.

1. Reconnaissance / target identification. The attacker identifies a WordPress site running Directorist below 8.9.5. Fingerprinting can be performed passively by inspecting the site's HTML for the plugin's asset paths (e.g., /wp-content/plugins/directorist/...) and by probing the WordPress REST API index at /wp-json/ for the plugin's registered namespace. Version identification supports narrowing to affected deployments, since the fix is version 8.9.5.

2. Authentication acquisition. The flaw is reachable only by an authenticated user. Subscriber-level self-registration is common on WordPress sites and provides the necessary PR:L foothold. No elevated role is required, per the NVD description ("subscriber role and above"). The attacker authenticates and obtains a valid session cookie and/or REST nonce for subsequent requests.

3. Triggering the flaw (missing authorization check). The attacker submits a REST API request to the plugin's order-creation route. Because the endpoint performs no capability check, the request succeeds despite the caller holding only a subscriber role. At the vulnerability-class level, this is a broken access control on a state-changing endpoint — the server processes the action based solely on the caller's authentication, not on authorization.

4. Parameter abuse (arbitrary amounts and victim attribution). Within the same request, the attacker supplies an arbitrary monetary amount and an ownership/attribution field pointing to another user's account. As the handler does not validate these caller-controlled values against the caller's entitlements, the resulting order and payment records are created with attacker-chosen amounts and assigned to victim accounts. This is the integrity-violating core of the issue.

5. Post-exploitation impact. The attacker can repeatedly create forged paid orders and payment records. This pollutes business/reporting data, can misattribute financial obligation or entitlement to victims, and may be leveraged for downstream fraud (e.g., fake payment confirmations, manipulated order histories) or to disrupt administrative workflows. No code execution or data exfiltration is described by the vulnerability.

Impact Assessment

The direct technical impact is limited and integrity-centric. CVSS 3.1 assigns 4.3 with subscores C:N/I:L/A:N/S:U. There is no confidentiality loss (no described read of sensitive data) and no availability loss (no described denial of service). The sole impact dimension is integrity at a Low level, reflecting that an attacker can create or modify a bounded set of records (orders/payments) rather than compromise the whole system.

The most material business consequences are:

• Data-integrity and financial-record tampering. Orders and payment records with arbitrary amounts can be injected, corrupting accounting, reporting, commissions, or reconciliation. Attributing records to other users can implicate innocent accounts in fraudulent or erroneous transactions.
• Attribution and audit-trail abuse. Because records can be tied to arbitrary users, incident response and user-level audits can be misled. Distinguishing legitimate from forged records may require deep correlation against payment-gateway ground truth.
• Foothold for downstream abuse. On directory/classified-ads sites, a subscriber-level account is a low bar to obtain; the resulting capability to write financial records materially expands what an otherwise limited account can do.

Blast radius is every WordPress installation running Directorist below 8.9.5 with the affected REST API reachable and self-registration (or any low-privileged account provisioning) enabled. There is no evidence of wormable behavior or lateral movement; the flaw is a per-site broken access control. Because Directorist is a directory/classifieds plugin, affected sites are typically public-facing and multi-user, which increases the population of low-privileged accounts that can trigger it.

Detection Guidance

Detection should focus on anomalous REST API order-creation activity by low-privileged accounts, requests that carry suspicious amount or user-attribution parameters, and any creation of payment records inconsistent with legitimate checkout flows. Because the exact route path and parameter names are not disclosed in the available data, the rules below use conservative, behavioral matching on the plugin namespace and order/payment creation semantics. Analysts should tune namespaces and field names to the specific deployment.

Sigma Rule

title: Directorist REST API Order Creation by Low-Privileged User (CVE-2026-84027)
id: 6b1f0c2a-9d4e-4b7a-8c31-directorist84027
status: experimental
description: Detects authenticated requests to the Directorist REST API order-creation
  endpoint from low-privileged (subscriber-level) accounts, indicative of CWE-862
  missing authorization (CVE-2026-84027).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-84027
author: valtersit.com
date: 2026/01/01
logsource:
  product: webserver
  category: webserver
detection:
  selection_route:
    cs-method: 'POST'
    cs-uri-query|contains:
      - '/wp-json/directorist'
      - '/wp-json/directorist/v1'
  selection_order:
    cs-uri-query|contains:
      - 'order'
      - 'payment'
  selection_lowpriv:
    # web server logs typically lack role; pair with WordPress audit plugin logs
    cs-username|contains: 'subscriber'
  condition: selection_route and selection_order
falsepositives:
  - Legitimate administrators or shop managers creating orders via the REST API
  - WordPress admin UI operations that proxy through REST
level: medium
tags:
  - attack.t1190
  - cve.2026-84027

YARA Rule

rule CVE_2026_84027_Directorist_Missing_Authz
{
    meta:
        description = "Detects Directorist plugin source indicating order-creation REST handler without capability check context (CVE-2026-84027)"
        author = "valtersit.com"
        date = "2026-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-84027"
        cve = "CVE-2026-84027"

    strings:
        $plugin_header = "Plugin Name: Directorist"
        $ns1 = "directorist/v1"
        $ns2 = "/wp-json/directorist"
        $order1 = "create_order"
        $order2 = "register_rest_route"
        $perm = "permission_callback"
        $cap = "current_user_can"

    condition:
        uint16(0) == 0x3C3F or $plugin_header
        and ($ns1 or $ns2)
        and $order2
        and not ($order1 and $cap)
        and not ($order1 and $perm)
}

Note: this rule is a heuristic aid for triage and version triage only. It relies on the intent (order creation) and the absence of authorization-callback markers and should NOT be treated as a definitive signature.

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-84027 Directorist REST order creation by low-privileged user"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/wp-json/directorist"; http.uri; content:"order"; nocase; http.header; content:"Cookie"; nocase; ; threshold:type limit, track by_src, count 1, seconds 60; sid:8402701; rev:1; metadata:cve CVE-2026-84027, mitre_tactic T1190;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [ network where http.request.method == "POST"
      and http.request.uri : "/wp-json/directorist*"
      and http.request.uri : "*order*" ]
  [ network where http.request.method == "POST"
      and http.request.uri : "/wp-json/directorist*"
      and (http.request.body : "*amount*" or http.request.body : "*payment*") ]

Interpretation: correlated POST requests to the Directorist REST namespace touching order/payment parameters from the same source within a short window indicate probable automated order-record forgery (CVE-2026-84027).

Splunk SPL Query

index=web sourcetype=access_combined
(method=POST)
(uri_path="*wp-json/directorist*")
(uri_path="*order*" OR uri_path="*payment*")
| stats count values(uri_path) as paths values(status) as statuses by src_ip, user
| where count >= 3
| sort - count

Analysts should enrich user with WordPress role data (e.g., from an audit or auth log) and alert on order-creation events sourced from subscriber-level accounts.

Wazuh OSSEC Rule

<group name="web,wordpress,directorist,">
  <rule id="840270" level="8">
    <decoded_as>web-accesslog</decoded_as>
    <match>/wp-json/directorist</match>
    <regex type="pcre2">POST.*\/(wp-json\/directorist[^\s]*)\/(order|payment)</regex>
    <description>CVE-2026-84027: Possible Directorist REST order/payment creation request (missing authorization)</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>directorist_cve_2026_84027,</group>
  </rule>
</group>

Rule tuning is required: legitimate authenticated administrators may also create orders through the REST API, so this rule should be combined with role context where available to reduce false positives.

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED. No patch commit, vendor advisory, changelog entry, or release artifact was available from any tracked source at the time of writing. The NVD description states the fix is present in version 8.9.5, but no corroborating patch evidence was retrieved. Treat all mitigations below as compensating controls until a verified patch is confirmed.

1. Immediate mitigations (compensating controls).

   • Remove or update the plugin. If Directorist below 8.9.5 is not business-critical, deactivate it immediately. This removes the vulnerable REST route entirely.
   • Restrict the affected REST route at the edge. Where the route path can be identified, block or rate-limit POST requests from unauthenticated or subscriber-level sessions at the WAF/reverse proxy.
   • Disable public self-registration. Because the flaw requires only subscriber-level access, closing self-registration or requiring administrator approval prevents untrusted visitors from obtaining the prerequisite account.
   • Reduce low-privileged account creation and audit existing subscriber accounts for anomalies.
   • Monitor order/payment records for entries with implausible amounts or attributed to accounts that did not place a legitimate order; reconcile against payment-gateway ground truth.

2. Patch / upgrade steps.

   • Upgrade Directorist to 8.9.5 or later once the release is verified from an authoritative WordPress.org or vendor source.
   • Before upgrading, back up the database and files. After upgrading, verify the REST route now enforces a capability/authorization check (analyst-validated) and re-audit recent orders/payment records for evidence of tampering.
   • If 8.9.5 is unavailable or the changelog cannot be verified, treat the plugin as unpatched and keep compensating controls in place.

3. Long-term hardening.

   • Apply timely WordPress core, plugin, and theme updates; subscribe to the WordPress.org plugin vulnerability feed and NVD for the Directorist vendor.
   • Enforce least privilege: audit which roles can create orders and payment records, and ensure capability checks gate every state-changing REST route.
   • Add server-side validation for monetary amounts and ownership fields (reject caller-supplied attribution to other users unless the caller is authorized).
   • Deploy WAF rules and log-based detections (see Detection Guidance) and forward WordPress audit logs (e.g., role, user, REST actions) to the SIEM for correlation.
   • Restrict the WordPress REST API and xmlrpc where not required, and monitor wp-json access from low-privileged sessions.

References

• NVD — CVE-2026-84027: https://nvd.nist.gov/vuln/detail/CVE-2026-84027
• MITRE CWE-862 — Missing Authorization: https://cwe.mitre.org/data/definitions/862.html
• WordPress REST API authentication and authorization documentation: https://developer.wordpress.org/rest-api/
• WordPress Plugin Security / Directorist plugin page (verify current version and changelog): https://wordpress.org/plugins/directorist/
• CISA Known Exploited Vulnerabilities Catalog (CVE-2026-84027 is NOT listed; verify): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat actor / exploit-in-the-wild evidence: None available. No public PoC, exploit code, or Nuclei template was observed for CVE-2026-84027 at the time of writing. EPSS has not yet scored this CVE by FIRST.org; no EPSS value is asserted here. CISA KEV status is NO. All detection and exploitation content in this report is inferred from the vulnerability class (CWE-862) and the NVD description; no specific route paths, parameter names, or function names beyond those in the NVD description are asserted.