一种高严重性的本地文件包含（LFI）漏洞已被披露，影响Welldone WordPress主题（版本≤ 2.4）。该漏洞被追踪为CVE-2026-28118，并被分配了8.1的CVSS基础分数，这一弱点允许未经身份验证的攻击者在易受攻击的网站上包含本地文件并暴露其内容。本地文件中的信息（数据库凭据、API密钥、配置细节）可能导致完全妥协——任何使用受影响主题的网站都需要立即采取行动。.

本建议以实用的香港安全从业者语气撰写：简洁、优先级明确，专注于快速遏制，然后进行验证和恢复。如果您管理多个网站，请与您的运营或托管团队分享此信息，并优先考虑“立即缓解”步骤。.

披露摘要

• 受影响的软件：Welldone WordPress主题
• 易受攻击的版本：≤ 2.4
• 漏洞类型：本地文件包含 (LFI)
• CVE：CVE-2026-28118
• CVSS：8.1（高）
• 所需权限：无（未认证）
• 影响：任意本地文件读取；可能泄露凭据和敏感文件；可能根据服务器配置导致完全接管
• 报告人：Tran Nguyen Bao Khanh（报告于2025年8月19日；公开披露于2026年2月26日）

为什么 LFI 对 WordPress 网站如此危险

本地文件包含发生在代码使用用户提供的输入构建本地文件路径而没有适当验证时，然后包含或读取该文件。在PHP中，include()、require()、include_once()和require_once()等函数是常见的失败点——尤其是在根据查询参数加载模板部分或文件的主题和插件中。.

对于WordPress，后果是严重的：

• wp-config.php通常包含数据库凭据和盐；读取它可以让攻击者获得完全的数据库访问权限。.
• 其他文件可能包含API密钥、SMTP凭据或专有数据。.
• PHP流包装器（php://filter，data://）或可访问的上传位置可以帮助攻击者从读取文件升级到执行代码。.
• 该缺陷是未经身份验证的，因此大规模自动扫描和利用是可能的；预计机会主义攻击者会快速扫描。.

攻击者通常如何利用LFI（高级别）

攻击者找到一个用于include()调用的参数（例如：include( $template_path . $_GET[‘page’] . ‘.php’ );）。没有验证，攻击者可以发送目录遍历有效负载（../../../../wp-config.php）或使用PHP流包装器（php://filter）读取任意本地文件。LFI通常可以链接以通过暴露可写的上传区域或日志文件来实现远程代码执行（RCE）。.

我们在这里不提供有效的利用有效负载；防御者应专注于识别下面列出的模式和指标。.

攻击和妥协的指标——需要注意什么

监控 web 服务器访问日志、PHP 错误日志以及任何 WordPress 日志以查找这些迹象：

1. 查询字符串中包含目录遍历模式的请求：
   • 未编码或编码的“../”序列（例如，, ..%2F, %2e%2e%2f)
   • 重复的遍历尝试，如 ../../../../
2. 引用敏感文件名的请求：
   • wp-config.php, wp-config.php.bak, .env, /etc/passwd, .htpasswd
3. 使用常见 LFI 参数名称的请求：
   • 名为 file, 页面, 模板, inc, 路径, 模块
   • 向主题端点发送多样化的遍历负载突发
4. 使用 PHP 流包装器模式：
   • php://filter, expect://, data:// 在查询参数中
5. 可写目录下的异常文件或修改：
   • 新的或可疑的 PHP/JS 文件在 wp-content/uploads, wp-content/themes//
   • 意外修改的模板或插件文件
6. 异常的数据库活动：意外的管理员用户创建、奇怪的查询或内容注入。.

如果您发现任何这些指标，请将情况视为高优先级，并遵循下面的事件响应检查表。.

立即（小时内）缓解——经过分类和实用的行动

这些步骤按速度和可能影响的顺序排列。如果您运行受影响的主题或不确定，请立即执行它们。.

