WordPress Core < 6.2.1 - Cross-Site Request Forgery

2023-05-16 00:00
John Blackbourn

Strategic Overview

Status
Patched in 4.1.38
Affected Core
WordPress 6.2
Affected Version
4.1 – < 6.2.1 · 23 branches
CVSS
4.3Medium
Weakness type
CWE-352 · Cross-Site Request Forgery (CSRF)
CVE
CVE pending
View all WordPress 6.2 vulnerabilities

At a glance

This record tracks a medium-severity Cross-Site Request Forgery (CSRF) vulnerability in the WordPress 6.2 WordPress release line, affecting 4.1 – < 6.2.1 · 23 branches. It carries a CVSS score of 4.3 (reachable over the network; low attack complexity). Exploitation requires no authentication. The issue is fixed in version 4.1.38; sites on affected versions should update now. Disclosed May 2023, reported by John Blackbourn.

Vulnerability Overview

WordPress Core is vulnerable to Cross-Site Request Forgery due to missing nonce validation on the ‘wp_ajax_set_attachment_thumbnail’ AJAX function in versions up to, and including, 6.2. This allows unauthenticated users to update the thumbnail image associated with existing attachments, granted they can trick an authenticated user with appropriate permissions into performing an action, such as clicking a link. The impact of this vulnerability is incredibly minimal.

Technical Analysis

The vector marks this flaw as remotely reachable over the network, with low attack complexity — no special timing or configuration is needed, and no privileges on the target site.

CWE-352: Cross-Site Request Forgery (CSRF)

WordPress 6.2 4.1 – < 6.2.1 · 23 branches carries this weakness at wp_ajax_set_attachment_thumbnail, and reaching it takes a caller who can reach the endpoint. Cross-site request forgery abuses the fact that browsers attach a victim's cookies to any request, so a state-changing action that only checks who you are, not whether you meant to act, can be triggered from another site.

An attacker who gets a logged-in user to load a crafted page can perform that action as them, with the impact scaling to whatever the victim's role is allowed to do. For WordPress 6.2 the fix is 4.1.38: builds 4.1 – < 6.2.1 · 23 branches are affected, anything from 4.1.38 onward is not.

Remediation

Update to one of the following versions, or a newer patched version: 4.1.38, 4.2.35, 4.3.31, 4.4.30, 4.5.29, 4.6.26, 4.7.26, 4.8.22, 4.9.23, 5.0.19, 5.1.16, 5.2.18, 5.3.15, 5.4.13, 5.5.12, 5.6.11, 5.7.9, 5.8.7, 5.9.6, 6.0.4, 6.1.2, 6.2.1

How does WordSec protect against this?

The attempt arrives as an ordinary request to WordPress 6.2: WordSec's web application firewall inspects request payloads before WordPress loads them. None of that substitutes for the fix: updating to 4.1.38 is the step that ends it.

  • Firewall
  • Alerts

External References

https://www.wordfence.com/threat-intel/vulnerabilities/id/0da1cc3b-5d6b-4ca0-9d8a-31c63ab5b9c9

Related records

Vulnerability data © Defiant, Inc., provided under the Wordfence Intelligence T&C