CVE-2026-119113 in GeoDirectory Plugin
Summary
by MITRE • 10/30/2026
The GeoDirectory – WP Business Directory Plugin and Classified Listings Directory plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the listing description (post_content) in versions up to, and including, 2.8.199 This is due to insufficient input sanitization on save (the bundled geodir_kses_safe_embed_attributes() helper only neutralises data-embed-url, data-src and data-embed, while WordPress core wp_kses_post permits data-* attributes on standard HTML tags) combined with the AyeCode UI library initializing every [data-bs-toggle="popover-html"] element with { html: true, sanitize: false }, which inserts the attacker-controlled data-bs-content value into the popover body as HTML at render time. This makes it possible for authenticated attackers, with Subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/30/2026
The GeoDirectory plugin for WordPress, specifically versions up through 2.8.199, contains a critical stored cross-site scripting vulnerability within the listing description field, technically identified as post_content. This flaw arises from a combination of insufficient input sanitization and improper configuration of client-side rendering libraries used by the application's user interface. The core issue lies in how the plugin processes HTML content during the save operation. While WordPress provides robust filtering mechanisms such as wp_kses_post to sanitize data, GeoDirectory utilizes its own helper function named geodir_kses_safe_embed_attributes for specific contexts. This custom sanitizer is overly permissive regarding certain attributes; it only neutralizes a limited set of embed-related attributes like data-embed-url, data-src, and data-embed, while inadvertently allowing other data-* attributes to pass through without adequate validation against the broader security policies enforced by WordPress core.
The vulnerability is exacerbated by the integration with the AyeCode UI library, which powers much of the plugin's frontend interface. Specifically, elements utilizing the attribute [data-bs-toggle="popover-html"] are initialized with a configuration object that explicitly sets html to true and sanitize to false. This configuration instructs the JavaScript engine to render the content provided in the data-bs-content attribute as raw HTML rather than plain text or sanitized markup. When an attacker injects malicious script tags into the listing description, these scripts survive the server-side sanitization process due to the aforementioned gaps in geodir_kses_safe_embed_attributes and are subsequently stored in the database. Upon page load, the frontend JavaScript reads this unsanitized content and inserts it directly into the DOM via the popover mechanism, executing any embedded malicious code within the context of the victim's browser session.
This vulnerability is classified under CWE-79, which covers Improper Neutralization of Input During Web Page Generation known as Cross-site Scripting. From a tactical perspective, this aligns with MITRE ATT&CK technique T1059.007, JavaScript Execution, and potentially T1189 Drive-by Client Side Code Injection if the attack is triggered via phishing or social engineering leading to page visits. The impact of this flaw is significant because it allows for session hijacking, credential theft through keylogging scripts, defacement of public-facing listings, or redirection to malicious sites. Since the payload is stored in the database, the execution occurs every time a user views the affected listing, creating a persistent threat vector that affects not just the attacker but any authenticated administrator or subscriber who accesses the compromised content.
The exploitation requires an attacker with at least Subscriber-level access and above within the WordPress environment. This relatively low privilege requirement makes the vulnerability particularly dangerous in multi-author sites where users may have limited administrative oversight but sufficient rights to create or edit listings. An attacker can craft a malicious listing description containing JavaScript payloads, such as those designed to steal cookies or perform actions on behalf of an administrator if they view the page while logged in with higher privileges. The stored nature of this XSS means that remediation is not merely about patching input validation but also requires cleaning existing database entries that may already contain injected scripts.
Mitigation strategies should focus on immediate updates and configuration hardening. Users running GeoDirectory versions up to 2.8.199 must upgrade to the latest patched version where the geodir_kses_safe_embed_attributes function has been corrected to properly restrict dangerous attributes and align with WordPress core security standards. In addition to updating, site administrators should review existing listings for any signs of injected scripts, particularly in fields that render HTML content via popovers or dynamic UI components. Implementing a Web Application Firewall can provide an additional layer of defense by blocking common XSS payloads before they reach the application logic. Furthermore, enforcing strict Content Security Policy headers on WordPress sites can mitigate the impact of successful exploitation by restricting the sources from which scripts are allowed to execute, thereby preventing many client-side attacks even if input sanitization fails.