★ FEATURED ARTICLE 上周一个朋友发来截图说他的 WooCommerce 站后台收到了一堆异常请求日志里面全是../、%2e%2e这样的路径穿越特征他问我是不是被扫描了。我一看时间点基本能对上——这轮扫描大概率就是冲着 CVE-2025-1661 这个 WooCommerce 本地文件包含漏洞来的。这个漏洞公告出来有一阵了但很多人其实没意识到它有多值得重视尤其是还在用旧版本、又堆了一堆插件的电商站。本地文件包含Local File InclusionLFI在 PHP 应用里不算新鲜但因为 WooCommerce 装得实在太广一旦出现这类漏洞影响面就不是“某个小插件的事情”了。攻击者不需要登录只要构造一个特殊请求就可能让服务器去加载并执行本不该被访问的本地文件轻则读到数据库账号密码重则结合其他条件直接控制整台服务器。这篇文章我把自己处理这类问题的思路、排查步骤和加固方法完整梳理一遍适合正在维护 WordPress WooCommerce 站点的开发者、站长也适合想系统理解 LFI 漏洞原理的安全初学者。1. 漏洞概览CVE-2025-1661 到底是什么影响有多广1.1 先理解本地文件包含漏洞LFI是个什么概念要理解 CVE-2025-1661绕不开 LFI 这个基础概念。PHP 里有几个常用的文件操作函数include、include_once、require、require_once它们的作用就一个——把另一个文件的代码加载进来然后当作当前程序的一部分执行。这本身是PHP提供的正常能力模板引擎、语言包、配置加载都要靠它。问题出在哪出在“加载哪个文件”这个决定权被交给了用户。如果程序直接把 GET 参数、POST 参数、Cookie 里的值当成文件路径去 include而没有任何过滤攻击者就可以把这个参数改成一个特殊路径比如../../../../etc/passwd服务器就会真的去读取系统里的账号文件。这就好比你家小区的快递柜本来是一人一码对应一个柜子但物管系统有漏洞来的人随便输一串字符打开的是楼上邻居的柜子。电商站对这类漏洞尤其敏感。原因是 WooCommerce 站点承载的业务数据太敏感了——订单、用户手机号、地址、支付流水、后台数据库密码全在一个系统里。LFI 漏洞一旦能被利用最直接的后果就是“任意文件读取”wp-config.php是几乎所有攻击者的头号目标因为它里面躺着数据库主机、数据库名、用户名、密码。1.2 CVE-2025-1661 的触发场景与受影响版本CVE-2025-1661 属于 WooCommerce 插件中的本地文件包含漏洞核心问题出现在某些文件路径参数未经严格校验就被用于文件操作。从目前公开的信息和同类漏洞的分布规律来看这类触发点往往藏在订单导出、模板加载、报表下载、附件处理这类功能模块里——因为这些模块的业务逻辑天然需要“按名字或参数去取一个文件”。举个例子你就明白了一个导出订单 CSV 的功能后端代码可能是这样的逻辑接收一个type参数然后根据这个参数拼接出文件路径再通过 include 或文件读取函数输出内容。正常情况下type只允许是orders或refunds但如果代码只做了 if-else 分支没有对参数本身做一个“白名单校验”攻击者传入type../../../../tmp/shell之类的值后端就可能跟着拼出一个危险的路径并执行。受影响的版本方面官方公告给出的修复版本很明确凡是低于该修复版本的 WooCommerce 安装都应该视为潜在受影响。这个问题在开源插件里尤其容易被忽略因为 WooCommerce 的更新节奏很快很多站长习惯在后台看到红点就点升级但也有大量站点用的是定制化修改过的版本、汉化包、或者第三方集成的主题包根本收不到官方更新提示这部分站点的风险实际上比官方源安装的站点更高。1.3 影响范围判断谁最该重视这个漏洞先说结论凡是自建独立站、用了 WooCommerce 搭建商城、且直接暴露在公网上的站点都该重视。我再把优先级排一下使用了 WooCommerce 但长期不更新、处于“部署完就不管”状态的站点站点中安装了较多的第三方插件、主题特别是来源不明的免费主题服务器配置了较高的 PHP 执行权限没有做 disable_functions 限制没有 Web 应用防火墙WAF或访问日志分析被扫描了都不知道。很多人有一个误区觉得“我的站小流量少不会有人盯上”。真实情况恰恰相反攻击者从来不是人工挨个挑肥拣瘦而是用扫描器批量扫全网只要你的站暴露在公网IP 一被扫到就会自动进入攻击队列。你的站可能没有人为的“重点关注”但漏洞扫描器对特征极其敏感只要探测到请求响应符合特征立刻就会跟进尝试利用所以小站跟大站被攻击的概率在自动化扫描面前没有本质区别。2. 深入原理WooCommerce 为什么会出现本地文件包含问题2.1 文件包含漏洞产生的机制拆解从程序的角度看LFI 漏洞的产生需要同时满足三个条件第一程序里确实存在用include、require、file_get_contents等函数去加载文件的地方第二这个加载的文件路径里包含了外部可控的变量第三外部可控的变量没有被有效地过滤或约束。三个条件缺一个漏洞就不成立。第一个条件好理解每个 PHP 应用都离不开文件加载。第二个条件才是关键以 WooCommerce 这样的大型插件为例它的代码量非常大模块之间的调用关系错综复杂一个变量从 HTTP 请求进来经过几层函数调用、封装、过滤最后落到文件路径拼接处中途任何一层的验证不够严谨都可能把风险传递到最终的 include 调用。这也是为什么很多漏洞不是开发者故意留的而是代码复杂度太高导致的“漏网之鱼”。第三个条件——过滤不严——则是最常见的翻车点。很多开发者不是没有做防御而是做错了方向。典型做法是只过滤了../觉得把路径穿越符过滤掉就安全了。但攻击者的绕过思路非常多URL 编码后的%2e%2e%2f、UTF-8 变体编码、Windows 下的反斜杠路径甚至可以利用 PHP 内核函数对路径的解析差异来绕过滤。只做黑名单过滤等于在跟整个攻击生态对抗几乎必输。2.2 WooCommerce 里哪些功能模块容易被埋雷我处理过几起类似的问题也专门分析过 WooCommerce 的代码结构直接说几个容易出现文件包含问题的典型业务场景第一个是“模板加载”。WooCommerce 允许主题覆盖默认模板同时自身也有模板定位的逻辑。如果某个模板名参数可以由用户控制参与路径拼接就存在风险。这里的难点在于模板系统太灵活开发者为了支持自定义主题往往用变量去动态拼模板路径一个不小心就把用户输入带进去了。第二个是“导出下载”。订单导出、报表导出是电商站的高频场景。导出功能的实现通常是后端生成一个文件然后把文件路径传给前端或直接重定向到下载链接。如果这个文件路径由 GET 参数控制攻击者完全可以修改参数指向其他文件配合服务器配置直接拉取任意可读文件。第三个是“附件与媒体处理”。WordPress 本身对上传文件的处理已经比较成熟但 WooCommerce 里有很多附加的媒体逻辑比如产品图片的缩略、备份文件的创建。这些逻辑在处理文件名时如果使用用户可控的字段也可能把恶意路径带进文件系统函数。你知道为什么这类漏洞在电商插件里反复出现吗因为它本质上不是“某个字符串没过滤”的问题而是电商业务本身太需要动态文件操作了——导出、下载、模板展示、附件管理每一个都是合理的业务功能每一个都需要处理路径但每一个都容易漏掉验证。2.3 LFI 能造成多严重的后果LFI 最直接的能力是读取任意文件。对 WordPress 站点来说wp-config.php是最典型的敏感目标里面有数据库主机地址、数据库账号、数据库密码和认证密钥。拿到这些之后攻击者可以直连数据库篡改管理员账号、注入恶意脚本站点基本就完全脱手了。更进一步的场景是利用 LFI 实现远程代码执行RCE。常见路径有两条一条是利用php://filter等伪协议读取源码配合日志注入、session 文件注入或者临时文件上传把一个写有 PHP 代码的本地文件落到服务器上再通过 LFI 去包含它最终拿到代码执行能力另一条是结合文件上传漏洞直接把恶意文件上传到服务器某个目录再用 LFI 去 include 执行。这两条路径都有很多前置条件比如服务器运行用户对特定目录有写权限、目标目录没有禁止 PHP 执行等所以不是每个 LFI 都能直接升级成 RCE但风险边界是真实存在的。我不放完整的利用代码这不是本文的目的但你想理解这个漏洞的杀伤力只要知道一件事就够了LFI 是“权限边界突破”的跳板它本身是信息泄露跟其他漏洞组合就是代码执行。提示所有的排查和测试动作都应该在你自己拥有授权的环境中进行或者在你的 staging 环境中验证。对没有授权的网站进行任何形式的漏洞验证都是违法行为技术边界和法律边界一样重要。3. 排查与确认怎样判断你的站点是否受影响3.1 第一步永远是把版本信息摸清楚排查任何漏洞的第一步都是先确定你用的到底是哪个版本。以 WooCommerce 为例登录 WordPress 后台在“插件”页面找到 WooCommerce可以看到当前版本号。如果你用的是国外主题和插件商店购买的正版授权一般还会显示具体的版本分支。拿到版本号之后对照官方安全公告和主流漏洞库的信息。这几个途径都可以查WordPress 官方安全公告页面、WooCommerce 产品的官方更新日志、第三方漏洞数据库比如 WPScan 的漏洞库。查的时候注意两个细节第一公告里写的“受影响版本区间”是什么你的版本是否落在区间内第二公告里给出的“修复版本号”是多少你的版本是否低于修复版本。还有一种情况经常被忽略——你看到的版本号可能是被修改过的。有些第三方开发者为了隐藏修改痕迹会把插件包里的版本号改成固定值导致后台显示的是正常版本但实际代码已经被改过了。这种情况下单纯的版本对照就不够用了需要结合其他手段来确认。3.2 测试环境验证与风险确认方法如果你确定自己的版本落在受影响区间或者不确定但想进一步确认不要直接在线上生产环境做扫描和探测正确做法是搭建一个 staging 环境也就是复制一份线上环境的副本在副本上进行验证。这个环境要和线上保持一致的 PHP 版本、WordPress 版本、WooCommerce 版本和插件组合这样测出来的结果才有参考意义。在 staging 环境中可以选择使用专业的漏洞扫描工具来辅助确认。扫描工具的原理是通过发送无害的检测请求观察响应特征来判断漏洞是否存在。工具报告里如果提示存在 LFI 风险你再根据提示的 URL 和参数位置做人工核查确认是否真的存在用户可控的文件路径参数。我个人不建议对生产站点直接执行这类测试原因很简单一是触发漏洞本身可能对业务造成影响比如意外加载了一个大文件导致 PHP 内存耗尽二是即使没有实际利用漏洞扫描的行为特征也会被服务商的安全系统记录处理起来麻烦。3.3 日志审计最可靠的风险证据如果版本对照和工具扫描都难以确定日志审计是最可靠的手段。我处理漏洞事件时第一个去的地方永远是访问日志。不管是 Nginx 还是 Apache访问日志都会记录每一个进来的 HTTP 请求包括请求的 URL、参数、来源 IP、时间戳。针对 LFI 漏洞你应该重点检索这些特征URL 参数中带有../、..%2f、..%252f等路径穿越编码参数中带有php://filter、php://input等 PHP 伪协议前缀参数中带有常见敏感文件路径比如/etc/passwd、wp-config.php、.envURL 路径片段包含file、template、download、export、include等关键词。日志里如果出现这类请求说明你的站点已经被扫描器盯上了攻击者在尝试探测是否存在文件包含点。这时候要做的是继续往下排查这些请求是从什么 IP 发来的、是单次尝试还是反复测试、请求的目标路径是否是 WooCommerce 的已知功能入口。除了访问日志还要看 PHP 错误日志和 WordPress 的 debug.log。如果攻击者的请求触发了文件加载函数的报错这些日志会留下痕迹比如提示某个文件不存在或路径被拒绝的警告信息。这些信息能帮你还原攻击者的尝试路径判断漏洞是否真的被触达过。4. 修复与加固升级只是起点纵深防御才是终点4.1 官方补丁与版本升级的正确姿势CVE-2025-1661 的修复核心是升级 WooCommerce 到官方发布的修复版本。听起来很简单但实际执行时有很多细节值得注意。升级之前先做备份。备份的东西有两块数据库和 web 目录的全部文件。数据库用后台自带的导出或数据库管理工具导出一份文件这块至少要把wp-content目录完整打包一份因为主题、插件上传、自定义代码都集中在里面。备份的目的是为了万一升级后出现兼容性问题可以快速回滚。备份完成后建议先在 staging 环境执行升级确认没有兼容性问题之后再动线上。升级本身的操作就是后台的“更新”按钮但如果你用的是通过 FTP 或者命令行方式部署的环境需要手动下载新版本插件包并替换文件注意先停用插件再替换然后重新启用。升级完成后确认版本号已经变成修复版本然后清理缓存。WooCommerce 有自己的缓存目录WordPress 也可能装了缓存插件升级之后这些缓存都要清一遍否则可能继续加载旧代码给自己造成“明明升级了怎么还有问题”的假象。4.2 代码层面的主动加固升级只能解决已知漏洞代码层的主动加固才是长期安全的保障。这里分享几个我实际用过的策略。第一对文件路径做规范化校验。PHP 提供了一个函数叫realpath()它能把一个路径解析成真实的绝对路径。正确做法是拿到用户传入的路径参数后先通过realpath()规范化再检查解析后的路径是否在允许的目录前缀之下。比如允许的目录是/var/www/html/wp-content/themes/那就看解析后的路径是否以这个前缀开头不是就直接拒绝。这个方案能有效拦截所有形式的路径穿越因为无论你怎么编码绕过最终到达文件系统时都会变成真实的绝对路径。第二对所有包含文件内容的函数参数做白名单校验。比如模板加载不要直接 include 用户传来的字符串而是维护一个固定的模板名数组用户传什么就往数组里查查不到就用默认值。这是一个很朴素但极其有效的方案直接在业务逻辑层面把输入约束死了。第三检查服务器和 PHP 配置。PHP 配置里有一个allow_url_include的选项默认是关闭的务必确认它没有被打开否则攻击者可以直接用远程 URL 包含任意网站文件。另外disable_functions里可以考虑禁用一些高危函数比如shell_exec、exec、system、passthru、popen这些函数不是 WordPress 运行必需的禁用它们能显著缩小攻击者拿到代码执行能力之后的破坏范围。4.3 Web 应用层面的纵深防御代码加固是治内纵深防御是御外。对 WordPress 电商站我建议至少做四层防护。第一层是 Web 应用防火墙WAF。商业 WAF 或者开源方案都行核心是开启针对路径穿越和文件包含的规则。WAF 的价值在于即使应用还没升级或者代码里存在未知的文件包含问题攻击者的尝试请求也会在到达 PHP 之前被拦截。第二层是 Web 服务器层的目录控制。在 Nginx 或 Apache 配置中对关键目录做执行权限隔离比如wp-content/uploads/目录本身只应存放图片等静态资源文件头应该明确禁止该目录下执行 PHP 脚本。这样即使攻击者通过上传功能把恶意 PHP 文件传到了 uploads 目录也没法通过 Web 请求直接触发执行。第三层是文件系统权限收紧。wp-config.php的权限应该设置为 600 或 640确保只有运行 PHP 的用户能读web 目录里不需要写的文件一律只读。这条防线可以防止攻击者读取到敏感文件后继续横向操作。第四层是安全监控。安装一份安全审计插件比如 Wordfence、iThemes Security 等开启文件完整性监控功能。这类插件会定期扫描核心文件和主题插件文件发现被修改时立刻报警。对电商站来说人为介入的时间越早损失就越小。5. 常见问题与实操心得踩过一次坑之后的经验总结5.1 升级后站点白屏、插件异常怎么处理升级 WooCommerce 后最常见的两个问题白屏和插件冲突。白屏通常有两种原因一是 PHP 代码报错但错误显示被关闭了二是新版本与原主题或插件不兼容导致致命错误。遇到白屏先别慌打开 WordPress 的调试模式在wp-config.php中加上define(WP_DEBUG, true);和define(WP_DEBUG_DISPLAY, true);刷新页面具体报错信息就会显示出来。看到报错后判断是哪个文件导致的一般是主题目录里的某个函数调用签名不匹配或者某个插件使用了废弃函数。短期处理方式是停用冲突插件或更换主题长期是联系主题/插件作者提供兼容性修复。如果实在无法快速解决回滚是最安全的选择。用之前备份的插件文件和数据库恢复原样站点恢复正常后再分步排查。5.2 装了安全插件就能高枕无忧吗说实话安全插件的作用远没有大多数人想的那么大。安全插件能做的主要是三件事修改登录地址、限制登录尝试次数、周期性扫描文件是否被篡改。对 LFI 这类应用层漏洞安全插件本身不具备直接修复能力——它既不能帮你打补丁也不能替代代码审查。安全插件真正的价值在于“感知”它能让你第一时间知道站点出现了异常比如敏感文件被修改、有恶意请求触发告警。我遇到的情况是装了安全插件的站点往往在攻击者刚开始探测时就会收到报警给站长留出反应时间没装的站点往往等到搜索引擎提示“站点可能已被入侵”时才知道出了问题两三天时间足够攻击者把数据拖走了。所以我的建议是安全插件要装但把它当成监控工具来用不要当成万能盾牌。真正修复漏洞的永远是对代码的修缮和对版本的及时升级。5.3 扫描日志里发现了攻击尝试但没实际得手还需要处理吗需要处理而且要认真处理。攻击尝试本身就是一种信号说明你的站点已经被自动化扫描器探测到了。攻击者可能今天尝试了 LFI 没成功但如果你的站点存在其他漏洞或者之后新增了有漏洞的插件同一批攻击者很可能会回来继续尝试。处理流程分三步先根据日志特征判断攻击尝试是否触达过目标文件触达过就深入排查文件完整性和敏感信息泄露情况然后把攻击者的 IP 加入防火墙黑名单并在 WAF 上临时添加拦截规则最后复盘一下你的站点当前的整体安全状态做过版本升级、代码加固和权限收紧之后再恢复正常运营。尽量不要因为“没得手”就忽略这些日志。我见过不少被入侵的案例回看日志发现攻击者在两周前就开始尝试了但站长没当回事。漏洞被修复则已一旦后来暴露了一个可利用的入口之前积累的踩点信息就会立刻转化为攻击路径。5.4 关于漏洞处置我这些年最想说的几点心得处理了这么多 WordPress 漏洞事件我自己最深的体会是——安全问题本质上不是技术问题而是流程问题。一个站点只要做到“版本持续更新、备份持续有效、日志持续监控”绝大多数已知漏洞都能在窗口期内被修复根本轮不到攻击者利用。具体到这次 CVE-2025-1661 的处置我想提醒所有维护 WooCommerce 站点的朋友漏洞公告出来后的一周到两周是攻击最密集的窗口期因为扫描器会第一时间更新检测规则并批量扫描全网。在这个窗口期内优先做升级升级不了的先用代码加固和 WAF 规则补上至少让攻击请求打不进来。窗口期一过针对这个漏洞的攻击流量会有所回落但也不能放松因为扫描器是周期性轮询的随时可能再回来。另外一个很值得做的事是订阅漏洞情报源。WordPress 官方安全公告、WooCommerce 的更新日志、几个主流漏洞库的邮件订阅都可以设置提醒。与其等新闻爆出来再慌慌张张处理不如让安全信息每天定时到你手上把应急响应的节奏从“事后救火”变成“事前预防”。最后说一句可能不太中听但很实在的话如果你的站点托管在虚拟主机上、连备份都不知道在哪里设置、也不清楚自己用的 PHP 版本是多少那比起研究单个漏洞怎么修复你更迫切的任务是先补齐最基础的安全习惯——备份和更新这两件事做好了你已经跑赢相当一部分同类站点了。
阅读完成 · 觉得有帮助？
