GeoDirectory CVE-2026-68565

Exploitation requires an attacker to hold a Contributor-level (or equivalent) WordPress account on the target site, satisfying the PR:L prerequisite in the CVSS vector. The attacker must be able to submit or edit content through GeoDirectory's listing or directory submission interface - the specific vulnerable field is not identified in the available data but is within contributor-accessible inputs. A second condition is that a user with higher privileges (editor or administrator) must subsequently view or interact with the poisoned content (UI:R), which is a realistic occurrence on sites where admins routinely review contributor submissions. Exploitation is limited to WordPress sites running GeoDirectory <= 2.8.172 where contributor accounts exist for untrusted users; installations where contributor access is restricted to fully trusted internal staff face significantly reduced risk despite the technical vulnerability being present.

The CVSS 3.1 score of 6.5 with vector AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L correctly reflects the attack profile: network-reachable, low complexity, low-privilege requirement (contributor account), but dependent on a privileged user viewing the injected content. No EPSS data was provided in the intelligence, and the vulnerability is not listed in the CISA KEV catalog, indicating no confirmed active exploitation at time of analysis. Despite the 'Low' impact ratings per-metric, the scope change is the critical signal here - successful exploitation could yield full WordPress admin takeover if an administrator views poisoned content, making the effective business impact substantially higher than the base score implies. Patchstack's disclosure via a structured plugin vulnerability report suggests responsible disclosure, which typically precedes rapid patch availability. Priority should be elevated on sites where contributor-role accounts are granted to untrusted or external users.

An attacker registers or compromises a contributor-level account on a GeoDirectory-powered WordPress site, then submits a business listing or directory entry containing a crafted XSS payload in an unsanitized field (e.g., listing description or custom metadata). When an administrator reviews, approves, or edits the submission through the WordPress dashboard or frontend, the malicious script silently executes in their browser - capturing the admin's session cookie or WordPress nonce and forwarding it to an attacker-controlled server, granting full administrative access. No public proof-of-concept code was identified in the provided data, but the attack requires no advanced techniques beyond standard stored XSS methodology.