然而在实际中，许多 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 → 内容 → 添加内容 → 文章 → 在 Image（图片）字段中选择文件 webshell.phtml → 上传。

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

步骤 3 — 执行 webshell

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

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

进一步测试以查看凭据：

结果

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

修复建议

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

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

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

总结