昨天在 UTC 时间 14:05 至 15:22 之间——也就是 77 分钟 的窗口内——针对 PraisonAI 这款多智能体框架发布了 20 个 CVE。编号连续，从 CVE-2026-55522 到 CVE-2026-55541。共有 13 名独立报告者署名。最高严重性评分为 9.1。

它们都指向同一个提交

从全部 20 份通告中提取参考列表并去重后，结果恰好只有一个修复提交，而且每一条记录都引用了它。该提交被描述为一次输入验证加固修改，于 2026 年 6 月 13 日合并，并在当天发布。因此，披露时间距离代码修复已经晚了 73 天。我们对两个版本中的受影响服务器文件进行了 diff 比对，以确认这项变更真实存在，而非只是表面调整。

常见表述忽略了什么

20 个 CVE 不等于 20 个漏洞。 一次修复输入验证失败类问题的加固提交，被 13 名在同一代码库上工作的报告者拆分成了 20 条分别编号的记录。最典型的例子是：其中 3 条描述的是同一个漏洞——API key 参数被忽略——却分别给出了 8.6、7.3 和 完全没有 CVSS 评分。同一缺陷，三个编号，三种不同的严重性处理。除此之外，还有一份通告对受影响范围的文字描述，比其机器可读范围晚了 9 个版本，前后自相矛盾。

为何这会扭曲记录

CVE 数量常被用作依赖风险的替代指标——采购方会看，扫描工具会看，任何比较框架的人都会看。某个项目在一个下午内冒出 20 个编号，看上去像灾难性事件，但实质上只是 6 月份的一次修复。与此同时，重复评分会让自动化分诊变得混乱不堪：一项把 8.0 以上问题升级处理的策略，会命中这个漏洞的一个副本，忽略第二个，而第三个根本看不到。

真正严重的部分

任何自 6 月初以来一直没有更新的人，实际上已经在运行已知存在漏洞的代码长达两个半月，却没有任何公开记录提醒他们——因为修复是作为一次常规的加固提交发布的，而这些通告又在 73 天后才出现。真正的风险在于这段时间差，而不是“20”这个数字。