CVE-2026-84150

Executive Summary

CVE-2026-84150 is an authorization flaw (CWE-639, Authorization Bypass Through User-Controlled Key) in the Directorist: AI-Powered Business Directory, Listings & Classified Ads WordPress plugin, affecting versions before 8.9.5. A REST route in the plugin reads and modifies a user's saved favorites without verifying that the target user matches the authenticated caller, allowing any authenticated user with subscriber-level access to view and alter another user's favorites. Impact is limited to confidentiality and integrity of a single affected data class (favorites), yielding a CVSS v3.1 base score of 5.4 (Medium); there is no public PoC, exploit code, or Nuclei template as of this writing, and no CISA KEV listing.

Technical Analysis

The vulnerable component is the Directorist WordPress plugin, which ships a REST API route dedicated to managing a user's saved favorites (bookmarks) for directory listings. According to the NVD description, the route "does not verify that the target user of a REST route matches the authenticated caller before reading and modifying that user's saved favorites." This is a textbook CWE-639 (Authorization Bypass Through User-Controlled Key) issue: the request identifies the user whose favorites should be read or written via a client-supplied identifier, and the handler trusts that identifier instead of deriving the acting user from the authenticated session.

The attack surface is the plugin's REST endpoint(s) exposed through the standard WordPress REST API routing mechanism (typically under the /wp-json/ namespace). Because the endpoint is reachable over the network and only requires an authenticated session (AV:N, PR:L, UI:N), an attacker holding any subscriber-level account — registration on many directory sites is frequently open to the public — can issue direct HTTP requests to the route. No victim interaction is required; the victim need not click a link or load a page. The missing control is object-level authorization (per-object ownership check), the same class of defect commonly described as an IDOR/BOLA in REST APIs: the caller must be the owner of the favorites being accessed, but the handler never enforces that binding.

Notably, the description states the route is used both for reading and modifying favorites. That means the flaw is not merely a disclosure issue: the API performs state-changing operations (add/remove/overwrite favorites) keyed to a user identifier the attacker controls. The confidentiality and integrity impacts (C:L/I:L) stem from the scope of the affected object — favorites are low-sensitivity, low-privilege data — which caps the CVSS score despite the clean, low-complexity exploit path.

The CWE-639 classification confirms the root cause is user-controlled key binding rather than, for example, missing authentication entirely. Authentication is present and required; the failure is purely in authorization scoping. No specifics of the route path, parameter name, nonce handling, or permission callback implementation are provided in the NVD description or CNA title, so those implementation details cannot be stated here without fabrication. The patch confidence is 0/4: no vendor advisory, commit reference, tagged release diff, or OSV entry was tracked, even though the NVD text indicates the issue is resolved in 8.9.5.

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template is available. The attack chain below is inferred strictly from the vulnerability class (CWE-639 in a WordPress REST route) and the NVD description; it deliberately avoids naming specific endpoints, parameters, or functions that are not given.

1. Reconnaissance / target identification. The attacker identifies WordPress sites running Directorist (a directory/classifieds plugin) at a version below 8.9.5. Fingerprinting is possible from publicly served plugin assets and page markup. The attacker then determines whether subscriber-level registration is open (common on directory sites) or whether any low-privilege account can be obtained. The attacker also needs to learn the REST route used for favorites operations — WordPress publishes its REST routes in its discovery index, which is reachable unauthenticated on default configurations, so the route shape and its accepted user identifier are enumerable without special access.

2. Triggering the flaw. With a valid subscriber session (cookie or application password), the attacker sends a direct HTTP request to the favorites REST route. Instead of (or in addition to) their own user identifier, the attacker supplies the identifier of a target user. Because the handler does not verify that the target user matches the authenticated caller, the request is processed as if the caller owned that object. This is a horizontal privilege escalation within the authenticated user tier — no elevation to editor or administrator is described.

3. Payload / execution method (class-level). For the read case, the attacker simply issues the request with the victim's user identifier and reads the returned favorites list. For the write case, the attacker issues the corresponding state-changing request (add, remove, or overwrite favorites) carrying the victim's identifier, causing modifications to be persisted against the victim's account. There is no memory corruption, code execution, or injection described — the "payload" is a well-formed REST request with an attacker-controlled user key. Any nonce or capability checks that exist are, by the description's own statement, insufficient to bind the object to the caller.

