CVE-2024-31210
PHP file upload bypass via Plugin installer
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.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- High
- Privileges needed
- High
- User interaction
- Required
What an attacker can affect
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Exploit likelihood
What each source reports
CVE List Score used
7.7
PHP file upload bypass via Plugin installer
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.
- Record
CVE-2024-31210- CVSS 3.1
- 7.7 High
CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:H - Weakness
- CWE-434
- Updated
- 2026-11-02
EUVDEUVD-2024-29110
7.7
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.
- Record
EUVD-2024-29110- CVSS 3.1
- 7.7 High
CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:H - Updated
- 2026-11-03
NVD
7.6
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.
- Record
CVE-2024-31210- CVSS 3.1
- 7.6 High
CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:H - CVSS 3.1
- 8.8 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H - Weakness
- CWE-434
- Updated
- 2026-11-02
OSV
7.6
PHP file upload bypass via Plugin installer
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.
- Record
CVE-2024-31210- CVSS 3.1
- 7.6 High
CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:H - Weakness
- CWE-434
- Updated
- 2026-11-02
OSVDEBIAN-CVE-2024-31210
8.8
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.
- Record
DEBIAN-CVE-2024-31210- CVSS 3.1
- 8.8 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
OSVUBUNTU-CVE-2024-31210
7.6
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.
- Record
UBUNTU-CVE-2024-31210- CVSS 3.1
- 7.6 High
CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:H/A:H - CVSS 3.1
- 8.8 High
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H - Updated
- 2026-11-02
OSVBIT-wordpress-2024-31210 No score
PHP file upload bypass via Plugin installer
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.
- Record
BIT-wordpress-2024-31210- Updated
- 2026-11-02
OSVBIT-wordpress-multisite-2024-31210 No score
PHP file upload bypass via Plugin installer
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.
- Record
BIT-wordpress-multisite-2024-31210- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
wordpressBitnami |
before 4.1.40, 4.2.0 up to 4.2.37, 4.3.0 up to 4.3.33, 4.4.0 up to 4.4.32, 4.5.0 up to 4.5.31, 4.6.0 up to 4.6.28, 4.7.0 up to 4.7.28, 4.8.0 up to 4.8.24, 4.9.0 up to 4.9.25, 5.0.0 up to 5.0.21, 5.1.0 up to 5.1.18, 5.2.0 up to 5.2.20, 5.3.0 up to 5.3.17, 5.4.0 up to 5.4.15, 5.5.0 up to 5.5.14, 5.6.0 up to 5.6.13, 5.7.0 up to 5.7.11, 5.8.0 up to 5.8.9, 5.9.0 up to 5.9.9, 6.0.0 up to 6.0.7, 6.1.0 up to 6.1.5, 6.2.0 up to 6.2.4, 6.3.0 up to 6.3.3, 6.4.0 up to 6.4.3 | 4.1.404.2.374.3.334.4.324.5.314.6.284.7.284.8.244.9.255.0.215.1.185.2.205.3.175.4.155.5.145.6.135.7.115.8.95.9.96.0.76.1.56.2.46.3.36.4.3 |
wordpress-multisiteBitnami |
before 4.1.40, 4.2.0 up to 4.2.37, 4.3.0 up to 4.3.33, 4.4.0 up to 4.4.32, 4.5.0 up to 4.5.31, 4.6.0 up to 4.6.28, 4.7.0 up to 4.7.28, 4.8.0 up to 4.8.24, 4.9.0 up to 4.9.25, 5.0.0 up to 5.0.21, 5.1.0 up to 5.1.18, 5.2.0 up to 5.2.20, 5.3.0 up to 5.3.17, 5.4.0 up to 5.4.15, 5.5.0 up to 5.5.14, 5.6.0 up to 5.6.13, 5.7.0 up to 5.7.11, 5.8.0 up to 5.8.9, 5.9.0 up to 5.9.9, 6.0.0 up to 6.0.7, 6.1.0 up to 6.1.5, 6.2.0 up to 6.2.4, 6.3.0 up to 6.3.3, 6.4.0 up to 6.4.3 | 4.1.404.2.374.3.334.4.324.5.314.6.284.7.284.8.244.9.255.0.215.1.185.2.205.3.175.4.155.5.145.6.135.7.115.8.95.9.96.0.76.1.56.2.46.3.36.4.3 |
wordpressDebian:12 |
before 6.1.6+dfsg1-0+deb12u1, plus listed versions 6.1.1+dfsg1-1 |
6.1.6+dfsg1-0+deb12u1 |
wordpressDebian:13 |
before 6.4.3+dfsg1-1 | 6.4.3+dfsg1-1 |
wordpressDebian:14 |
before 6.4.3+dfsg1-1 | 6.4.3+dfsg1-1 |
wordpressDebian:11 From an advisory covering 4 CVEs |
before 5.7.11+dfsg1-0+deb11u1, plus listed versions 5.7.1+dfsg1-25.7.3+dfsg1-0+deb11u15.7.5+dfsg1-0+deb11u15.7.8+dfsg1-0+deb11u15.7.8+dfsg1-0+deb11u2 |
5.7.11+dfsg1-0+deb11u1 |
wordpressDebian:12 From an advisory covering 4 CVEs |
before 6.1.6+dfsg1-0+deb12u1, plus listed versions 6.1.1+dfsg1-1 |
6.1.6+dfsg1-0+deb12u1 |
wordpressUbuntu:16.04:LTS |
All versions, plus listed versions 4.3+dfsg-14.3.1+dfsg-14.4+dfsg-14.4.1+dfsg-14.4.2+dfsg-14.4.2+dfsg-1ubuntu1 |
None known |
wordpressUbuntu:18.04:LTS |
All versions, plus listed versions 4.8.2+dfsg-24.8.3+dfsg-14.9.1+dfsg-14.9.2+dfsg-14.9.4+dfsg-14.9.5+dfsg1-1 |
None known |
wordpressUbuntu:20.04:LTS |
All versions, plus listed versions 5.2.2+dfsg1-15.2.4+dfsg1-15.3.2+dfsg1-15.3.2+dfsg1-1ubuntu1 |
None known |
wordpressUbuntu:22.04:LTS |
All versions, plus listed versions 5.7.1+dfsg1-2ubuntu15.8.1+dfsg1-2ubuntu15.8.2+dfsg1-1ubuntu15.8.3+dfsg1-1ubuntu15.8.3+dfsg1-1ubuntu1.1 |
None known |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected, facts | ||
| aliases, published | EUVD | |
| first indexed | CVE List, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2024-31210 is a high vulnerability (CVSS 7.7) in Wordpress, published April 4, 2024. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 1.00%, the 62nd percentile. Fixed in wordpress 4.1.40.
References
github.com/WordPress/wordpress-develop/security/advisories/GHSA-x79f-xrjv-jx5r
nvd.nist.gov/vuln/detail/CVE-2024-31210
github.com/CVEProject/cvelistV5/tree/main/cves/2024/31xxx/CVE-2024-31210.json
security-tracker.debian.org/tracker/CVE-2024-31210
ubuntu.com/security/CVE-2024-31210
wordpress.org/news/2024/01/wordpress-6-4-3-maintenance-and-security-release
cve.org/CVERecord?id=CVE-2024-31210