同行 CMS 的入口文件被换成篡改脚本，公开问题单里能读出什么

同行内容系统的入口文件被替换成篡改脚本，公开问题单里能读出哪些线索？这份问题单（PbootCMS 的 issue #50，标题写的是「最新版本漏洞还在，新的脚本篡改病毒」）可核对的字段有三条时间线与两处文件名：2026 年 6 月 23 日 core/start.php 被篡改，6 月 24 日首页 index.php 被篡改，问题单创建于 6 月 25 日、7 月 8 日关闭。被写入的脚本不直接输出固定内容，而是先读访客标识与来源引用，判断这次访问是否来自搜索引擎，再取回外部地址的内容输出。对内容站来说，这就是典型的「只对爬虫展示」的篡改形态。

问题单里能读到的三条时间点

两条篡改日期相连，是这份问题单最有价值的信息：它说明写入动作不是一次性的，攻击者拿到了可持续改写文件的能力。排查如果只清理首页，第二天仍会重新出现。

篡改脚本为什么要判断访客身份

问题单里被写入的脚本读取访客标识与来源引用，用搜索引擎名称相关的关键词以及爬虫名称的正则模式来判断访问来源。目的很直接：让站长与正常访客看不到异常，只在爬虫访问时返回构造内容。

这带来两个排查上的后果。一是用浏览器打开首页往往显示正常，判断是否被篡改要换用与爬虫一致的访问方式；二是搜索引擎收录里出现的标题与描述可能与站内任何一份正文都不对应——这类「站里没有、外部却有」的差异，本身就是最直接的信号。

至于外部取回内容的具体地址与代码细节，问题单里已经写明，本文不复述混淆片段，也不引用外部域名。跟进时只需要接受一个结论：入口文件不是自己写的那份。

核对文件完整性的先后顺序

顺序按「被写入的可能性」排，不按目录层级排。

第 1 步的比对基准来自发布包，而不是当前目录本身：当前目录里的文件已经被改过，拿它作基准永远一致。第 3 步是很多站点漏掉的一处——上传目录允许写入又要能被解析，是二次写入的常见落点。

部署方式决定恢复速度

同类事件里，恢复速度的差别通常不在技术上，而在有没有可退回的整份副本。

AnQiCMS 的备份与恢复支持数据与静态文件的备份和恢复，回退时把数据库与静态产物一并退回，避免模板退回、数据没退回造成的不一致。文档删除是移入回收站而不是物理删除，正文层面的误删与篡改可以先从回收站恢复，不必依赖备份整包。

部署方式在这里也起作用。AnQiCMS 支持宝塔面板一键部署、aaPanel、LNMP 命令部署与 Docker 镜像，默认监听 8001 端口。容器化部署时可以把整个运行环境退回上一镜像再重建，恢复面比只替换文件更完整；面板或命令部署时，比对与替换文件是主要手段，前提是有发布包原件可作基准。

改完之后还要验的几件事

清理与改密只完成一半，剩下的验证决定问题是否真的收住。

第一件是换一种访问方式复查：用与爬虫一致的访问方式抓取首页与几个内页，确认返回内容与站内正文一致。第二件是核对公开可见的结果，看收录里是否还残留异常标题。第三件是复核内容层，AnQiCMS 的内容安全设置提供敏感词过滤与关键词替换，并配套内容审核，这层检查能在篡改内容重新写入时把异常拦在对外发布之前。第四件是复盘写入路径——账号、版本、目录权限三项都要有结论，否则只清理文件等于等待下一轮。

常见问题

问题单里没写攻击来源，要不要自己推测？

不要。问题单只写明被改的文件与脚本行为，没有给出入侵路径。排查应当从账号、版本与文件权限三条可核对的线上找证据，推测来源会让处置动作失焦。

只恢复首页文件够吗？

不够。这份记录里两次篡改分别在入口启动文件与首页文件，两者相差一天。只清理被看到的那一个，另一个会在下次访问时重新产生异常。

怎么确认站点当前没有被写入类似逻辑？

用爬虫一致的访问方式抓首页与主要内页，与站内正文比对；同时把入口与启动文件同发布包原件比对。两者都一致，才能认为公开可见内容与站内内容相符。

恢复之后要不要改凭据？

要。文件被改写说明已存在写入能力，处置至少包括管理员口令更换与凭据轮换，再复核登录记录。只回滚文件、不改凭据的站点，下一轮清理还会重来。