IPFS 看似与传统漏洞数据库无关，但近年来确实出现过多起影响范围不小的安全事件。本篇整理几个有代表性的案例，并提炼对自建节点团队的启示。
DHT 投毒与节点劫持
DHT 投毒是 IPFS 协议层最经典的攻击方式。攻击者向 DHT 注入大量伪造记录，让目标 CID 指向无关或恶意内容。这种攻击不会破坏数据本身，但会让用户拉取到错误数据，进而误导链上业务。
防御思路是「客户端验证」：拉取到内容后立即用本地哈希校验。同时建议节点开启可信 peers 白名单，对照 BNB链最佳实践 中的 peer 管理策略做加固，可以让风险显著降低。
Pinning Service 凭据泄漏
2023 至 2024 年陆续有团队因为 Pinning Service API Key 泄漏导致内容被替换或删除。原因多半是 Key 直接写在前端代码里、或者贴到了 GitHub 公开仓库。处置上，需要立即吊销 Key 并替换所有 CID 哈希。
配合 Solana程序安全审计 中的 secret 管理建议，把所有 Key 都收口到密钥管理系统（HashiCorp Vault、AWS KMS），并启用日志审计。如果团队同时使用中心化交易所如 Binance 或 币安 的 API Key，可以采用相同的策略统一管理。
Gateway 路径穿越与 SSRF
部分自建 Gateway 在解析 path 时未做严格校验，导致攻击者可以通过特定 CID 触发 SSRF（服务端请求伪造），进而访问内网服务。社区在 2024 年公布过 CVE，建议所有团队检查自家 Gateway 版本与配置。
整改思路包括：升级到最新版本、用 WAF 拦截可疑请求、在 Gateway 与内网之间增加 ACL。这类问题通常只要做版本跟进与配置审计就能避免。
节点 OOM 与拒绝服务
IPFS 节点对大文件、大 DAG 的处理能力有上限，攻击者可以构造特殊 DAG 触发 OOM。运维上需要在 Kubo 配置里设置合理的内存上限，配合 cgroup 隔离与监控告警。
可参考 Geth常见错误 中提到的内存优化思路，把 IPFS 与节点 EVM 同台部署的场景做资源隔离。
应急响应与公开沟通
一旦事件发生，团队需要在最短时间内做： 第一，断网取证； 第二，吊销凭据； 第三，对外公告。 公开沟通时要诚实、具体、给出整改时间线。这类做法对项目声誉的修复至关重要。
参考 BNB链最佳实践 中关于事件公关的流程，可以让公告更专业、更易获得社区谅解。
总结：把漏洞当作系统化课题
漏洞不是「会不会发生」而是「什么时候发生」。把每一个公开案例当作团队学习材料，把 IPFS 安全审计纳入季度计划，是把去中心化存储维持在长期稳定状态的关键。坚持几年，团队的安全实力会形成实质护城河。