供应链劫持攻击，为啥代码没改也会中招？

代码一行没改，服务器也没动，网站却开始给访客跳一些莫名其妙的请求——这种事现在不算新鲜。多数人的第一反应是「被黑了」，然后一头扎进自己的代码里翻，翻到半夜也找不到入口。问题常常压根不在你写的代码里，而在你信任的那一层：装过的包、引的外链 JS、拉镜像的地址、打包发布那条流水线。供应链劫持攻击为啥代码没改也会中招，答案就在这——攻击者绕过了你本人，去改了你上游的东西。

供应链劫持攻击为啥代码没改也会中招，根子在信任链

把站点想成一根绳子，你只是其中一节。上游有包管理器的公共仓库、有 CDN 节点、有主题和插件作者、有构建工具、有域名解析商，还有你从别人那抄来的一键安装脚本。这条链上任何一环被人动了手脚，下游所有用它的人一起中招，而且你这边什么都看不出来。攻击者算得很清楚：攻一个中小网站收益有限，攻一个被几万个项目依赖的包，等于一次性撬开几万扇门。这也是为什么这类攻击听着玄乎，实际发生频率一点不低。

被换掉的常常不是你的代码，是上游那个包

最典型的是包仓库里的投毒。早些年 npm 上有个叫 event-stream 的包，作者不维护了把项目转手，接手的人在依赖里塞了针对特定钱包的恶意代码，公开报道里说过这事；后来 ua-parser-js 这类常用包也出现过维护者账号被盗、发布带毒版本的情况。共同点是：用这些包的人，自己的代码一个字没改，重新构建一次就带上了。原因往往出在版本号写法上——package.json 里写 ^1.2.3，每次装依赖都可能拉到新的小版本，作者一换人，你就跟着换。lock 文件不提交到仓库，等于每次部署都在抽奖。

前端更容易出事，一段外链 JS 就能带进来

后端依赖好歹还有个清单能查，前端就更松。统计代码、客服挂件、广告位、图床、字体库，还有从公共 CDN 引的 jquery.min.js、vue.js，这些东西你根本没源码，浏览器拿到什么就执行什么。对方服务器上那个文件被换掉，你的页面立刻变成投递通道，用户看到的还是你的域名、你的证书，一点异常都没有。能加 integrity 属性（SRI）的就加上，浏览器会先核对哈希，对不上就不执行；再配合 CSP 把允许加载脚本的域名收紧。麻烦是麻烦，但比出事之后再排查省事得多。

几起公开案例，够说明问题

SolarWinds 那次，公开报道的口径是官方发布的更新包被植入后门，大量下游机构在正常升级时中招；Codecov 的 bash 上传脚本被改过，也是公开披露的事件；2024 年 xz-utils 里被发现后门，编号 CVE-2024-3094，同样有公开的技术分析。这些案子有个共同特征：受害方都是按正常流程操作，装的是「官方版本」。具体时间线和影响范围以厂商公告和公开报道为准，这里不复述数字，只提醒一句——信源本身也可能是被攻击的那一环。

先查这几处，比上来就全盘杀毒管用

真怀疑中招了，别急着格式化。先看几处关键位置：网站目录里最近被动过的文件，find /www/wwwroot -mtime -7 -type f 跑一遍，正常运营的站不该有大量陌生文件冒出来；定时任务 crontab -l，还有 /etc/cron.d 下面，很多后门就挂在这；对外连接用 ss -antp 看有没有连向陌生 IP 的进程；nginx 配置里搜 proxy_pass 和 rewrite，看有没有被人塞进去的转发规则；后台账号列表里多出来的管理员；域名解析记录有没有被改。这一圈走下来，比装三个杀毒软件有用。

锁版本这一步，能挡掉一多半

防御没那么多花活，把版本锁死就是最实在的一条。lock 文件必须提交进仓库，部署时用安装锁定版本的命令，别用会自动升级的写法。依赖源尽量走官方或者自己搭的私有源，公共镜像省事，但同步延迟和被替换的风险得自己评估。npm audit、composer audit 这类工具在 CI 里跑一遍，有已知漏洞就卡住不让发。还有一条很多人不当回事：curl 一串地址 | bash 这种一键脚本，等于把服务器交给一个你看不见内容的东西，能不用就别用，镜像和面板一律从官方渠道拿。

建站和上云的人，几个笨办法最管用

插件和主题别贪多，装十个有八个用不上，还都是别人写的代码；破解版主题直接别碰，省下的那点钱不够善后。云主机镜像选官方提供的，一键部署脚本先看一眼内容再跑。备份要有，而且得是能回滚的那种，出事之后最快的止损不是查清楚，是先把干净版本顶上去。后台账号按最小权限给，别所有操作都用管理员。最后，官方安全公告该看还得看，很多漏洞在爆出来之前，补丁其实已经放出来一段时间了。

回到开头那句：代码没改也会中招，不是玄学，是你看不见的那半条链在动。今天花十分钟把 lock 文件提交上、把外链脚本收一收、把定时任务看一眼，比出事之后熬三个通宵划算得多。