内容摘要：2018年那场大规模挂马事件，让phpcms彻底从神坛跌落。攻击者利用的正是v9.6.0版本中的一处SQL注入，直接绕过了后台登录验证。那会儿国内半数中小型新闻网站都是它搭的，一夜之间，首页全被篡改成

2018年那场大规模挂马事件，漏洞让phpcms彻底从神坛跌落。漏洞攻击者利用的漏洞正是v9.6.0版本中的一处SQL注入，直接绕过了后台登录验证。漏洞那会儿国内半数中小型新闻网站都是漏洞它搭的，一夜之间，漏洞首页全被篡改成赌博广告。漏洞

这套系统的漏洞问题根子在于老架构。它的漏洞数据库操作层写得极其冗杂，参数过滤靠的漏洞是零散的正则函数，而不是漏洞统一的预处理机制。开发者在不同模块里各写各的漏洞过滤逻辑，有的漏洞地方过滤了单引号，有的漏洞地方却忘了过滤十六进制编码。攻击者只要找到一处漏网的漏洞参数，就能拼出恶意SQL语句。

最典型的案例在content/down.php文件里。这个文件处理附件下载请求时，直接取了$_GET['id']拼进查询语句，连基本的intval转换都没做。攻击者构造id=-1 UNION SELECT ...就能拖出管理员密码哈希。更讽刺的是，官方补丁只是加了个intval()函数，治标不治本——同一套代码逻辑在其他文件里原样躺着。

后来我翻过它的历史漏洞库，发现从2008年到2018年十年间，官方修了上百个漏洞，但修复方式几乎都是打补丁式堵漏，从不重构底层。这套系统的核心模块像积木一样层层堆叠，每加一个功能就多几张查询表，每张表都可能有独立的参数入口。你堵住这个入口，攻击者换个编码方式从另一个入口进来。

有个细节特别能说明问题。phpcms后台的模板解析功能允许管理员直接修改PHP代码，但权限验证只靠一个$_SESSION['userid']判断。一旦前台出现任意文件上传漏洞，攻击者就能上传一个包含恶意PHP的模板文件，然后通过访问触发解析。整个过程不需要提权，因为系统本身就把执行权限给了模板引擎。

这套系统最后彻底没落，不是因为没有维护者，而是维护者自己都理不清代码脉络。2019年官方最后一次更新后，社区彻底沉寂。现在你去GitHub搜phpcms相关仓库，大部分是安全研究员写的漏洞分析文档，而不是使用教程。这玩意儿成了活教材——它用十年时间证明了一个道理：CMS系统最致命的不是某个漏洞，而是整体架构缺乏安全设计时的连锁反应。

有意思的是，这些年我审计过不少基于phpcms二次开发的政企网站，发现开发者们习惯性地继续沿用老路子：把用户输入直接拼接进SQL，用正则过滤代替参数绑定。他们没意识到，phpcms的教训不是某个函数写得不好，而是整个开发范式已经过时。当框架本身不强制安全编码规范时，人的惰性就会让漏洞反复出现。