你用的 CDN 可能正在埋雷：一次域名劫持带来的警示

做网站的人都懂，代码分两种：自己写的和别人写的。自己写的，大家都很上心；别人写的，往往就睁一只眼闭一只眼了。最近发生的一件事，生动地说明了这种心态有多危险。

一个被遗弃的域名引发的血案

事情是这样的：有一家 CDN 服务商，支撑了成千上万个 WordPress 网站十多年，后来公司被收购，业务慢慢关停，最后域名都懒得续费了。结果这个域名被人重新注册走了，这下子，所有曾经指向这家 CDN 的子域名，全落入了别人手里。

这事儿可不是我瞎编的。netdna-ssl.com 就是活生生的例子。这是 MaxCDN 的资产域名，WP Engine 的很多用户都在用它托管静态文件。MaxCDN 被 StackPath 收购后慢慢关停了，域名就这么过期了。2025 年 7 月，有人把它注册回去了。

新主人立刻拿到了 *.wpengine.netdna-ssl.com 这个命名空间下的所有 DNS 控制权。你网站还在引用的那些带哈希值的子域名？不好意思，现在全在别人服务器上——一个运行 Instagram 下载器、挂着 Google AdSense 的陌生人手里。

别觉得这事跟你没关系

你可能会说："这都老黄历了，谁还用这个啊。"问题是，你的感觉往往不靠谱。

researchers 调查发现，光 GitHub 上就有大约 4000 个文件还在引用这些过期的域名。而且不是什么被废弃的仓库——Mozilla 的 webxr-polyfill 项目、还有 Kong、Nextcloud、耶鲁每日新闻等机构的网站，至今还在从这些废弃节点加载资源。

更让人心里没底的是：Cloudflare Radar 数据显示，netdna-ssl.com 排在全球域名流量的前两万名。这意味着现在还有大量真实用户在访问这个域名。这不是什么考古发现，是正在发生的现实。

一把上了膛的枪

这事儿最可怕的地方在于：目前这些旧的资源链接其实打不开。新主人虽然接入了 Cloudflare，但 SSL 证书只覆盖了主域名和一些代理子域名，并不包含那些老旧资产域名的泛解析。所以当浏览器尝试从类似 xyz123.wpengine.netdna-ssl.com 这样的地址加载脚本或字体时，TLS 握手直接失败。

短期内，这反而保护了用户——浏览器直接把内容拦掉了，不会执行。但你仔细想想：攻击者已经掌握了全部 DNS 控制权，已经架好了流量变现的基建，服务器都开着了。就差在 Cloudflare 高级证书管理器里点一下开关，就能让一切变成灾难。

安全圈管这叫"上了膛的枪"——漏洞目前没法利用，但攻击者只要动动手指头，随时能扣扳机。

历史不会重复，但会押韵

如果你觉得这情节眼熟，那是因为 2024 年 6 月我们刚看过一模一样的剧本——polyfill.io 事件。当时整个互联网都信任这个域名，结果域名易主后，十多万个网站突然发现自己正在给用户推送来路不明的代码。问题出在哪？我们把"这个域名一直以来都挺安全"当成了"这个域名以后也会一直安全"，但这两件事根本不是一回事。

说白了，我们的安全靠的是域名而不是代码本身。域名换了主人，所有信任它的网站都得跟着承担新主人的一切行为。

现在该做什么

马上检查你的依赖。 搜一搜代码库、数据库、文档里有没有还在引用废弃 CDN 域名的。别以为服务关停了，域名就安全了。

把关键资源拿回来自己托管。 如果字体、脚本、CSS 是核心功能，干脆自己搭服务。多花那点服务器钱，比起让用户浏览器从不可信的源头拉代码，风险小多了。

用上 SRI。 不得不依赖第三方资源的时候，给你的 <script> 和 <link> 标签加上加密哈希。SRI 能保证就算域名被劫持，攻击者也没法篡改代码——一改就露馅。

盯紧你的供应链。 Report URI 之类的服务可以监控 CSP 报告，发现异常域名立刻报警。把这些告警配好，有人打扰的时候认真对待。

说到底

这件事暴露了现代 Web 开发的一个根本矛盾：我们建立在信任之上，却很少回过头去检验这份信任。一个去年还安全可靠的依赖，明年可能就变成恶意代码的入口——只因为域名换了主人。

聊域名安全，大家容易想到 DNSSEC、SSL 证书、注册商锁定这些。但这件事提醒我们：真正的安全挑战不只是保护自己的域名，更是要慎重选择信任哪些域名，而且要有一套机制，能察觉到信任被错付了的那一刻。

互联网靠信任运转。你的信任，放在哪儿了吗？