GeoDirectory EUVD-2026-86541

Requires an authenticated WordPress account with at least subscriber-level access on a site running GeoDirectory ≤2.8.183, and the attacker must own a listing (post authorship is the only check the AJAX save handler enforces besides a nonce). Exploitation therefore depends on the site permitting user registration and listing creation/ownership by low-privileged users - a common but not universal GeoDirectory configuration. The stored payload executes only when a user subsequently views the injected listing page (delayed, victim-side trigger). Limiting factors: authentication is mandatory (PR:L, no anonymous exploitation), impact is limited to script execution in browser context (C:L/I:L, no availability impact), and sites that restrict listing creation to trusted roles are not practically exploitable by arbitrary users.

This is a genuine but moderate-severity issue, not a top-priority emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N = 6.4) indicates network-reachable, low-complexity exploitation but requires authentication at subscriber level (PR:L) and yields only low confidentiality/integrity impact with a scope change (S:C, reflecting XSS crossing into other users' browser context). The description reinforces this: the flaw is an authorization gap - the AJAX save handler checks only post authorship plus a nonce with no capability check, so any subscriber who owns a listing can inject persistent script. No EPSS score, KEV listing, or public POC is present in the provided data, so exploitation status is 'no public exploit identified at time of analysis.' The Wordfence threat-intel report confirms the vulnerability and its root cause but does not indicate active exploitation. Realistically this is a widespread-plugin stored-XSS that matters for sites accepting untrusted registrations, but the subscriber-ownership precondition and stored (rather than wormable unauthenticated) nature keep real-world urgency in the medium band. Note the S:C scope-change assignment is a defensible but debatable choice typical of Wordfence XSS scoring; no signal conflicts require vendor verification.

On a GeoDirectory site that allows public/subscriber registration and listing ownership, an attacker registers a subscriber account and creates or claims a listing. They then send a crafted AJAX save request setting the 'business_hours' parameter to a malicious script payload, which is stored and later executes in the browser of any visitor or administrator who views the listing page. No public exploit code is identified in the provided data, but the technique is straightforward given the documented missing capability check.