Cloudanix VulnDB

CVE-2024-31210

High · 7.6

CVSS

7.6

EPSS

0.9%

Published

Apr 4, 2024

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

WordPress could let certain administrators run unapproved code on the site when specific security settings and file transfer requirements are active.

Exploitation
Remote Authenticated
Attacker needs
High Privilege
Complexity
High
Impact
Remote Code Execution
Component
Application
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Allows an administrative user to submit a non-zip file as a plugin upload; when FTP credentials are prompted for installation and DISALLOW_FILE_EDIT is true, the file remains accessible in the media library enabling arbitrary PHP execution for users otherwise restricted from such actions.

Why it matters to the business

May permit restricted administrator accounts to achieve full site control on affected WordPress installations, increasing risk of unauthorized changes, data exposure, or persistent compromise especially on sites with file modification restrictions enabled.

How an attack unfolds

An attacker logs in with administrator or super-admin rights, submits a crafted non-zip file through the plugin upload interface, triggers the FTP credential flow that leaves the file in the media library, and then executes the uploaded PHP code to bypass intended restrictions on arbitrary code execution.

How to fix it

Upgrade to WordPress 6.4.3 or any of the backported fixed releases (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, 4.7.28, 4.6.28, 4.5.31, 4.4.32, 4.3.33, 4.2.37, 4.1.40); alternatively define DISALLOW_FILE_MODS as true to block all plugin uploads.

How to confirm the fix worked

Confirm the installed WordPress version matches a listed fixed release or contains the referenced commits; test the upload plugin flow to ensure non-zip files are rejected before any temporary storage occurs.

Typical attack path

  1. Log in with administrator or super-admin privileges on a single-site or multisite installation
  2. Access the Plugins > Add New > Upload Plugin interface
  3. Submit a file that is not a valid zip archive containing PHP code
  4. Trigger the FTP credential prompt during attempted installation
  5. Locate and invoke the file now stored in the media library to execute code

How to detect it

Inspect the media library for files uploaded outside normal plugin flows, review web server and WordPress logs for plugin upload events that coincide with FTP prompts, and search for unexpected PHP files appearing after administrator plugin activity.

What your security team should do

  • Apply the appropriate WordPress update across all instances without delay
  • Audit current DISALLOW_FILE_EDIT and DISALLOW_FILE_MODS settings and enforce the stricter constant where possible
  • Review administrator accounts and reduce unnecessary privileges on sites that require FTP for updates

The record

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 packages

Ecosystem Package Introduced Fixed
Bitnami wordpress 0 4.1.40
Bitnami wordpress 6.4.0 6.4.3
Bitnami wordpress-multisite 0 4.1.40
Bitnami wordpress-multisite 6.4.0 6.4.3
Debian:11 wordpress 0 5.7.11+dfsg1-0+deb11u1
Debian:12 wordpress 0 6.1.6+dfsg1-0+deb12u1
Debian:13 wordpress 0 6.4.3+dfsg1-1
Ubuntu:16.04:LTS wordpress 0 No fix
Ubuntu:18.04:LTS wordpress 0 No fix
Ubuntu:20.04:LTS wordpress 0 No fix
Ubuntu:22.04:LTS wordpress 0 No fix
Ubuntu:24.04:LTS wordpress 0 6.4.3+dfsg1-1ubuntu1
Ubuntu:24.10 wordpress 0 6.4.3+dfsg1-1ubuntu1
Ubuntu:Pro:16.04:LTS wordpress 0 No fix
Ubuntu:Pro:18.04:LTS wordpress 0 No fix
Ubuntu:Pro:20.04:LTS wordpress 0 No fix

Related vulnerabilities