然而，在实践中，许多 Drupal 站点会向普通用户授予内容创建权限（论坛、社区博客、允许投稿的新闻网站）。在这种情况下，攻击者只需注册一个账户即可利用此漏洞。

攻击流程：

根本原因（ROOT CAUSE）

在文件 core/modules/file/file.module 中，有一个正则表达式决定哪些文件被视为可执行文件：

这个正则表达式列出了 7 种扩展名：phar、php、pl、py、cgi、asp、js。任何扩展名匹配此列表的文件都会被 Drupal 自动追加 .txt——从而消除其执行能力。

然而，PHP 引擎并不只处理 .php 文件。根据 Web 服务器的配置，它还会识别并执行其他扩展名：

正则中完全没有这 5 种 PHP 扩展名变体。这意味着一个名为 shell.phtml 的文件被上传到 Drupal 后 → 正则不匹配 → 不会被重命名 → 以原始名称保存到上传目录 → Web 服务器看到 .phtml → 将其作为 PHP 执行 → 攻击者实现 RCE。这就是根本原因：Drupal 使用黑名单来阻止危险扩展名，但该列表并不完整。

各防御层分析

当用户上传文件时，Drupal 会在保存前将其依次通过 3 个验证函数。下面分析为什么这 3 个函数在面对 .phtml 时全部失效。

第 1 层 — file_munge_filename()（core/includes/file.inc）

目的：检测位于文件名中间的危险扩展名，并追加 _ 来破坏它们。函数的工作原理如下：

以 shell.phtml 为例：

• explode 将其拆分为 ["shell", "phtml"]
• shift 取出 "shell"，剩余 ["phtml"]
• pop 取出 "phtml"，剩余 []
• 中间数组为空 → foreach 不执行
• 原样返回 "shell.phtml"

然而，如果文件只有一个扩展名，该函数不会介入。因此，这个函数仅用于处理多扩展名的文件。

第 2 层 — FILE_INSECURE_EXTENSION_REGEX（file.module:1015）

这是主要的防御层。第 1015 行的代码如下：

如果文件名匹配正则 → 将 MIME 类型改为 text/plain，并在末尾追加 .txt。

以 shell.phtml 为例：

• preg_match('/\.(phar|php|pl|py|cgi|asp|js)(\.|$)/i', 'shell.phtml') 返回 0
• 不匹配 → 不会进入 if 代码块 → 文件保留原始名称

因此，这部分本应拦截危险文件，但由于正则不知道 .phtml 是危险的，它便轻松溜了过去。

第 3 层 — 上传目录中的 .htaccess

Drupal 会在 sites/default/files/ 中放置一个 .htaccess 文件：

php_flag engine off 指令会关闭整个目录的 PHP 引擎，但它只对 mod_php5 生效。Drupal 8.7.5 运行在 PHP 7 上，这意味着 mod_php7 处于活动状态且未被禁用。

此外，.htaccess 还有 3 个其他弱点：

• Nginx 不读取 .htaccess——该文件在 Nginx 上完全无效
• Apache 配置了 AllowOverride None → .htaccess 会被忽略
• 使用 PHP-FPM 而非 mod_php 的服务器 → php_flag 指令不生效

漏洞利用

第 1 步 — 创建 webshell

第 2 步 — 上传文件

使用具有上传权限的账户登录 Drupal → 内容 → 添加内容 → 文章 → 在图片字段中选择文件 webshell.phtml → 上传。

Drupal 接受该文件，不会重命名它，并以原始名称将其保存到 sites/default/files/。

第 3 步 — 执行 webshell

之后，使用 whoami 执行 shell 调用：

至此，我们成功以 www-data 身份实现了 RCE。

进一步测试以查看凭据：

结果

攻击者可以读取包含数据库凭据的 settings.php、转储整个数据库、安装反向 shell，或将权限提升至 root。

修复建议

更新正则 — 添加缺失的 5 种扩展名：

更新 .htaccess — 添加对 mod_php7 的禁用：

该补丁有效，但仍依赖黑名单。如果将来出现新的扩展名（.php8、.phpt），正则将需要再次更新。白名单方式——只允许已知的安全扩展名——会是更彻底的解决方案。

总结