CVE-2024-31210

PHP file upload bypass via Plugin installer

HIGH
8.8
CVSS Score
Published: April 4, 2024 at 10:59 PM UTC
Updated: June 17, 2026 at 07:27 AM UTC
1 product affected across 1 vendorWordPress

Using wordpress-develop by WordPress?

Get instant alerts when new vulnerabilities affect wordpress-develop - before attackers find them.

Real-time alertsTrack your software stackFree plan available
Severity
HIGH8.8
Exploit prediction
EPSS 1.0%
SSVC
No known exploit

Description

WordPress is an open publishing platform for the Web. It's possible for a file of a type other than a zip file to be submitted as a new plugin by an administrative user on the Plugins -> Add New -> Upload Plugin screen in WordPress. If FTP credentials are requested for installation (in order to move the file into place outside of the `uploads` directory) then the uploaded file remains temporary available in the Media Library despite it not being allowed. If the `DISALLOW_FILE_EDIT` constant is set to `true` on the site _and_ FTP credentials are required when uploading a new theme or plugin, then this technically allows an RCE when the user would otherwise have no means of executing arbitrary PHP code. This issue _only_ affects Administrator level users on single site installations, and Super Admin level users on Multisite installations where it's otherwise expected that the user does not have permission to upload or execute arbitrary PHP code. Lower level users are not affected. Sites where the `DISALLOW_FILE_MODS` constant is set to `true` are not affected. Sites where an administrative user either does not need to enter FTP credentials or they have access to the valid FTP credentials, are not affected. The issue was fixed in WordPress 6.4.3 on January 30, 2024 and backported to versions 6.3.3, 6.2.4, 6.1.5, 6.0.7, 5.9.9, 5.8.9, 5.7.11, 5.6.13, 5.5.14, 5.4.15, 5.3.17, 5.2.20, 5.1.18, 5.0.21, 4.9.25, 2.8.24, 4.7.28, 4.6.28, 4.5.31, 4.4.32, 4.3.33, 4.2.37, and 4.1.40. A workaround is available. If the `DISALLOW_FILE_MODS` constant is defined as `true` then it will not be possible for any user to upload a plugin and therefore this issue will not be exploitable.

Affected

Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.

v < 4.1.40v < 4.2.37v < 4.3.33v < 4.4.32v < 4.5.31v < 4.6.28v < 4.7.28v < 4.8.24v < 4.9.25v < 5.0.21v < 5.1.18v < 5.2.20v < 5.3.17v < 5.4.15v < 5.5.14v < 5.6.13v < 5.7.11v < 5.8.9v < 5.9.9v < 6.0.7v < 6.1.5v < 6.2.4v < 6.3.3v < 6.4.34.2 ≤ v < 4.2.374.3 ≤ v < 4.3.334.4 ≤ v < 4.4.324.5 ≤ v < 4.5.314.6 ≤ v < 4.6.284.7 ≤ v < 4.7.284.8 ≤ v < 4.8.244.9 ≤ v < 4.9.255.0 ≤ v < 5.0.215.1 ≤ v < 5.1.185.2 ≤ v < 5.2.205.3 ≤ v < 5.3.175.4 ≤ v < 5.4.155.5 ≤ v < 5.5.145.6 ≤ v < 5.6.135.7 ≤ v < 5.7.115.8 ≤ v < 5.8.95.9 ≤ v < 5.9.96.0 ≤ v < 6.0.76.1 ≤ v < 6.1.56.2 ≤ v < 6.2.46.3 ≤ v < 6.3.36.4.0 ≤ v < 6.4.3
Affected range stops below 4.1.40, so it looks safe — our inference, not a vendor statement
Affected range stops below 4.2.37, so it looks safe — our inference, not a vendor statement
Affected range stops below 4.3.33, so it looks safe — our inference, not a vendor statement
Affected range stops below 4.4.32, so it looks safe — our inference, not a vendor statement
Affected range stops below 4.5.31, so it looks safe — our inference, not a vendor statement
Affected range stops below 4.6.28, so it looks safe — our inference, not a vendor statement
Affected range stops below 4.7.28, so it looks safe — our inference, not a vendor statement
Affected range stops below 4.8.24, so it looks safe — our inference, not a vendor statement
Affected range stops below 4.9.25, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.0.21, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.1.18, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.2.20, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.3.17, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.4.15, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.5.14, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.6.13, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.7.11, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.8.9, so it looks safe — our inference, not a vendor statement
Affected range stops below 5.9.9, so it looks safe — our inference, not a vendor statement
Affected range stops below 6.0.7, so it looks safe — our inference, not a vendor statement
Affected range stops below 6.1.5, so it looks safe — our inference, not a vendor statement
Affected range stops below 6.2.4, so it looks safe — our inference, not a vendor statement
Affected range stops below 6.3.3, so it looks safe — our inference, not a vendor statement
Affected range stops below 6.4.3, so it looks safe — our inference, not a vendor statement

Remediation

No guide yet

No remediation guidance has been written for this CVE yet. What the record does show:

SSVC — Action Prioritization

SSVCNo known exploitNot automatableTotal impact

SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.

CVSS

Attack Vector
NETWORK
Complexity
LOW
Privileges
NONE
User Interaction
REQUIRED
Scope
UNCHANGED
Confidentiality
HIGH
Integrity
HIGH
Availability
HIGH
Vector?

Quick Info

StatusANALYZED
CWE
CWE-434

Get alerted

Stop reading CVE feeds looking for your own stack

Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.

Free plan, no card