1. 2025 年 12 月开始出现异常请求#

服务器 的 OpenResty 日志从 2025 年 12 月起，持续出现针对 Umami 根路径的异常 POST。日志里能看到 Server Action 探测和异常请求格式，例如：

1
React2ShellScanner/1.0.0
2
Failed to find Server Action
3
Invalid Server Actions request

这些日志本身不能证明某一次请求就是唯一的入侵请求，因为当时没有保存完整请求体。但它们与当时运行的 Next.js 版本、后续落地文件和攻击时间线能够互相印证。

2. 2026 年 7 月重建后，攻击很快再次出现#

Umami 容器在 2026 年 7 月 13 日重建后，大约几个小时内又收到了同类型的探测请求。这说明“重建容器”只能清掉当时的可写层，不能替代版本修复、入口收敛和凭据轮换。

3. 2026 年 8 月 8 日，Safe Browsing 明确标记#

8 月 8 日检查 blog.910501.xyz 时，Google Safe Browsing 仍显示“此网站不安全”。博客本身使用 Vercel，Umami 使用 Cloudflare/OpenResty 代理，这也是为什么一开始很容易把问题错误归因到 CDN 或 DNS。

真正的关联关系是：

1
Umami 容器被写入未授权代码
2
        ↓
3
umami.910501.xyz/script.js 被污染或被用于投放内容
4
        ↓
5
博客所有页面加载 Umami 脚本
6
        ↓
7
Google 将 Umami 风险关联到博客页面
8
        ↓
9
Chrome 对博客显示危险网站警告

已确认的影响#

1. Umami 容器被写入非官方文件。
2. Umami 的公网脚本和根域名被 Google Safe Browsing 标记。
3. 博客页面因为加载 Umami 脚本而受到关联影响。
4. Umami 的 APP_SECRET、数据库连接凭据和管理员会话必须按已泄露处理。

暂未发现的影响#

后续横向检查中暂未发现：

• n0de 或同组 IOC 在运行；
• 到恶意 IP 的活动外联；
• 宿主机上出现同名文件或未知系统服务；
• 其他容器出现同组 IOC；
• Umami 使用宿主机挂载、Docker socket、额外 capability 或 privileged 模式；
• 已有证据证明攻击者逃逸到 服务器 宿主机。

不过，“没有发现”不等于“绝对没有发生”。因此处置时没有把数据库、共享 Docker 网络和凭据当作安全的，而是按最小权限和凭据可能泄露重新处理。

第一步：先保全证据，再停止服务#

停止容器之前，保存了：

• docker inspect、docker diff、docker top；
• 容器日志和镜像 digest；
• OpenResty access/error 日志和 Umami vhost；
• 容器网络、挂载、能力和进程信息；
• 污染容器的导出归档及 SHA256；
• MySQL 数据库备份和可恢复性检查；
• 当时的 DNS、博客 HTML、脚本列表和 Safe Browsing 检查结果。

证据目录使用 root-only 权限保存，禁止把数据库备份、环境变量、容器导出或 IOC 样本上传 GitHub、网盘或公开文章附件。

第二步：先切断公网应用入口#

证据保全后，umami.910501.xyz 由 OpenResty 返回静态 410 Gone，只保留 ACME Challenge 路径。这样做的目的不是“伪装服务正常”，而是确保浏览器、爬虫和博客都不能继续进入污染容器。

然后才停止 Umami、关闭自动重启、断开共享 Docker 网络，并保留污染容器供后续核查，而不是立刻删除。

第三步：轮换凭据#

以下内容按已泄露处理：

• Umami APP_SECRET；
• Umami 专用 MySQL 用户密码；
• Umami 管理员会话；
• 依赖 Umami 或共享服务的内部连接凭据。

普通用户 API Key 没有无理由批量轮换，避免把一次安全事件扩大成业务中断；只有发现异常使用的 Key，才单独吊销。

第四步：移除博客上的危险依赖#

博客方面做了几件非常保守的事情：

• 清空 Umami websiteId 和 scriptUrl；
• 永久不再恢复这次被污染的 Umami 容器和可写层；
• 暂时关闭 Waline 评论和 Guestbook；
• 暂时移除第三方网盘、邀请码、短链和安装包；
• 保留文章主体，但移除无法核验的下载执行链；
• 保留 Vercel Insights 和 Speed Insights；
• 通过本地构建和公网页面扫描确认不再请求 Umami、Waline 或恶意 IOC。

这里的原则是：恢复文章内容，不等于恢复所有外链；保留教程，不等于替读者背书未知下载源。

Cloudflare 橙云不能修复被入侵的源站#

橙云可以改善 DNS 隐藏、WAF、缓存和 DDoS 防护，但它不能：

• 删除容器里的恶意文件；
• 修补 Next.js 远程代码执行漏洞；
• 轮换数据库密码和应用 Secret；
• 判断页面是否存在 SEO Cloaking；
• 修复源站服务停止导致的 502。

因此后续恢复使用了 Cloudflare CIDR 源站隔离、Authenticated Origin Pulls / Origin CA 和 Full (strict) 的组合，但这些只是在清理之后减少绕过和伪造源站访问，不是替代补丁。

Safe Browsing 不是“测一下首页 200”#

Safe Browsing 关注的是完整 URL、跳转、脚本、iframe、下载、表单和第三方资源。一个首页返回 200 的站点，仍然可能因为隐藏脚本或某篇文章中的下载链被标记。

这次复核至少检查了：

• 根页面、文章页和 robots.txt；
• 外部脚本、iframe、重定向和表单；
• Umami/Waline/网盘/邀请码残留；
• 页面是否产生登录、密码输入或文件下载行为；
• 中国大陆运营商、手机流量和海外网络的访问差异；
• Google Safe Browsing 和 Search Console 的状态变化。

提交复审前，必须先保证污染容器停止、博客不再引用危险资源、Google 能抓到干净部署；不能一边继续加载 Umami，一边提交“已经清理”的复审说明。

镜像与版本#

• 禁止使用不确定的 latest；
• 记录镜像 digest；
• 对框架和运行时依赖做漏洞扫描；
• 公开暴露的 Next.js、Nuxt、WordPress 等服务及时升级；
• 升级后重新检查 Server Action、Middleware、调试和安装入口。

容器与主机#

• 应用使用非 root 用户；
• cap_drop: ALL，启用 no-new-privileges；
• 不给统计、博客、后台服务挂载 Docker socket；
• 不让无关服务共享同一个 Docker 网络；
• 定期检查 docker diff、/tmp、/var/tmp 和启动脚本；
• 监控容器异常外联、PID、CPU、OOM 和 RestartCount。

反向代理与源站#

• 源站服务只绑定 loopback 或私网；
• 80/443 只接受 Cloudflare 官方 CIDR；
• 非业务路径明确拒绝 /setup、/debug、/metrics、.env、.git 和备份文件；
• 动态 API 不缓存、不返回登录 HTML 代替 JSON 错误；
• SSE 和 WebSocket 单独验证，不让代理缓冲破坏业务。

账号与数据#

• 安全事件后优先轮换 Secret，而不是先重启服务；
• 管理员会话和 Refresh Token 要能按用户撤销；
• 只给数据库用户最小权限；
• 备份要能恢复，并且与生产配置分开保存；
• 证据和备份不得进入 Git、网盘或公开工单。