CVE-2025-26768: what3words Address Field CSRF Vulnerability

CVE-2025-26768 Overview

A Cross-Site Request Forgery (CSRF) vulnerability exists in the what3words Address Field WordPress plugin (3-word-address-validation-field) that enables Stored Cross-Site Scripting (XSS) attacks. This chained vulnerability allows attackers to trick authenticated administrators into unknowingly submitting malicious requests that inject persistent JavaScript code into the WordPress site. Once stored, the malicious scripts execute in the browsers of any user viewing the affected pages.

Critical Impact

Attackers can chain CSRF with Stored XSS to achieve persistent code execution in victim browsers, potentially leading to credential theft, session hijacking, administrative account takeover, and website defacement.

Affected Products

• what3words Address Field WordPress plugin versions up to and including 4.0.15
• WordPress installations using the 3-word-address-validation-field plugin

Discovery Timeline

• 2025-02-16 - CVE-2025-26768 published to NVD
• 2026-04-01 - Last updated in NVD database

Technical Details for CVE-2025-26768

Vulnerability Analysis

This vulnerability represents a chained attack scenario combining two distinct web application weaknesses. The what3words Address Field plugin fails to implement proper CSRF token validation on certain administrative actions, allowing attackers to craft malicious requests that execute in the context of an authenticated administrator's session. The lack of input sanitization and output encoding on user-supplied data creates the secondary Stored XSS condition.

When an administrator is tricked into visiting an attacker-controlled page while logged into WordPress, the malicious page can submit forms or trigger requests to the vulnerable plugin endpoints. Because the plugin does not verify the authenticity of these requests through CSRF tokens, it processes them as legitimate. The injected payload is then stored in the database and rendered without proper escaping to all users viewing affected content.

Root Cause

The vulnerability stems from two related implementation failures in the what3words Address Field plugin. First, the plugin does not implement WordPress nonce verification (wp_verify_nonce()) on state-changing requests, making it susceptible to CSRF attacks. Second, user input is stored and later displayed without proper sanitization using functions like esc_html(), esc_attr(), or wp_kses(), enabling the Stored XSS component.

Attack Vector

An attacker would create a malicious webpage containing a hidden form that targets the vulnerable plugin endpoint. The attacker then entices an authenticated WordPress administrator to visit this page—often through phishing emails or compromised websites. When the admin visits the page, JavaScript automatically submits the hidden form containing malicious XSS payload to the WordPress admin panel. Since the admin's browser includes their valid session cookies, the vulnerable plugin processes the request and stores the malicious script in the database.

The vulnerability mechanism works as follows: The attacker crafts an HTML page with a form targeting the vulnerable WordPress plugin endpoint. This form includes hidden fields containing the XSS payload (typically malicious JavaScript). When an authenticated administrator visits this page, the form auto-submits via JavaScript, and the plugin stores the payload without proper validation. Subsequently, any user viewing pages where the stored content is rendered will have the malicious script execute in their browser context.

For additional technical details, refer to the Patchstack Vulnerability Report.

Detection Methods for CVE-2025-26768

Indicators of Compromise

• Unexpected JavaScript code or <script> tags in what3words Address Field plugin settings or stored data
• Suspicious administrative activity from unusual IP addresses or at unusual times
• Browser developer tools showing requests to external domains from plugin-generated content
• User reports of unexpected popups, redirects, or browser warnings on pages using the plugin

Detection Strategies

• Implement Web Application Firewall (WAF) rules to detect and block XSS payloads in POST requests targeting WordPress plugin endpoints
• Enable WordPress audit logging to track changes to plugin settings and identify unauthorized modifications
• Deploy Content Security Policy (CSP) headers to prevent inline script execution and detect policy violations
• Monitor server access logs for suspicious POST requests to /wp-admin/ endpoints with unusual referrer headers

Monitoring Recommendations

• Configure alerting for any modifications to what3words Address Field plugin configuration
• Implement browser-based XSS detection through CSP violation reporting endpoints
• Review WordPress audit logs regularly for administrator actions performed without corresponding login events
• Set up network monitoring to detect outbound connections to suspicious domains from the web server

How to Mitigate CVE-2025-26768

Immediate Actions Required

• Update the what3words Address Field plugin to a patched version beyond 4.0.15 when available
• Audit all stored data associated with the plugin for evidence of injected malicious content
• Review WordPress administrator accounts for any suspicious activity or unauthorized changes
• Consider temporarily disabling the plugin until a patched version is released

Patch Information

Monitor the WordPress plugin repository and the vendor for security updates addressing this vulnerability. The Patchstack Vulnerability Report provides tracking information for this issue.

Workarounds

• Implement a Web Application Firewall with rules to block CSRF and XSS attack patterns targeting WordPress plugins
• Add Content Security Policy headers to prevent inline script execution: Content-Security-Policy: script-src 'self';
• Restrict WordPress admin panel access to trusted IP addresses only
• Ensure administrators are educated about phishing risks and avoid clicking untrusted links while logged into WordPress

# Add CSP headers in Apache .htaccess to mitigate XSS impact
<IfModule mod_headers.c>
    Header set Content-Security-Policy "script-src 'self'; object-src 'none';"
    Header set X-Content-Type-Options "nosniff"
    Header set X-Frame-Options "SAMEORIGIN"
</IfModule>