Exploitation Conditions

This vulnerability requires an account with file upload permissions. By default in Drupal 8.7.5, regular users (Authenticated) only have permissions to view content and post comments — no permission to create articles or upload files.

However, in practice, many Drupal sites grant content creation permissions to regular users (forums, community blogs, news sites allowing article submissions). In those cases, an attacker only needs to register an account to exploit it.

Attack Flow:

Root Cause ( ROOT CAUSE )

In the file core/modules/file/file.module, there is a single regex that determines which files are considered executable:

This regex lists 7 extensions: phar, php, pl, py, cgi, asp, js. Any file with an extension matching this list will be automatically appended with .txt by Drupal — neutralizing the ability to execute.

However, the PHP engine does not only process .php files. Depending on the web server configuration, it also recognizes and executes other extensions:

5 PHP extension variants are completely absent from the regex. This means a file named shell.phtml sent to Drupal → regex does not match → not renamed → saved with its original name into the upload directory → web server sees .phtml → executes it as PHP → attacker achieves RCE. This is the root cause: Drupal used a blacklist to block dangerous extensions, but that list was incomplete.

Analysis of Each Defense Layer

When a user uploads a file, Drupal passes it through 3 validation functions before saving. Below is an analysis of why all 3 fail with .phtml.

Layer 1 — file_munge_filename() (core/includes/file.inc)

Purpose: detect dangerous extensions located in the middle of the filename and append _ to disrupt them. How the function works:

For example with shell.phtml:

• explode splits into ["shell", "phtml"]
• shift takes "shell", leaving ["phtml"]
• pop takes "phtml", leaving []
• The middle array is empty → foreach does not execute
• Returns "shell.phtml" intact

However, if the file only has a single extension, it does not intervene. Thus, this function is only designed to handle files with multiple extensions.

Layer 2 — FILE_INSECURE_EXTENSION_REGEX (file.module:1015)

This is the main defense layer. Code at line 1015:

If the filename matches the regex → change MIME to text/plain and append .txt at the end.

With shell.phtml:

• preg_match('/\.(phar|php|pl|py|cgi|asp|js)(\.|$)/i', 'shell.phtml') returns 0
• No match → does not enter the if block → file retains its original name Thus, this section should have blocked dangerous files, but because the regex does not know .phtml is dangerous, it slips right through.

Layer 3 — .htaccess in the upload directory

Drupal places a .htaccess file in sites/default/files/:

The php_flag engine off directive turns off the PHP engine for the entire directory, but it only applies to mod_php5. Drupal 8.7.5 runs on PHP 7, meaning mod_php7 is active and not disabled.

And .htaccess also has 3 other weaknesses:

• Nginx does not read .htaccess — this file is completely ineffective on Nginx
• Apache configured with AllowOverride None → .htaccess is ignored
• Servers using PHP-FPM instead of mod_php → the php_flag directive has no effect

Exploitation

Step 1 — Create webshell

Step 2 — Upload file

Log in to Drupal with an account that has upload permissions → Content → Add content → Article → in the Image field, select the file webshell.phtml → Upload.

Drupal accepts the file, does not rename it, and saves it with its original name into sites/default/files/.

Step 3 — Execute webshell

After that, execute the shell call with whoami:

Thus, we have successfully achieved RCE as www-data.

Testing further to view credentials:

Result

The attacker can read settings.php containing database credentials, dump the entire DB, install a reverse shell, or escalate privileges to root.

Remediation

Update regex — add the 5 missing extensions:

Update .htaccess — add disable for mod_php7:

The patch works but still relies on a blacklist. If new extensions emerge in the future (.php8, .phpt), the regex will need updating again. Whitelisting — only allowing known safe extensions — would be a more thorough approach.

Summary