wordpress-develop: Unrestricted Upload of File with Dangerous Type
CVE-2024-31210 is a high-severity unrestricted upload of file with dangerous type vulnerability in wordpress-develop from WordPress, with a CVSS 3.1 base score of 8.8 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, but only if a user takes part, for example by opening a link or file. The record lists version 6.4.3 as the first without the flaw, so updating wordpress-develop to that release or later removes the exposure. There is no confirmed exploitation so far. EPSS estimates a 1% chance of exploitation within 30 days, higher than 63% of scored CVEs.
High severity with no evidence of exploitation so far.
What to do
- Update wordpress-develop to 6.4.3 or a later version.
- Update Wordpress to 4.1.40 or 4.2.37 or 4.3.33 or 4.4.32, whichever matches your release line, or a later version.
- Read the advisory on github.com for workarounds and exact fixed builds.
- Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.
- Because the attack needs a user to take part, warn users about unexpected links and files related to this product until it is patched.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| WordPress | wordpress-develop | >= 6.4.0, < 6.4.3; >= 6.3.0, < 6.3.3; >= 6.2.0, < 6.2.4; >= 6.1.0, < 6.1.5; >= 6.0.0, < 6.0.7; >= 5.9.0, < 5.9.9; >= 5.8.0, < 5.8.9; >= 5.7.0, < 5.7.11; and 17 more ranges | 6.4.3 |
| WordPress | Wordpress | before 4.1.40; 4.2 up to, but not including, 4.2.37; 4.3 up to, but not including, 4.3.33; 4.4 up to, but not including, 4.4.32; 4.5 up to, but not including, 4.5.31; 4.6 up to, but not including, 4.6.28; 4.7 up to, but not including, 4.7.28; 4.8 up to, but not including, 4.8.24; and 16 more ranges | 4.1.40, 4.2.37, 4.3.33, 4.4.32, 4.5.31, 4.6.28 |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- NetworkCan be exploited remotely over a network, including the internet.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- NoneNo account or login is needed.
- User interaction
- RequiredA user must take an action such as opening a file or link.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- HighAll data handled by the component can be read.
- Integrity
- HighData or code can be modified at will.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. Scored by NVD.
| Scoring system | Score | Severity | Scored by |
|---|---|---|---|
| CVSS 3.1 | 7.6 | High | CNA (github.com) |
| CVSS 3.1 | 8.8 | High | NVD |
Official 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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Unrestricted Upload of File with Dangerous Type
The product allows the upload or transfer of dangerous file types that are automatically processed within its environment.
How developers prevent this class of flaw
- Generate a new, unique filename for an uploaded file instead of using the user-supplied filename, so that no external input is used at all.
- When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
- Consider storing the uploaded files outside of the web document root entirely. Then, use other mechanisms to deliver the files dynamically.
More Unrestricted Upload of File with Dangerous Type vulnerabilities (CWE-434)
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: no, technical impact: total).
- Record last changed materially (score, affected products, status or references).
References
Other vulnerabilities in wordpress-develop
- 9.8 Critical severity
- 8.8 High severity
- 7.2 High severity
- 7.5 High severity
Recent Unrestricted Upload of File with Dangerous Type vulnerabilities
- 7.2 High severity
- 7.2 High severity
- 9.8 Critical severity
- 7.5 High severity
- 10.0 Critical severity
- 9.1 Critical severity
Spotted an error? Tell us.