CVE-2026-114270 in GeoDirectory Plugin
Summary
by MITRE • 10/29/2026
The GeoDirectory WordPress plugin before 2.8.197 does not honour post password protection when rendering a listing, allowing unauthenticated users to disclose the content and custom fields of published listings that are protected by a post password.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in versions of the GeoDirectory WordPress plugin prior to release 2.8.197 represents a critical failure in access control mechanisms, specifically concerning how the application handles authenticated versus unauthenticated requests for content designated as private or password-protected. In standard web application architecture and Content Management System (CMS) operations like WordPress, post-level security is enforced by checking user session tokens or authentication cookies before rendering sensitive data to the client browser. However, in this specific implementation within GeoDirectory, the logic governing the display of listing details bypasses these necessary verification steps when generating output for end users. This architectural flaw allows any individual with a direct URL link to view detailed information about listings that are explicitly marked as requiring authentication or password entry, effectively rendering the protection mechanism obsolete from an external attacker's perspective.
From a technical standpoint, this issue falls under the category of Broken Access Control, which is consistently ranked among the top security risks in web applications by industry standards such as OWASP Top 10 and CWE-284. The root cause lies in the server-side rendering process where the plugin retrieves listing data from the database without adequately validating whether the requesting entity possesses the requisite credentials or has successfully authenticated via a password prompt for that specific post ID. Consequently, the application treats unauthenticated requests with the same privilege level as authorized ones regarding content visibility. This misconfiguration means that custom fields, which may contain sensitive personal information such as contact details, identification numbers, or other proprietary data associated with business listings, are exposed to any user who can guess or obtain the direct permalink of a protected listing.
The operational impact of this vulnerability is significant for organizations and individuals relying on GeoDirectory to manage secure directories. Since attackers do not need valid credentials to exploit this flaw, it facilitates unauthorized information disclosure at scale. An adversary could potentially scrape large volumes of sensitive data by iterating through known or enumerated post IDs, leading to privacy violations under regulations such as GDPR or CCPA if personal identifiable information is involved. Furthermore, the exposure of custom fields might reveal internal business processes, pricing structures, or contact strategies that competitors could leverage for malicious purposes. The ease of exploitation means that automated tools can rapidly identify and harvest this data without triggering typical intrusion detection systems associated with brute-force login attempts.
To mitigate this risk, immediate action is required to update the GeoDirectory plugin to version 2.8.197 or later, where the developers have patched the access control logic to properly enforce password requirements before rendering listing content. In environments where updating may not be immediately feasible due to compatibility constraints with other plugins or themes, administrators should implement a Web Application Firewall rule that intercepts requests for protected post types and verifies authentication status at the network edge. Additionally, reviewing server logs for unusual patterns of access to private listings can help identify if exploitation has occurred in the past. Regular security audits focusing on access control flows are recommended to ensure that future updates or custom code modifications do not reintroduce similar vulnerabilities into the application stack.