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.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2024-31210)

Note that Nessus relies on the presence of the package as reported by the vendor.

WordPress versions < 6.6.1 are affected by one or more vulnerabilities

The remote Debian 11 / 12 host has packages installed that are affected by multiple vulnerabilities as referenced in the dsa-5685 advisory.

  - WordPress Core is vulnerable to Directory Traversal in versions up to, and including, 6.2, via the     wp_lang' parameter. This allows unauthenticated attackers to access and load arbitrary translation files.
    In cases where an attacker is able to upload a crafted translation file onto the site, such as via an     upload form, this could be also used to perform a Cross-Site Scripting attack. (CVE-2023-2745)

  - Auth. Stored (contributor+) Cross-Site Scripting (XSS) vulnerability in WordPress core 6.3 through 6.3.1,     from 6.2 through 6.2.2, from 6.1 through 6.1.3, from 6.0 through 6.0.5, from 5.9 through 5.9.7 and     Gutenberg plugin <= 16.8.0 versions. (CVE-2023-38000)

  - Exposure of Sensitive Information to an Unauthorized Actor in WordPress from 6.3 through 6.3.1, from 6.2     through 6.2.2, from 6.1 through 6.13, from 6.0 through 6.0.5, from 5.9 through 5.9.7, from 5.8 through     5.8.7, from 5.7 through 5.7.9, from 5.6 through 5.6.11, from 5.5 through 5.5.12, from 5.4 through 5.4.13,     from 5.3 through 5.3.15, from 5.2 through 5.2.18, from 5.1 through 5.1.16, from 5.0 through 5.0.19, from     4.9 through 4.9.23, from 4.8 through 4.8.22, from 4.7 through 4.7.26, from 4.6 through 4.6.26, from 4.5     through 4.5.29, from 4.4 through 4.4.30, from 4.3 through 4.3.31, from 4.2 through 4.2.35, from 4.1     through 4.1.38. (CVE-2023-39999)

  - WordPress does not properly restrict which user fields are searchable via the REST API, allowing     unauthenticated attackers to discern the email addresses of users who have published public posts on an     affected website via an Oracle style attack (CVE-2023-5561)

  - 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. (CVE-2024-31210)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Severity
250775	Linux Distros Unpatched Vulnerability : CVE-2024-31210	Nessus	Misc.	high
204968	WordPress < 6.6.1	Nessus	CGI abuses	high
195202	Debian dsa-5685 : wordpress - security update	Nessus	Debian Local Security Checks	medium

Detections

Analytics

CVE-2024-31210

high

Tenable Plugins

high

high

medium