WordPress vulnerability allows deletion of any file

Disclosed WordPress vulnerability affects current 4.9.6 and earlier WordPress versions

Recently disclosed WordPress vulnerability made a massive shock to some WordPress community members. It’s not the vulnerability itself. Some users were shocked by the fact that it was already reported to the WordPress Security team about seven months ago. Well, let’s analyze everything step by step.

Disclosed WordPress vulnerability

First of all, relax. I can say that most of the WordPress sites are not affected by this vulnerability. In order to exploit this vulnerability, certain conditions are required. In this case, an attacker must have sufficient rights to edit and delete media files (for example “author” role or any custom role with the previously mentioned rights). There are several possible ways to affect site security by exploiting this vulnerability.

  • An attacker can delete the .htaccess file and gain access to some files or folders that were restricted by the custom rules of that particular .htaccess file.
  • Also, it is possible to delete index.php files from various folders and make them accessible for a directory listing to see all the files and folder structure.
  • More sophisticated exploitation vector possible by deleting a wp-config.php file, it will allow an attacker to access WordPress installation procedure and gain more control over the site.
  • Finally, I need to mention that it is possible to delete any file and partially deface or entirely screw up the site.

Temporary WordPress vulnerability fix

As I said before this vulnerability affects only websites with users that have “author” or similar roles with the capability to edit and delete media files. If you want to fix this issue before the official WordPress security release, you can use the code provided below.

add_filter( 'wp_update_attachment_metadata', 'rips_unlink_tempfix' );

function rips_unlink_tempfix( $data ) {
if( isset($data['thumb']) ) {
$data['thumb'] = basename($data['thumb']);

return $data;

You need to put this piece of code to the functions.php file of your active theme or child theme. Don’t forget to remove this code once you update your WordPress to the patched version (I think we will see this release quite soon).

Timeline of events

According to the vulnerability authors (RIPSTECH), this issue is known by WordPress security team for more than seven months since the day of the report:

2017/11/20 – WordPress Vulnerability reported to the WordPress security team on Hackerone.
2017/11/22 – The vulnerability was triaged and verified by the security team.
2017/12/12 – Asked for progress.
2017/12/18 – WordPress is working on a patch. Asked for the release date. No response.
2018/01/09 – Asked for the release date. No response.
2018/01/20 – Asked for mediation on Hackerone due to the severity of the issue and the lack of communication.
2018/01/24 – The WordPress security team estimates the time to fix to be six months.
2018/05/24 – Asked for progress and/or plans on the issue, and given a reminder that we would publish it soon. No response.
2018/05/24 – Sent twitter DM to a member of the security team to make sure they do not overlook the message on Hackerone.
2018/06/26 – The issue remains unpatched more than seven months after reporting. Information disclosed.

This vulnerability now has the CVE number and the database entry CVE-2018-12895. Also, it already appears in the ThreatPress database of WordPress vulnerabilities.

Don’t worry if you don’t have any untrusted users with the rights mentioned above and if you do, make sure you put that temporary fix code to the functions.php file of your active theme or child theme.

Leave a Reply

Your email address will not be published. Required fields are marked *