CVE-2026-105078 in Store Locator Plugin
Summary
by MITRE • 10/08/2026
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in WP Store Locator WP Store Locator wp-store-locator allows Stored XSS.This issue affects WP Store Locator: from n/a through 3.0.3.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The identified security flaw represents a classic instance of Improper Neutralization of Input During Web Page Generation, commonly known as Cross-Site Scripting or XSS. Specifically, this vulnerability manifests within the WP Store Locator plugin for WordPress, affecting versions ranging from its initial release through version 3.0.3. The core technical deficiency lies in the application's failure to adequately sanitize user-supplied input before it is rendered back into the web page context. This lack of proper encoding or validation allows an attacker to inject malicious client-side scripts that are subsequently stored within the application's data store, such as a database, and served to other users without further modification by the server.
This specific implementation constitutes a Stored XSS vulnerability rather than a reflected one. In this scenario, the malicious payload is not merely executed in the context of a single session triggered by a crafted link but is permanently stored on the target server. Consequently, every user who accesses the affected page containing the compromised data will have their browser execute the injected script. This persistence significantly amplifies the potential impact compared to reflected XSS attacks, as it does not require complex social engineering tactics like phishing links to trigger repeatedly; simply visiting a public-facing page where the malicious content was previously submitted is sufficient for exploitation.
The operational impact of this vulnerability is severe and multifaceted. Attackers can leverage the executed JavaScript to perform session hijacking by stealing authentication cookies, thereby gaining unauthorized access to user accounts with elevated privileges if such users are targeted. Furthermore, the attacker can manipulate the DOM (Document Object Model) to deface the website's appearance, redirect visitors to malicious sites hosting malware or phishing content, and harvest sensitive information entered into forms on the page. In enterprise environments using this plugin for internal directories, it could lead to significant data exfiltration of customer contact details stored within the locator database if combined with other techniques like keylogging via injected scripts.
From a classification perspective, this vulnerability aligns directly with CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'). It also maps closely to MITRE ATT&CK technique T1059.007: JavaScript, which describes the use of client-side scripting languages for execution on target systems. The attack vector typically involves an authenticated user or a public-facing input field where data is saved and later displayed, allowing the persistence mechanism inherent in stored XSS to take effect against unsuspecting visitors.
Mitigation strategies must address both immediate remediation and long-term security hygiene. The primary and most effective solution is to upgrade the WP Store Locator plugin to version 3.0.4 or any subsequent release where this vulnerability has been patched by the developers through proper input validation and output encoding techniques such as HTML entity encoding for user-supplied data before rendering it in the browser context. For organizations unable to update immediately due to compatibility constraints, implementing a Web Application Firewall (WAF) with rules specifically tuned to detect and block XSS payloads can provide an additional layer of defense by intercepting malicious requests at the network perimeter. Additionally, enforcing strict Content Security Policy headers that restrict script execution sources can mitigate the impact even if some scripts are injected, as they would fail to execute unless explicitly allowed by the policy directives.