1. 暂时禁用易受攻击的主题
   • 切换到一个标准的、维护的默认主题，以快速减少攻击面。.
   • 如果无法切换，请在应用其他缓解措施时将网站置于维护模式。.
2. 从文件系统中移除或隔离易受攻击的主题
   • 使用 SFTP/SSH，重命名或移除易受攻击的主题目录 wp-content/themes/ 以防止主题代码运行。.
   • 如果您正在调查，请保留一个离线副本以供分析。.
3. 在 Web 服务器上阻止可疑请求
   • 在 Web 服务器级别（nginx 或 Apache）阻止包含目录遍历序列和 PHP 流包装器的请求。首先在暂存环境中测试任何规则，以避免破坏合法流量。.
   • 示例 nginx（概念）：

   if ($request_uri ~* "(%2e|%2f|\.\./|\.\.\\)") {
       return 403;
   }
   if ($request_uri ~* "php://|data://|expect://|file://") {
       return 403;
   }

   • 示例 Apache (.htaccess) — 拒绝直接访问 wp-config 并阻止可疑查询字符串：

   <Files "wp-config.php">
     Order allow,deny
     Deny from all
   </Files>
   
   <IfModule mod_rewrite.c>
     RewriteEngine On
     RewriteCond %{QUERY_STRING} (\.\.|php://|data://) [NC,OR]
     RewriteCond %{REQUEST_URI} (\.\.|php://|data://) [NC]
     RewriteRule ^.* - [F,L]
   </IfModule>

4. 加固文件权限和所有权（快速检查）
   • 确保 wp-config.php 不是全局可读的：使用 400 或 440 在适当的地方。.
   • 标准设置：目录 755，文件 644（进一步收紧敏感文件）。.
   • 确保适当的所有权，并避免以能够修改网站文件的同一用户运行 Web 服务器进程，如果您的主机支持分离。.
5. 在可能的情况下禁用危险的 PHP 包装器和函数
   • 在 php.ini, ，设置 allow_url_fopen = 关闭 和 allow_url_include = 关闭.
   • 如果不需要，请考虑禁用风险函数： 执行, shell_exec, 系统, passthru, proc_open, popen. 示例：

   disable_functions = exec,shell_exec,system,passthru,proc_open,popen

6. 阻止用户提供的用于文件加载的参数
   • 如果主题端点接受 file 或 模板 参数，请添加临时服务器端规则以阻止或验证这些参数，直到您可以修补。.

中期（天）修复和验证

1. 替换或更新主题
   • 检查是否有官方修补的Welldone版本来解决CVE-2026-28118。当可用时，在暂存环境中测试，然后部署到生产环境。.
   • 如果没有补丁，请考虑用维护的替代主题替换该主题，或创建一个维护的基础主题的自定义子主题。.
2. 审计您的文件系统以查找Webshell和可疑文件
   • 扫描 wp-content/uploads, ，主题和插件目录中查找意外的PHP文件、最近的修改或已知的IOC模式。.
3. 轮换凭据和秘密
   • 轮换所有WordPress管理员密码、数据库凭据、API密钥和可能已暴露的任何令牌。.
   • 从备份恢复后，始终轮换凭据。.
4. 审查服务器和应用程序日志
   • 在披露日期之前和之后搜索日志以查找利用的迹象。如果需要，将相关日志导出到安全位置以进行取证。.
5. 完整网站恶意软件扫描和完整性检查
   • 运行恶意软件扫描器和文件完整性检查，以查找Webshell、后门和修改的核心文件。将代码与已知良好的来源进行比较。.
6. 如果确认被攻破，请从干净的备份中恢复
   • 如果您无法自信地清理被攻破的网站，请从在最早的攻击迹象之前进行的已知良好的备份中恢复。恢复后，应用加固并轮换凭据。.

长期预防和加固（周/持续进行）

• 最小权限原则：确保文件和数据库用户仅具有所需的权限。.
• 1. 隔离环境：在暂存和生产之间使用单独的凭据和隔离。.
• 2. 持续监控和警报：集中日志并为目录遍历尝试、引用和错误的异常激增添加警报。 wp-config.php, ，以及错误的异常峰值。.
• 4. 定期漏洞扫描和代码审查：自动扫描加上定期手动审查主题和插件代码。.
• 5. 定期备份和测试恢复：异地、版本化备份和定期恢复测试。.
• 6. WordPress 加固：保持核心、插件和主题更新；移除未使用的组件；禁用文件编辑器；实施安全头并强制使用 HTTPS。.

7. 建议的检测和防止规则（概念性）

8. 将这些模式适配到您的 WAF 或服务器规则集中，并进行彻底测试以避免误报。这些是用于规则创建的概念性正则表达式片段：

• 9. 阻止目录遍历： (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c)
• 11. 阻止 PHP 流包装器： 12. (php://|data://|expect://|zip://|phar://)
• 13. 阻止对敏感文件的引用： 14. (wp-config\.php|/etc/passwd|/proc/self/environ|\.env|\.htpasswd)
• 15. 阻止常用于混淆的长编码序列： 16. (%[0-9A-Fa-f]{2}){6,}

17. 示例伪规则（与 WAF 无关）：如果请求查询字符串匹配以下任意项：

• (\.\./|\.\.\\|%2e%2e%2f|%2e%2e%5c) 或者
• 18. (php://|data://|expect://) 或者
• 19. (wp-config\.php|/etc/passwd|\.env)

20. 则阻止请求（HTTP 403）并记录详细信息。将规则范围限制在可能的端点以减少误报。.

如果您的网站已被攻陷 — 事件响应检查清单

1. 将网站下线（维护模式）或隔离主机。.
2. 对网站和日志进行完整快照以进行取证分析。.
3. 更改所有密码：管理员用户、数据库、FTP/SFTP、控制面板。.
4. 轮换可能已存储在服务器上的API密钥和令牌。.
5. 扫描并删除恶意文件和Webshell；如果不确定，请从干净的备份中恢复。.
6. 验证数据库完整性并删除未经授权的管理员用户或注入内容。.
7. 进行全面审计以确定攻击路径和任何横向移动。.
8. 如有必要，从已知良好的来源重建环境；如果后门可能存在，请不要仅依赖“清理”。.

开发者和系统管理员技术说明

这种类型的漏洞通常源于不安全地将用户输入连接到文件系统路径。遵循以下安全实践：

• 在未列出允许值的情况下，切勿使用原始用户输入构建文件名。.
• 使用映射：将短键映射到允许的文件名，而不是接受完整路径。.
• 在传递给include/require之前，规范化和验证任何路径。.
• 如果用户内容决定模板选择，请将选择限制为您代码库中存在的受信任集合。.

示例安全模式（伪代码）：

$allowed_templates = ['home', 'archive', 'single'];

实用服务器代码片段（摘要）

在部署到生产环境之前，请在暂存主机上测试这些：

保护 wp-config.php （Apache .htaccess）：

<files wp-config.php>
  order allow,deny
  deny from all
</files>

Nginx 规则以阻止 php 包装器尝试（概念性）：

if ($query_string ~* "php://|data://|%2e%2e|(\.\./)") {
  return 403;
}

PHP ini 加固（示例）：

allow_url_fopen = 关闭

最终行动 — 在接下来的 24–72 小时内该做什么

1. 清单：识别所有运行 Welldone 主题 ≤ 2.4 的网站。.
2. 至少采取一种立即缓解措施：
   • 禁用或重命名主题文件夹，或
   • 在服务器级别阻止利用模式，并
   • 限制 wp-config.php 访问。.
3. 启用持续扫描和监控上述指标。.
4. 如果您托管客户，请及时通知利益相关者并在受影响的租户中应用缓解措施。.

需要专业帮助吗？

如果您管理多个 WordPress 安装或缺乏内部事件响应能力，请联系信誉良好的事件响应提供商或您的托管提供商的安全团队。在任何可能破坏证据的激进清理之前，优先考虑遏制、日志捕获和取证。.