CVE-2024-31210: WordPress Core maybe_unserialize Deserialization of Untrusted Data Remote Code Execution Vulnerability
This vulnerability allows remote attackers to execute arbitrary code on affected installations of WordPress Core. Authentication may be required to exploit this vulnerability, depending on the product configuration. The specific flaw exists within the maybeunserialize function. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the service account.
Other sources
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 DISALLOWFILEEDIT 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 DISALLOWFILEMODS 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 DISALLOWFILEMODS 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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/wordpressto a version that resolves this vulnerability.Fixed in 6.1.6+dfsg1-0+deb12u1 - Upgrade
Upgrade
debian/wordpressto a version that resolves this vulnerability.Fixed in 6.4.3+dfsg1-1 - Upgrade
Upgrade
debian/wordpressto a version that resolves this vulnerability.Fixed in 6.1.9+dfsg1-0+deb12u1Fixed in 6.8.7+dfsg1-0+deb13u1Fixed in 6.8.12+dfsg1-0+deb13u1Fixed in 7.1.4+dfsg1-1 - Upgrade
Upgrade
WordPress Coreto a version that resolves this vulnerability.Fixed in 6.4.3 - Configuration
Define the DISALLOW_FILE_MODS constant as true to prevent users from uploading plugins and make the issue non-exploitable.
WordPress DISALLOW_FILE_MODS = true
Event History
Frequently Asked Questions
What is the severity of CVE-2024-31210?
CVE-2024-31210 has a high severity due to the potential for unauthorized file uploads via the WordPress plugin installation process.
How do I fix CVE-2024-31210?
To fix CVE-2024-31210, update WordPress to version 6.4.4 or later immediately to patch the vulnerability.
Who is affected by CVE-2024-31210?
CVE-2024-31210 affects all WordPress installations up to version 6.4.3 that allow file uploads through the plugin installation interface.
What kind of files can be exploited in CVE-2024-31210?
CVE-2024-31210 can be exploited to upload malicious files that are not zip files, compromising the WordPress installation.
Is there a workaround for CVE-2024-31210?
As a temporary workaround for CVE-2024-31210, you can restrict plugin uploads by disabling the plugin upload feature in the WordPress dashboard.