CVE-2023-2745

What it actually does

CVE-2023-2745 is a WordPress Core directory traversal weakness in handling of the unauthenticated `wp_lang` parameter in versions up to and including 6.2. By supplying traversal sequences or otherwise unexpected paths, an attacker can cause WordPress to resolve and load translation files outside the intended language directory. The primary impact is unauthorized access to and loading of arbitrary translation files. If an attacker can also place a crafted translation file on the site, for example through an upload feature or another write primitive, the issue can be chained to inject attacker-controlled translated strings and trigger cross-site scripting in affected WordPress pages. The CVSS score is moderate, but the EPSS score is high and exploit maturity is listed as weaponized, indicating practical exploitation is plausible.

Why it matters to the business

A vulnerable WordPress site may allow unauthenticated attackers to abuse language-loading behavior to access or execute attacker-controlled translation content. In practical terms, this can lead to user-facing script injection, credential theft, session hijacking, defacement-like content manipulation, and loss of trust in the affected site. Because WordPress is widely deployed and this issue has a high EPSS score with weaponized exploit maturity, internet-facing sites running unpatched WordPress Core should be treated as a priority even though it is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies a WordPress site running a vulnerable Core version, up to and including 6.2. They then send unauthenticated HTTP requests containing a manipulated `wp_lang` parameter, typically to WordPress endpoints that process language selection, using path traversal sequences or encoded variants to escape the expected translation-file location. If the attacker only has read/load access to existing files, the impact may be limited to loading unintended translation files. If the attacker can upload or otherwise write a crafted translation file to a reachable path, they can point `wp_lang` at that file. When WordPress loads the malicious translation content, attacker-controlled strings may be rendered into the page, enabling cross-site scripting against administrators or users who view the affected page. A successful attack chain may therefore combine file upload capability, directory traversal through `wp_lang`, and victim interaction with a rendered WordPress page containing malicious translated content.

How to fix it

Upgrade WordPress Core to a fixed release. For source-based deployments, ensure the WordPress repository includes the fix commit `206b164e27d3db60ddf5c0b5562b9f92e4fc6fe6`; for `wordpress-develop`, ensure commit `9403a3e285a7d3743d876765b18dd93e81ba2c69` or later is present. Operationally, update WordPress to a current supported version rather than only applying the minimum historical fix. If immediate upgrade is not possible, restrict or monitor requests containing suspicious `wp_lang` values, block traversal sequences in query parameters at the WAF or reverse proxy, disable unnecessary unauthenticated upload paths, prevent upload of translation-related file types such as `.mo` and `.po` unless explicitly required, and ensure uploaded files cannot be interpreted or loaded as application resources. Also review plugins and themes that expose upload functionality, because this vulnerability becomes more serious when an attacker can place crafted translation files on the server.

How to confirm the fix worked

Confirm the installed WordPress Core version is newer than 6.2 or that the relevant fixed source commit is present. From the application host or deployment artifact, verify the WordPress version reported by Core files and package metadata, then compare it with the deployed release baseline. Test externally by sending benign requests containing invalid or traversal-style `wp_lang` values, such as encoded `../` sequences, and confirm the application rejects, ignores, or normalizes them without attempting to load files outside the expected language directory. Review web server logs to ensure no continued successful responses are associated with suspicious `wp_lang` traversal attempts. Where WAF rules are deployed, validate they block encoded and double-encoded traversal patterns, not only literal `../`. Also verify upload controls prevent untrusted users from placing `.mo`, `.po`, or other translation artifacts in locations WordPress could load.

Typical attack path

1. Fingerprint the target as WordPress and determine whether the Core version is 6.2 or earlier.
2. Identify endpoints that accept or process the `wp_lang` parameter, commonly language-selection or login-related WordPress pages.
3. Send unauthenticated requests with traversal payloads in `wp_lang`, including URL-encoded variants, to test whether translation-file path restrictions can be bypassed.
4. If write access is available through an upload form, plugin feature, media workflow, or another vulnerability, upload a crafted translation file to a web-accessible or otherwise readable location.
5. Reference the uploaded translation file through the vulnerable `wp_lang` parameter using traversal sequences.
6. Cause WordPress to load the malicious translation content.
7. Trigger rendering of attacker-controlled translated strings, potentially executing JavaScript in a victim user’s browser.
8. Use the resulting cross-site scripting to steal sessions, perform actions as the victim, alter content, or pivot to broader WordPress compromise.

How to detect it

Investigate historical web access logs, WAF logs, CDN logs, reverse-proxy logs, WordPress application logs, file upload logs, and file integrity monitoring data. Focus on unauthenticated requests containing the `wp_lang` parameter with traversal sequences, URL-encoded traversal, double-encoded traversal, absolute file paths, Windows path separators, or references to `wp-content/uploads`. Correlate suspicious `wp_lang` requests with recent uploads of `.mo`, `.po`, or other localization-related files, especially by unauthenticated or low-privileged users. Review HTTP responses around those requests for successful status codes, unusual redirects, or pages containing unexpected translated strings or script markup. On the filesystem, inspect upload directories, plugin upload locations, theme directories, and language directories for recently modified translation files. If cross-site scripting is suspected, review administrator browser activity where available, WordPress admin actions following suspicious requests, creation of new administrator accounts, plugin/theme modifications, and unexpected content changes. Because exploitation may use encoded variants, normalize URLs before searching and include raw, decoded, and double-decoded query strings in log analysis.

• wp_lang=../
• wp_lang=..%2f
• wp_lang=%2e%2e%2f
• wp_lang=..%252f
• wp_lang=%252e%252e%252f
• wp_lang=..\\
• wp_lang=%2e%2e%5c
• wp_lang=%252e%252e%255c
• wp_lang=/
• wp_lang=%2f
• wp_lang=wp-content/uploads
• wp_lang=..%2f..%2fwp-content%2fuploads
• wp_lang=../../wp-content/uploads
• /wp-login.php?wp_lang=../
• /wp-login.php?wp_lang=%2e%2e%2f
• /wp-admin/?wp_lang=../
• /wp-content/uploads/
• /wp-content/uploads/*.mo
• /wp-content/uploads/*.po
• .mo?wp_lang
• .po?wp_lang

What your security team should do

• Prioritize patching internet-facing WordPress sites because the EPSS score is high and exploitation is considered weaponized.
• Upgrade WordPress Core to a current supported release; for source deployments, verify inclusion of commit `206b164e27d3db60ddf5c0b5562b9f92e4fc6fe6` or the corresponding `wordpress-develop` fix `9403a3e285a7d3743d876765b18dd93e81ba2c69`.
• Search web access logs for suspicious `wp_lang` values containing traversal, encoded traversal, absolute paths, Windows path separators, or references to upload directories.
• Review recent uploads for translation files such as `.mo` and `.po`, especially in `wp-content/uploads/` or plugin/theme-controlled upload paths.
• Add temporary WAF or reverse-proxy rules blocking traversal patterns in `wp_lang` while patching is underway.
• Audit plugins, themes, and custom code that allow unauthenticated or low-privileged file uploads, because file-upload capability can turn this issue into cross-site scripting.
• If suspicious activity is found, preserve web logs, uploaded files, WordPress audit logs, and file modification timestamps before cleanup.
• Rotate administrator sessions and review administrator account activity if there is evidence that malicious script content was served to authenticated users.