4. Post-exploitation impact. The attacker obtains read and write access to arbitrary users' favorites sets. Concrete abuse includes: harvesting favorites to profile a victim's interests, listings, or business relationships; tampering with favorites to mislead or socially engineer the victim (for example, causing a fraudulent or attacker-controlled listing to appear in a victim's saved list); and mass enumeration of user identifiers to map which accounts are active. Because the affected object is favorites only, there is no described path to credential theft, site takeover, or code execution. The primary risk is privacy violation plus data-integrity manipulation of account-level user preferences, repeated at scale across all users on the site.

Impact Assessment

Business impact is moderate and bounded. The CVSS v3.1 base score is 5.4 (Medium) with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. Reading the vector: the attack is network-reachable (AV:N), requires no special conditions beyond a session (AC:L), needs a low-privilege authenticated account (PR:L) — subscriber level per the description — and requires no user interaction (UI:N). Scope is unchanged (S:U), meaning the flaw does not cross a security authority boundary into other components; confidentiality and integrity impacts are Low (C:L/I:L) and there is no availability impact (A:N). The Low subscores reflect the low sensitivity of the affected object (saved favorites), not the ease of exploitation.

Affected systems are WordPress installations running Directorist below 8.9.5. Blast radius within a site: potentially every registered user, since any subscriber can target any other user's favorites. The practical ceiling on damage is the value of favorites data — for niche directories (B2B listings, local services, classifieds) this can reveal commercial intent and vendor relationships, and write access enables manipulation of a victim's saved listings. It does not, per available data, reach administrative functions, site configuration, or other plugins.

On a multi-tenant or high-traffic directory, the enumerable user-identifier space combined with no rate limiting described in the advisory means bulk read and write of favorites is feasible. Threats to watch: mass privacy violations that could trigger GDPR/CCPA exposure if favorites are linked to identifiable users; reputational harm if an attacker defaces victims' saved listings; and use of the modified favorites as a phishing or social-engineering vector. CISA KEV status is NO, EPSS is not yet scored (do not assume a value), and there is no exploit-in-the-wild evidence. This is a routine, likely-automatable web-app authorization bug rather than an urgent mass-exploitation event.

Detection Guidance

Detection logic must account for the fact that legitimate favorites operations also hit the same route. High-signal detections should baseline normal traffic — an authenticated user normally references only their own user identifier — and alert on cross-user references, high-volume enumeration of user IDs, and state-changing requests against identifiers other than the session owner.

Sigma Rule

title: Directorist Favorites REST Route Cross-User Access (CVE-2026-84150)
id: 7f2c1a44-9d3e-4c8b-a1f6-2b6e5c9d8a01
status: experimental
description: Detects requests where a WordPress REST favorites operation targets a user identifier that differs from the authenticated session user, consistent with CWE-639 abuse in Directorist before 8.9.5.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-84150
author: valtersit.com threat intelligence
date: 2026/01/01
logsource:
  category: webserver
  product: generic
detection:
  selection_route:
    cs-uri-query|contains:
      - 'favorite'
      - 'favorites'
  selection_rest:
    cs-uri-query|contains: '/wp-json/'
  selection_user_param:
    cs-uri-query|re: '(user_id|user|uid|author)=\d+'
  filter_same_user:
    cs-uri-query|contains: 'internal_reporting_marker'   # placeholder; tune with app logging
  condition: selection_rest and selection_route and selection_user_param
falsepositives:
  - Legitimate administrative tooling operating on multiple users
  - Shared-account environments
level: medium

YARA Rule

rule CVE_2026_84150_Directorist_Favorites_IDOR
{
    meta:
        description = "Detects Directorist plugin artifacts associated with CVE-2026-84150 favorites authorization bypass (CWE-639)"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-84150"
        author = "valtersit.com threat intelligence"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $plugin_path = "wp-content/plugins/directorist" ascii wide
        $rest_ns     = "directorist" ascii wide nocase
        $fav1        = "favorite" ascii wide nocase
        $fav2        = "favourites" ascii wide nocase
        $route1      = "register_rest_route" ascii wide
        $route2      = "permission_callback" ascii wide

    condition:
        (uint32(0) == 0x504B0304 or uint32(0) == 0x3C3F7068) and
        $plugin_path and
        any of ($fav*) and
        any of ($route*)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-84150 Directorist Favorites REST Cross-User Access Attempt"; flow:established,to_server; http.method; content:"GET|POST|PUT|PATCH|DELETE"; http.uri; content:"/wp-json/"; content:"directorist"; nocase; content:"favorite"; nocase; pcre:"/(user_id|user|uid|author)=\d+/i"; reference:cve,2026-84150; classtype:attempted-user; sid:2026841501; rev:1; metadata:affected_product WordPress, attack_target Web_Server, created_at 2026_01_01, cve CVE_2026_84150;)

Note: the http.method content list is written for readability; deployers should split or adjust to their Suricata version's syntax requirements.

Elastic Detection

sequence by source.ip with maxspan=5m
  [ network where network.protocol == "http"
      and url.path like "/wp-json/%directorist%favorite%"
      and url.query rlike ".*(user_id|user|uid|author)=\\d+.*" ]
  [ network where network.protocol == "http"
      and http.request.method in ("POST", "PUT", "PATCH", "DELETE")
      and url.path like "/wp-json/%directorist%favorite%"
      and url.query rlike ".*(user_id|user|uid|author)=\\d+.*" ]

This flags a read-then-write pattern against the favorites route within a five-minute window, a strong indicator of cross-user tampering rather than ordinary self-service activity.

Splunk SPL Query

index=web OR index=proxy
| eval uri = lower(coalesce(uri, url, request_uri))
| where like(uri, "%/wp-json/%") AND like(uri, "%favorite%") AND like(uri, "%directorist%")
| rex field=uri "user_id=(?<target_user>\d+)"
| eval same_user = if(target_user == session_user, "yes", "no")
| where same_user == "no"
| stats count, dc(target_user) as distinct_targets, values(target_user) as targets by src_ip, session_user
| where distinct_targets > 3 OR count > 20
| sort - distinct_targets

Tune the session_user field to whatever identifier your WAF, reverse proxy, or application log exposes; if unavailable, alert on high-volume favorites-route traffic across many distinct target users from one source.

Wazuh OSSEC Rule

<group name="web,wordpress,directorist,">
  <rule id="202684150" level="10">
    <decoded_as>web-accesslog</decoded_as>
    <url>/wp-json/.*directorist.*favorite</url>
    <regex>user_id=\d+|uid=\d+|author=\d+</regex>
    <description>CVE-2026-84150: Directorist favorites REST route accessed with a user identifier parameter (possible cross-user IDOR).</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>cve_2026_84150,attack,</group>
  </rule>
</group>

Pair this with a frequency rule to escalate when a single source IP triggers the base rule repeatedly, indicating enumeration.

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The NVD description indicates the issue is resolved in Directorist 8.9.5, but no vendor advisory, changelog diff, commit, or OSV entry was tracked to independently confirm the fix, so this must be validated before relying on it.

1. Immediate mitigations (no vendor fix confirmed):

   • Treat every subscriber account as a potential attacker. If the site does not need open registration, disable public subscriber sign-ups immediately to shrink the attacker base, and audit existing low-privilege accounts.
   • If a functional plugin update is available (8.9.5 or later), update in a staging environment first and verify that the favorites route now enforces ownership before promoting to production. Because patch confidence is 0/4, confirm the fix behaviorally: an authenticated user attempting to read/write another user's favorites should receive an authorization failure.
   • Where updates are blocked by compatibility, consider a reverse-proxy/WAF layer or custom WordPress filter that (a) requires the target user identifier in favorites requests to equal the session's user, and (b) rate-limits or blocks favorites-route requests referencing identifiers outside the caller's own. Any custom filter must be reviewed and tested, since directly modifying plugin code complicates future updates.
   • Reduce exposure: restrict REST API access for unauthenticated and low-trust roles where the plugin does not require it; ensure favorites routes are not reachable without a valid session.
   • Monitor alerts from the detection rules above for cross-user references and enumeration bursts.

2. Patch / upgrade steps:

   • Upgrade the Directorist plugin to 8.9.5 or later. Take a full database and file backup before upgrading.
   • After upgrade, validate the fix: as subscriber A, attempt to read and modify subscriber B's favorites via direct REST calls; confirm the requests are rejected.
   • Re-check for a published vendor advisory and changelog; none is tracked at present, and no CVE-linked commit was available for review.

3. Long-term hardening:

   • Enforce the principle that REST handlers derive the acting user from the authenticated session and never trust a client-supplied user key for authorization decisions; apply object-level authorization checks to every read and write.
   • Maintain an inventory of installed plugins and their versions with alerting for new CVEs; automate outage-aware staging updates.
   • Log all state-changing REST API calls with actor identity, target object, and outcome; feed into SIEM for cross-user anomaly detection.
   • Apply least privilege to WordPress roles, disable user enumeration where possible, and cap the number of low-privilege accounts.
   • Consider an API gateway or plugin security layer that centralizes per-object authorization checks.

References

• NVD — CVE-2026-84150: https://nvd.nist.gov/vuln/detail/CVE-2026-84150
• CWE-639 — Authorization Bypass Through User-Controlled Key: https://cwe.mitre.org/data/definitions/639.html
• WordPress REST API handbook (route discovery and authentication model): https://developer.wordpress.org/rest-api/
• Directorist plugin project page (WordPress.org plugin repository): https://wordpress.org/plugins/directorist/
• OWASP API Security Top 10 — API1: Broken Object Level Authorization: https://owasp.org/API-Security/

Threat actor campaigns: none known. Exploit-in-the-wild evidence: none. CISA KEV: NO. No public PoC, exploit code, or Nuclei template was available as of this report; EPSS remains unscored by FIRST.org.