Tailscale 确认，SQLite 的预写日志 (Write-Ahead Logging, WAL) 机制中存在一个长达 16 年的缺陷，该缺陷可能会导致数据库发生静默损坏。公司已与 SQLite 的维护者合作，在 3.46.1 版本中发布了修复程序。这一发现至关重要，因为许多现代服务仍在使用 WAL 模式运行 SQLite，而未被察觉的损坏可能会抹除配置数据并导致网络节点失效。

该漏洞是如何被漏掉的

该漏洞自 2010 年以来一直存在于 WAL 机制中。高并发访问模式与某些文件系统行为之间的一种罕见交互触发了静默数据损坏，而标准的健康检查未能发现它。

Tailscale 的工程师首先发现少数节点在没有任何明显错误消息的情况下丢失了存储的状态。询问“数据库是否在线？”的探测程序持续返回成功，但配置条目却消失了。重现该问题需要使用自定义工具来对 WAL 路径施加压力并调整文件系统时序，这也是该问题隐藏十多年之久的原因。

谁需要担心

  • 任何启用了 WAL 模式运行 SQLite 的应用程序，尤其是在有多个进程或线程进行并发写入时。
  • 在非标准或网络文件系统上的部署，因为延迟和缓存会放大时序上的极端情况。
  • 将看起来健康的 SQLite 文件视为数据完整性保证的基础设施服务。

缓解步骤

  1. 升级 SQLite – 升级到 3.46.1 或更高版本；WAL 漏洞已在该版本中修复。
  2. 运行完整性检查 – 定期执行 PRAGMA integrity_check; 或速度更快的 PRAGMA quick_check; 以验证数据库的内部结构。
  3. 审计 WAL 使用情况 – 扫描代码库中的 journal_mode=WAL 设置，并决定并发级别是否合理。
  4. 加强监控 – 添加检查项，通过比较预期的数据模式或行数，而不仅仅是确认数据库是否可达。
  5. 持续备份 – 使用 Litestream 等工具实时复制 SQLite 的更改，为可能发生的损坏提供安全保障。

此事件带来的启示

  • 遗留漏洞可能在新负载下浮现 – 随着服务的扩展，曾经罕见的模式变得普遍，从而暴露了旧的缺陷。
  • 静默损坏比崩溃更危险 – 崩溃会强制重启并通常会触发警报；而静默数据丢失可能在数周内都未被察觉。
  • 公开的事后分析有助于生态系统 – Tailscale 详细的报告为其他团队提供了快速审计自身部署所需的信息。

后续关注

Tailscale 与 SQLite 团队合作，确保在分享消息之前修复程序已经准备就绪。

核心结论： 一个潜伏了 16 年未被察觉的漏洞之所以重新浮现，是因为现代工作负载以其最初开发者从未想象过的方式推动着 SQLite。更新库、运行完整性检查以及提高可观测性，是防御此类隐藏故障最快的方法。