漏洞从被利用到进 KEV 的 42 天：公开信号先出现在哪

最早的公开信号不在 X 上，也不在任何按 CVE 编号的订阅里，而在项目自己的 GitHub 议题区：Nextcloud 内置 Collabora 文档服务（应用名 richdocumentscode）的被入侵报告，2026 年 9 月 11 日就贴出了访问日志，比 CVE 编号公开早 32.5 天，比美国 CISA 把它列入「已知被利用漏洞目录」（KEV）早 42.2 天。我们在 2026 年 10 月 26 日 10:17–10:56（新加坡时间）用 EveryInfra 发了 60 次请求、52 次计费，合计 $0.029576，又对照 NVD 变更历史、FIRST EPSS 时间序列和 24 个同期进 KEV 的漏洞，结论是：X 上按编号搜到的 106 条帖子里，CVE 公开前 0 条、进 KEV 后 80 条，按事先写好的规则逐条标注（一次标注，没有第二人复核）后，93.4% 是转述、机器人和推广；CVE 记录里的 SSVC 字段写着「未被利用」的状态持续了 9 天，EPSS 停在 1.2% 达 10 天。

本文说的「公开信号到处置的可审计流程」，是每天按自己用到的组件名（不只是 CVE 编号）去项目议题、厂商论坛和几个社交平台各取一次，原样存下返回和时间，跟资产清单比对，剔除噪音后决定升级、移除或排查，并把每一步「谁、何时、凭哪条证据、做了什么」记下来。它给运维和安全团队的是「先处理哪一个、凭什么」的依据，不是漏洞利用的预测，也不替代厂商通告。

不写什么

我们只写监测和处置，不写任何攻击方法、利用细节和请求构造。文中提到的入侵现象，只写到「管理员在哪里、什么时候、说了什么」这一层，便于读者核对时间，具体的请求内容一概不转述。个人账号名一律隐去，只写机构账号（如 CISA、CERT.LV、意大利 CSIRT、Censys）和项目维护者以项目身份发的内容。我们也不评价任何厂商的披露决定，只把公开记录里的时间并排放出来。

动手前写下的判据

我们在 10 月 26 日 10:16（新加坡时间）、第一次请求之前，把五条判据写进了检查记录；10:29 又在横截面请求的结果打开之前补了两条。下表把判据原文和结果放在一起，结果一栏的数字都在后文逐项给出来源。

第 2 条要说明一下边界：在 X 上，按编号和按「产品名加症状词」两种搜法，在 CVE 公开前都是 0 条相关，所以单看 X，这一条测不出差别；差别来自项目议题区和论坛，它们不是社交平台，但同样是公开的、可以按组件名订阅的地方。第 6 条我们写的是「形式上通过」，因为早 1 天和早 30 天对处置的意义完全不同，下文会把这个数拆开。

主案例：从第一行攻击日志到进 KEV

这个漏洞的编号是 CVE-2026-110447。按 Collabora 的安全通告，它只影响 Nextcloud 的可选应用「Collabora Online - Built-in CODE Server」，也就是在 Nextcloud 服务器上自带一份文档编辑服务的那种装法；独立部署的 Collabora Online 服务器不受影响（Nextcloud 论坛的提醒帖补充说，用 Docker 或发行版软件包装的也不受影响），修复版本是 26.4.303，并且「停用应用不够，必须升级或删除」。NVD 记录的描述写明，这个漏洞「在 2026 年 9 月和 10 月被在野利用」。

我们把公开记录里能落到秒的时间点全部取了一遍，用的是各家的原始接口而不是网页上的转述：GitHub 的议题接口给出议题和每条评论的 created_at，Nextcloud 论坛用的是 Discourse，帖子地址后面加 .json 就能拿到每楼的发帖时间（Discourse 接口文档），CVE 的保留和公开时间来自 CVE.org 记录背后的接口，NVD 每个字段何时变化来自 NVD 的 CVE 变更历史接口，KEV 的收录时间来自 CISA 的 KEV JSON 里的 dateReleased。下表是整理结果，时间为 UTC，括号里是新加坡时间。

这张表里最值得停一下的是两个「70 分钟」和一个「0.7 秒」。修复版 26.4.303 在 9 月 11 日 13:43 发布，70 分钟后，第一位受害的管理员开帖说「从昨天起，我们的系统正被成功入侵」。我们推测这两件事互相不知道：版本说明里没有安全字样，开帖人也是在议题里被问到才去升级的。另一个 70 分钟在 10 月 14 日：CVE.org 在 02:27 公开编号，69.8 分钟后 X 上才出现第一条带编号的帖子。至于 0.7 秒：CVE.org 接口里这条记录的 dateReserved 是 02:27:41.637，datePublished 是 02:27:42.315，也就是说，在这之前的 33 天里，这个漏洞连一个「已保留、未公开」的编号都没有。任何按编号工作的流程，在这 33 天里都没有东西可以匹配。

我们还发现一处二手资料与原始记录对不上。扫描机构 Censys 10 月 16 日的通告写的是「报告人的日志显示第一个恶意请求在 9 月 16 日」，但议题正文里两台服务器的日志行分别是 9 月 10 日 19:51 和 9 月 11 日 09:56（+0200 时区），议题本身也是 9 月 11 日开的，不可能引用 9 月 16 日的日志作为「第一次」。我们以 GitHub 接口返回的议题正文为准；这也说明，做时间线要回到原始帖子，转述里一个日期的错位，在 33 天的窗口里就是 6 天的偏差。同一份 Censys 通告给出的暴露面数字我们照录：当天探测到 19,454 台主机、103,350 个网站页面带有这个应用的特征，Censys 自己注明「并非都已确认存在漏洞」，而且这两个计数把 ARM64 版的同一应用（1,001 台）也算在里面。

为什么 33 天里没有 CVE

KEV 有三条硬门槛，CISA 在收录标准页里写得很清楚：已分配 CVE 编号、有可靠证据显示在野利用、有明确的修复动作。这个漏洞在 9 月 11 日就满足了后两条：议题里有三位管理员的被入侵报告，修复版也已经发布；卡住它的是第一条。KEV 在 CVE 公开后 9.7 天收录，单看这一段并不算慢；把它拉长到 42 天的，是编号本身的 32.5 天。

Collabora 自己在 10 月 14 日的博客里并列写了两件事：今年收到的 AI 辅助安全报告数量很大；「通过 GitHub 申请并公开一个 CVE 的时间，从大约一天变成了好几周」。博客没有直接说前者造成了后者，只说他们正在申请自己成为 CVE 编号机构（CNA）来缩短等待。CVE.org 的记录显示最终分配方是 MITRE，而且是保留和公开在同一秒完成，这和「走正常申请流程排队」的形态并不一样，更像是 MITRE 作为兜底分配方直接处理。我们没有看到 MITRE 或 GitHub 对这个个案的说明，所以这里只写记录形态，不推断原因。

这个案例并不特殊。安全公司 Second Security 10 月发布的研究 The Patchless Window 把 2026 年 1–8 月公开的 18,594 个开源 CVE 逐个追到修复它的第一个公开提交，算出「修复已公开、CVE 还没出来」这段时间的中位数：1 月 5.1 天，8 月 39.2 天。Collabora 这次从修复版发布到 CVE 公开是 32.5 天，比 8 月的中位数还短。换句话说，对开源组件，「先有修复、很久之后才有编号」正在变成常态；按编号订阅漏洞情报的团队，平均每个漏洞要比修复晚一个多月才收到第一条提醒。BleepingComputer 10 月 15 日的报道引用了这项研究，原文数字我们核对的是研究网站本身。

还有一层背景：NIST 从 2026 年 4 月 15 日起不再分析每一条 CVE，只优先补全进 KEV 的、联邦政府在用的和「关键软件」的 CVE，理由是 2020 到 2025 年提交量涨了 263%。我们 10 月 26 日从 NVD 接口读到的这条记录，vulnStatus 仍是 Deferred（暂缓补全），评分只有分配方给的 CVSS 4.0 和 CISA 的 SSVC，没有 NVD 自己的分析；而 NIST 的新规写的是「KEV 条目争取一个工作日内补全」，KEV 收录已过去 2 天多。对读者的含义是：NVD 上很多字段本来就可能是空的，指望 NVD 的评分把漏洞排到前面，在 KEV 之前和之后的一段时间里都会落空。

实测一：CVE 之前，社交平台上搜得到什么

如果当时有人在 X 上盯着这个组件，能不能更早看到？我们在 10 月 26 日 10:24–10:26（新加坡时间）用 X (Twitter) 关键词搜索爬虫 API（twitter/search）按三种思路各搜了一次，时间窗口都设成 9 月 1 日到 10 月 14 日：应用名 richdocumentscode；产品名加症状词 nextcloud (hacked OR webshell OR compromised OR backdoor)；只用产品名 nextcloud collabora。

结果很一致：前两种在 CVE 公开前 0 条，返回的 3 条和 5 条全是 10 月 14 日之后的；第三种在 CVE 公开前有 16 条，但我们逐条读完，16 条里没有 1 条提到漏洞、入侵或被黑，内容是瑞士联邦政府打算让 3,000 名员工改用开源办公套件、欧洲数字主权、主机商推广托管 Nextcloud 之类。这里还有一个顺手发现：三次请求都写了 until:2026-10-14，返回里却分别有 3、5、6 条是 10 月 14 日或之后的帖子，日期上限（X 高级搜索说明里写的是「某日期之前」）没有被严格执行，所以我们是按每条的 posted_at 重新筛的。

Reddit 这边，Reddit 关键词搜索爬虫 API（reddit/search）的时间范围固定为最近一个月，10 月 26 日搜，正好覆盖 9 月 26 日以后，也就是 CVE 公开前的 18 天。10:42 用 richdocumentscode 按最新排序搜到 14 条，全部和这个漏洞有关，但 CVE 公开前 0 条；第一条是 10 月 14 日 20:04 的安全资讯转发，比 CVE 晚 17.6 小时。真正有分量的是 10 月 22 日 r/NextCloud 一位管理员写的被入侵经过，标题直接点名内置 Collabora 应用，52 条评论，13 秒后同一作者又把它发到了 r/Malware。Hacker News 用官方的 Algolia 搜索接口查：richdocumentscode 0 条，nextcloud collabora 在 9 月 1 日以后第一条相关的是 10 月 15 日 22:06 的一条链接帖，2 分、0 评论。

我们把每个平台第一条相关内容相对 CVE 公开的时间排在一起：GitHub 议题早 32.5 天，Nextcloud 论坛早 10.7 天，X 晚 0.05 天，Reddit 晚 0.73 天，Hacker News 晚 1.8 天，YouTube 搜索（youtube/search，10 条全部提到编号）晚 2.5 天，LinkedIn 搜索（linkedin/search，10 条里 8 条提到编号）晚 4.0 天。微博用 微博关键词搜索爬虫 API（weibo/search）搜「Nextcloud 漏洞」，10 条里 9 条讲的是另一个漏洞 PHP2Shell，剩下 1 条是一份综合早报顺带提了一句 Collabora；Threads 搜索（threads/search）返回的 25 条全部集中在最近约 19 小时内，量不出首见。

这张表的含义可以一步一步推出来。第一，CVE 之前的全部公开信号都出现在「项目自己的地方」：代码仓库的议题区和厂商用户论坛。第二，这两个地方的作者是受影响的管理员和项目维护者，内容带日志和版本号，可核对；社交平台在这一段完全沉默。第三，社交平台的第一条内容几乎都是在 CVE 公开之后由安全资讯账号发出的，它们读的是 CVE 记录，不是议题区。所以，监测的重点应该是「按组件名订阅项目议题和论坛」，社交平台的作用是事后放大和补充受害者自述，不是早期预警。这个推论的边界是：本案的受害者是自托管的中小机构，他们习惯去项目议题区求助；如果受害者是大型企业，第一条信号更可能出现在厂商的付费支持渠道，那是公开数据看不到的。

实测二：CVE 公开以后，帖子量跟着 KEV 走

10:26（新加坡时间）我们按编号 CVE-2026-110447 在 X 上搜了一次，limit 200、按最新排序，返回 106 条，没有到上限。按发帖时间切成三段：CVE 公开前 0 条；CVE 公开到进 KEV 的 9.7 天里 26 条；进 KEV 之后的 2.3 天里 80 条，其中 10 月 24 日一天 49 条。进 KEV 后 48 小时内的帖子占全部的 71.7%。

这个形状说明了一件事：在 X 上，KEV 是放大器，不是被放大的信号。漏洞早在 9 月就被利用，CVE 描述 10 月 14 日就写明「已被在野利用」，大型安全资讯账号当天也发了帖，但真正的转发浪潮等到 CISA 发布收录通知之后才来。原因不难理解：很多安全资讯账号和自动化机器人的输入本来就是 KEV 的每日更新；很多企业内部的漏洞工单也只认 KEV。对监测的启示是，用「X 上某个编号的帖子量突然变大」当预警，在这个案例里会比 KEV 本身还晚。帖子量能告诉你「大家现在都在说什么」，不能告诉你「谁已经被打了」。

语言分布也值得一提：106 条里英文 68 条、日文 18 条、法文 5 条、西班牙文 4 条、韩文 3 条，中文只有 1 条，而且是 10 月 24 日、进 KEV 之后的一篇整理帖。中文安全圈对这个漏洞的讨论主要在 X 之外：网易号「安全圈」 10 月 17 日编译了英文报道，台湾的 iThome 也做了报道，GitHub 上的中文网安日报 10 月 17 日收录了影响范围。它们都在 CVE 公开 3 天以后，都是转述。中文读者如果只看中文渠道，这个漏洞的第一条提醒比 GitHub 议题晚了约 36 天。

实测三：噪音占 93.4%，它们长什么样

这 106 条按一个事先写好的规则分成 6 类。要说清楚标注的局限：106 条只按规则标了一遍，没有第二个人独立复标，所以下面的 93.4% 是「一次规则标注的结果」，误差范围未知。要把它用进正式报告，应当请另一个人按同一份规则独立复标 106 条，再报两次标注的一致率。「信号」的定义是带来了 CVE 记录和厂商通告里没有的新事实；「噪音」包括三种：转述已经发布的公告或新闻、模板化的机器人号和每日汇总、推广和无关内容。

结果：转述 80 条、机器人和每日汇总 12 条、推广和无关 7 条，合计 99 条，占 93.4%；带来新事实的 7 条里，4 条是机构用自有数据发的通报（拉脱维亚 CERT.LV、意大利 CSIRT、扫描机构 Censys 的暴露面统计、CISA 的收录通知），2 条是有人自己核对记录后发现的新事实（一条指出 SSVC 字段前后矛盾，一条指出 NVD 只有 CVSS 4.0 分没有 3.x 分），1 条是一位日本管理员 10 月 23 日 08:29（UTC）说自己管理的一台服务器上周被这个漏洞植入了挖矿程序。这 7 条里只有 4 条出现在进 KEV 之前。

推广和无关的 7 条里，有几类在别的漏洞上也会反复出现，值得写进去噪规则：借漏洞标题推加密货币代币的帖子；把「用某个 AI 机器人连一个网址就能生成告警」当卖点的产品推广；「漏洞赏金技巧」式的帖子，教人怎么去找、去测还没打补丁的实例，对防守方没有用，我们按噪音剔除，也不转述其内容；还有一条是讨论「每周都像天要塌下来」的泛泛评论，只因为带了编号被搜进来。

噪音不只在 X 上。Nextcloud 论坛那个 7 楼的帖子里，第 3 楼和第 6 楼来自同一个注册不久的账号，两次都贴了一个「免费 30 秒自检」的外部网页，第 7 楼是社区负责人的提醒：「你发了两条内容几乎一样的链接，我们在盯着垃圾广告。」微博的「Nextcloud 漏洞」10 条里，有 8 条是 8 个不同账号在 2 秒之内发出的同一段 PHP2Shell 新闻，这是典型的矩阵号同步发布，把关键词匹配的结果整片占满。Threads 上搜「Nextcloud Collabora」的 25 条里，有 6 条其实是意大利语动词「collabora」（合作）。

实测四：机器可读的风险字段，比原文还慢

很多团队的漏洞流水线不读描述原文，而是读结构化字段：CISA 通过 Vulnrichment 项目写进 CVE 记录的 SSVC 三个决策点（是否已被利用、能否自动化利用、技术影响），以及 FIRST 每天发布的 EPSS 分数（未来 30 天被观测到利用活动的估计概率）。美国联邦机构的 BOD 26-04 指令正是用 KEV 状态、能否自动化、技术影响和是否暴露在公网这四个变量决定修复时限，其中三个由 CISA 通过 Vulnrichment 给出；本案的 KEV 条目写的是 3 天期限并要求「取证排查」，这是该指令里最紧的一档。

我们用 NVD 变更历史接口把这条记录的 SSVC 每一次变化都取了出来，再用 EPSS 接口取了时间序列。CVE 描述从 10 月 14 日 03:17 起就写着「已被在野利用」，而 SSVC 的变化是这样的：

也就是说，描述原文写着「已被利用」的 9.7 天里，结构化字段先是空的，然后写着「未被利用、不能自动化」整整 9 天，直到 KEV 收录后 47 分钟才改成「已被利用」；EPSS 在这 10 天里一直是 1.2%（当时的百分位约 68%），进 KEV 后第 2 天才到 12.3%。一个「SSVC 为 active 或 EPSS 大于 10% 才开工单」的规则，在这个案例里会比 KEV 还晚 1–2 天，比原文晚 11 天。X 上有一位用户在 10 月 23 日 21:03（UTC）发帖说，他上一条提醒这个矛盾的帖子发出约 6 分钟后 KEV 就收录了，SSVC 也已改成 active，「如果你的流水线拿过之前的值，请重新拉取，联邦期限是 10 月 26 日」。这是 106 条里少见的、对流水线有直接用处的帖子。

这不是说 SSVC 和 EPSS 没用。EPSS 的 FAQ 写明它不是完整的风险分数，只估计「观测到利用活动」的概率；SSVC 是 CISA 分析员的判断，需要证据。我们的观察是：在「证据只存在于项目议题区」的阶段，这两类字段都没有接到这些证据。对读者的意思是，结构化字段适合排序，不适合当闸门；描述原文里「exploited in the wild」这类字样，应该单独做一条文本规则。

实测五：24 个同期进 KEV 的漏洞，X 能早多少

一个案例不够，我们把 KEV 在 9 月 26 日到 10 月 23 日收录的全部 30 个条目拿出来。其中 6 个是 2015–2025 年的老编号（例如 2015 年的 ProFTPD 和 BIND），剩下 24 个 2026 年编号的，在 10:28–10:41（新加坡时间）各用 twitter/search 搜了一次编号，limit 200。KEV 时刻取 NVD 变更历史里第一次出现 KEV 标注的时间，它比 CISA 实际发布晚几十分钟到几小时，所以是上界，会让「X 比 KEV 早多少」略偏大。这和主案例的取法不同：主案例用的是 CISA KEV JSON 的 dateReleased（10 月 23 日 19:30），同一条在 NVD 里的 KEV 标注是 20:17，晚 47 分钟。横截面的 23 个旧版本目录拿不到逐条发布时刻，只能统一用 NVD 标注时间，所以下面横截面里的数都比「真实 KEV 时刻」偏晚一点，主案例在横截面里也按这个取法记为 9.7 天。

结果：24 个里 23 个在 KEV 之前 X 上已经有带编号的帖子，占 95.8%，形式上满足判据 6。但早多少？按未取整的提前量算，中位数约 1.16 天（第 12、13 个是 1.12 天和 1.19 天），13 个早 1 天以上；更关键的是，17 个 CVE 的 X 首帖和 NVD 发布相差不到 0.3 天。原因在 NVD 到 KEV 的间隔：24 个里有 12 个是 NVD 发布当天或第二天就进了 KEV（多为厂商已确认在野利用的零日，如 Citrix NetScaler、Fortinet、Ivanti），X 首帖再早也早不过 CVE 太多。只有 NVD 和 KEV 间隔长的那几个（Atlassian 10 天、Ahsay 10 天、本文主案例 9.7 天），X 才显得「早」，而这个「早」几乎全部来自 CVE 公开本身。

把 NVD 到 KEV 的间隔按自然日排开，形状更清楚：0 天 9 个、1 天 3 个、2 天 2 个，5、6、9 天各 1 个，10 天 3 个，27 天 4 个，中位数 1.5 天。

也就是说，这个月进 KEV 的漏洞分成两群：一群是厂商自己确认零日、CVE 和 KEV 几乎同时出来的，另一群是 CVE 早已公开、利用证据后到的。前一群里，X 的价值在于把「厂商刚发了紧急公告」这件事更快推到你面前，提前量以小时计；后一群里，X 能给的提前量完全取决于 CVE 公开之后有没有人注意到它，Plex 的例子说明，可能整整三周没人提。还有 6 个 CVE 在 NVD 收录之前 X 上就有了带编号的帖子，多是厂商公告里先给出编号、NVD 晚几个小时同步的情形，这也提醒做时间线时不要把 NVD 收录时间当成「编号公开时间」。

例外是 Plex Media Server 的 4 个 CVE：NVD 9 月 23 日就发布了，X 上第一次有人提这些编号却是 10 月 18 日，晚了 24.9 天，只比 KEV 早 2.2 天。这一点我们在下一节单独拆。另外两个提醒：本次 24 个里有 2 个（CVE-2026-88771 和 CVE-2026-102764）返回满了 200 条，最早的帖子可能被截掉，我们写的首见时间对它们是下限；X 搜索返回的是平台排序后的样本，不是全量。SSVC 那边的结论更干脆：30 个条目里，没有一个在 KEV 收录之前就被写成 exploitation: active，SSVC 的「已被利用」在这个样本里就是 KEV 的镜像。EPSS 在 KEV 前一天有数据的 12 个 CVE，全部低于 10%。

三个对照：NetScaler、Plex2Shell、PHP2Shell

为了看清「最早的公开信号在哪」是否有规律，我们又对照了三个同期事件，各用 X 搜了一次，并把各自的一手记录时间对齐（以 CVE 公开为 0 点）。

NetScaler：X 确实早，但早的是传闻。 10:54（新加坡时间）我们搜了 9 月 26 日到 28 日的 NetScaler，返回 176 条，第一条是 9 月 26 日 15:07（UTC），一个大号说「一个正在被利用的未知 Citrix NetScaler 零日让政府和机构关停设备」；NVD 收到 CVE-2026-88771 是 9 月 27 日 17:16，这之前 X 上已有 77 条。几条早期帖子都提到传闻源自 Reddit 上系统管理员的讨论。CISA 当天 20:16 前后收录，并在专门的告警里提醒「修补前先检查是否已被入侵」，Citrix 的安全公告同日发布。这一类是大厂、零日、边界设备：受影响的是大机构，消息先在从业者之间以「出事了」的形式流传，然后厂商、CVE、KEV 在一天之内同时到。X 能早 26 小时，但这 26 小时里的内容是未核实的传闻，适合拉起「先查日志」的预案，不适合直接下结论。

Plex2Shell：厂商早就说了，没人听见。 Plex 在 9 月 1 日 18:30（UTC）的论坛公告里写「已发布 1.43.3 修复若干安全问题，CVE 已申请」，这个帖子到现在有 86,684 次浏览；可同期在 X 上搜「plex "security update"」，9 月 1 日到 22 日只有 1 条。CVE 9 月 23 日发布（如 CVE-2026-96652），按意大利国家网络安全局 ACN 的通报，4 个 CVE 单看评分都不高（CVSS 3.1 分别为 4.3、6.5 等），没人当回事。转折是研究者 10 月 16 日公开了把 4 个漏洞串起来的完整分析，一位研究者的蜜罐 10 月 17 日就观测到了利用（他的博客），X 上带「Plex2Shell」的帖子 10 月 18 日 15:59 才出现第一条，CISA 10 月 20 日收录。这一类的规律是：低分漏洞的组合风险，只有在利用分析公开后才被看见；最早的公开信号是厂商自己的公告，监测要能读到「重要安全更新、细节稍后公布」这类措辞。Reddit 上的受害者自述（r/unRAID「服务器被 plex2shell 打了，现在怎么办」，109 条评论）出现在 10 月 21 日，已经是 KEV 之后。

PHP2Shell：X 的热度最高，却至今不在 KEV。 PHP 团队 10 月 20 日预告将发布两个严重漏洞的修复，X 上第一条带 CVE-2026-109618 编号的帖子是 10 月 20 日 18:56（UTC），比修复发布和 CVE 公开（10 月 21 日 13:48，据 CVE.org）早约 19 小时；到 10 月 21 日 14:00 禁令解除前，我们这一次搜索的样本里已有 68 条。AWS 威胁情报 10 月 21 日的博客说，它的蜜罐网络在 10 月 17 日就看到了利用尝试，比公开早 4 天；欧盟机构 CERT-EU 的通报记录了 10 月 20 日、21 日、23 日三次更新。但截至我们 10 月 26 日读取，KEV 目录仍停在 2026.10.23 版，没有这两个编号。我们 10:52 的搜索在 10 月 20 日到 23 日之间就拿满了 200 条，日期上限同样没被严格执行。这一类说明，社交平台的热度和 KEV 收录之间没有必然关系；KEV 要「可靠证据显示在野利用」，蜜罐里的尝试未必算数。对读者的意思是：PHP2Shell 这样的漏洞，不能等 KEV，要按自己的暴露面直接排期。

把四个案例放在一起，结论不是「社交平台没用」，而是「最早的公开信号在哪，取决于谁先受害、受害者去哪里说话」。自托管的小机构去项目议题区和用户论坛；大机构的从业者先在社交平台上互相打听；厂商在自己的论坛和发布说明里低调提醒；研究者在博客和代码仓库里发分析。按 CVE 编号订阅，覆盖的只是这些之后的那一段。

从信号到处置：一条每天跑一圈的流程

第一站盯源头。名单不是 CVE 编号，而是你实际在用的组件名，比如 richdocumentscode、Plex Media Server、NetScaler。每个组件对应三类来源：项目的议题区和版本发布（GitHub 有免费接口，可以按时间取新议题和新版本）、厂商的用户论坛或安全公告页（很多是 Discourse，可以取 JSON）、以及几个社交平台的关键词搜索。KEV JSON 和 CVE 描述原文也每天取一次，但它们的角色是核对和定期限，不是起跑线。本案里，一个每天读 richdocumentscode 议题区的流程，会在 9 月 11 日看到标题里的「Hack」，比任何编号订阅早一个月。

第二站存证据。每次取回的原始响应不做改写，连同请求参数、UTC 时间和文件哈希一起存档。原因有两个：一是事后要能回答「我们什么时候知道的」，这在 BOD 26-04 要求的取证排查和很多行业的事件报告里都会被问到；二是平台内容会变，帖子会被删，评论会被编辑，转述会出错。本文时间线里 Censys 把首次攻击写成 9 月 16 日的那处差异，就是靠回到存档的议题原文才发现的。

第三站对资产。拿组件名而不是 CVE 编号去比对资产清单，原因前面已经算过：在 Patchless Window 研究里，8 月份的中位数是 39.2 天没有编号。比对要细到「部署方式」：本案只影响内置 CODE 应用，独立部署的 Collabora 不受影响；只按「我们有没有用 Collabora」比对，会产生大量误报，也会让人对真正受影响的那一台掉以轻心。

第四站去噪音。按上一节的 6 类规则给每条内容打标签，转述、机器人、推广和攻击技巧帖打上标签后不进处置队列，但保留在存档里，便于复核。我们的经验数字是：按编号搜 X，93.4% 会被剔除；按产品名在 CVE 之前搜，100% 被剔除。去噪规则要包括语言撞词（意大利语的 collabora）、矩阵号同步发布（8 个账号 2 秒内同一段话）和论坛里的「免费自检」推广链接。

第五站处置。对本案这类问题，Collabora 通告给的动作是：升级到 26.4.303 或删除应用，停用不够；运行在已停止维护的 Nextcloud 29 及更早版本上的，要么升级 Nextcloud，要么删除应用。Nextcloud 论坛第 4 楼的管理员给了一个很实用的核对办法：升级后 Nextcloud 自带的完整性检查报告了应用目录里一个「多出来的文件」，他据此删掉了文件并卸载了这个应用。意大利 CSIRT 的通报提到了「植入网页后门和窃取凭据」，所以我们建议的补充动作是：对 9 月 10 日以来暴露过的实例，补丁之外再跑一次完整性检查、看访问日志，并轮换网页服务账户能读到的数据库口令和应用口令。我们只转述这些防守动作，不转述攻击请求的样子。

第六站结案。每一单要能回答四个问题：谁处理的、什么时候、凭哪条证据（指向存档里的那份原始响应）、做了什么。KEV 收录后，再把它的到期日和你的结案时间对一下。下面是我们建议的最小记录字段，都是这次实测里真用到的：

算一笔账：50 个组件，一个月多少钱

按 10 月 26 日 10:13（新加坡时间）读取的能力目录（以价格页为准），twitter/search、reddit/search、youtube/search、linkedin/search、threads/search 每次都是 $0.000556，weibo/search 每次 $0.000806，按次计费，不按返回条数；另有 3 次用 EveryInfra 搜索的 quick 档（每次 $0.000694）在网页和论坛里找 CVE 之前的帖子，都是 0 条。

一个中小团队假设有 50 个对外暴露的组件，每个组件每天在 X 和 Reddit 各搜一次：每天 100 次 × $0.000556 = $0.0556，30 天 $1.668。GitHub 议题、Discourse 论坛、NVD、CVE.org、KEV 和 EPSS 的接口都是免费的公开接口，不进这笔账。空结果和失败不扣费：本文 60 次请求里有 6 次被限速（返回 429）、1 次参数写错（返回 422）、1 次空结果自动退还，都没有扣费，实际计费 52 次，合计 $0.029576；另外生成头图和一张示意图花了 $0.06。

频率要不要提到每小时？同样 50 个组件、X 和 Reddit 各一次，每小时跑一圈是每天 2,400 次，$1.3344，一个月约 $40.03，是每天一圈的 24 倍。换来的是把「看到」的时间最多提前不到一天。本案最早的信号比 CVE 早 32.5 天，比 KEV 早 42.2 天，每天一圈和每小时一圈的差别，在这个尺度上可以忽略；真正需要按小时盯的，是 NetScaler 那一类「CVE 和 KEV 一天之内同时到」的边界设备零日，而它们的名单通常只有几个组件，可以单独拉一张高频清单，不必整张表一起提频。

用代码或 AI 客户端取同一份数据

一次 curl 按编号搜 X（Key 写成占位符）：

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer <API Key>" \
  -H "Content-Type: application/json" \
  -d '{"platform":"twitter","action":"search","params":{"keyword":"CVE-2026-110447","sort":"latest","limit":200}}'

本文用到的返回字段，与目录里 twitter/search 的 response_fields 逐个对过：

Reddit 用 reddit/search，参数是 keyword 和 sort（newest、relevance 等），返回字段里 community、comment_count、posted_at 最常用；它的时间范围固定为最近一个月，做 30 天以上的回看要在当时就存档。

在 Claude Code 里，先按快速开始建一把 Key，再加远程 MCP 服务器：

claude mcp add --transport http everyinfra https://api.everyinfra.com/mcp \
  --header 'Authorization: Bearer ${EVERYINFRA_API_KEY}'

然后可以直接说：「用 everyinfra_call_api 在 X 上按 richdocumentscode 和 CVE-2026-110447 各搜一次，按 posted_at 排序，标出 CVE 公开（2026-10-14 02:27 UTC）之前和之后各有几条，并把机构账号和个人账号分开列。」

报错和扣费，都是本次实测遇到的。Reddit 的 sort 写成不存在的 oldest，返回 422 invalid_value，错误里列出全部允许值，并写明「Nothing was charged」。测试 Key 每分钟 10 次的限速被同一把 Key 的其他请求占满时，返回 429 rate_limited，带 retry_after 秒数，同样不扣费，我们按它给的秒数加 10 秒重试后全部成功。同步空结果返回 200、count 为 0、billing.reason 为 empty_result_refunded，不扣费；逐条对账见失败返还与对账。X 搜索返回满 limit 时，最早的帖子可能被截掉，返回里不会报错，要自己看 count 是否等于 limit。

最近 60 天的变化和相关研究

2026 年 10 月 23 日，CISA 收录 CVE-2026-110447，期限 3 天并要求取证排查。 见上文的 CISA 告警。对读者的意思是：KEV 条目里的 forensicTriage: Yes 字段值得单独做一条规则，它意味着「补完还要查有没有被入侵」。

2026 年 10 月 21 日，PHP2Shell 公开，AWS 说利用比公开早 4 天。 见上文。对读者的意思是：排查时间要从已知最早的利用往回算，不是从公告日往后算。

2026 年 10 月 20 日，CISA 一次收录 6 个漏洞，其中 4 个是 Plex2Shell。 见上文。对读者的意思是：低分漏洞组合起来可以进 KEV，按单个 CVSS 分数过滤会漏。

2026 年 10 月 14 日，Collabora 把延迟归因于 CVE 申请排队，并申请成为 CNA。 见上文的博客。对读者的意思是：开源项目自己成为编号机构以后，编号会来得更快，但在那之前，按编号订阅仍会晚一个月。

2026 年 10 月，Second Security 发布 Patchless Window 研究。 8 月份「修复已公开、CVE 未出」的中位数是 39.2 天。对读者的意思是：开源组件的监测必须直接读项目的提交、发布和议题，而不是等编号。

2026 年 9 月 25 日，一篇 arXiv 论文提出用 GitHub 上利用代码仓库的星标、分叉和用户数做优先级指标（GPM），并称已并入 EPSS 第 5 版（arXiv 2609.31004）。对读者的意思是：代码仓库的公开活动正在被正式纳入评分，但本案的信号是议题区的受害者报告，不是利用代码，仍然不在这类指标的覆盖范围里。

2026 年 8 月 19 日，一项基于已部署威胁知识图谱的测量研究发表（Information 期刊），它用 1 万条威胁相关的社交帖子做对照，发现知识图谱已覆盖帖子里 96% 的可操作漏洞且不晚于帖子，社交平台只在「在野利用的早期预警」上领先。对读者的意思是：这和本文的观察一致，社交数据的价值在少数受害者自述和传闻，不在漏洞编号的覆盖面。

2026 年 8 月，STINER 研究用 X 上的告警做欧洲威胁态势分析（arXiv 2608.14418），发现不同国家的攻击在 X 上的可见度差别很大。对读者的意思是：本文 106 条里英文 68 条、中文 1 条，语言和地区是社交监测绕不开的变量。更早的方法背景是 2015 年 USENIX Security 的一篇论文，它尝试用 Twitter 帖子预测哪些漏洞会被真实利用。

本文的边界

第一，主案例只有一个，三个对照也只是各搜了一次；我们没有一个「没被利用的漏洞」对照组，所以算不出误报率，也不能说「项目议题区一出现被黑帖，就一定是真漏洞」。本案的议题区信号可信，是因为它附了日志、多人复现、维护者在 3 天内回应，这三点在别的议题里未必都有。

第二，X 搜索返回的是平台排序后的样本。本文按编号搜到的 106 条没到上限，但我们无法证明 X 上不存在更早的、没被搜索返回的帖子；同理，X 的 until 日期上限在本次 4 次请求里都没被严格执行，我们靠 posted_at 重筛。Reddit 搜索只覆盖最近一个月，CVE 之前 9 月 10 日到 25 日这一段，Reddit 上有没有相关帖，我们这次查不到；用通用网页搜索限定 reddit.com、10 月 14 日以前，返回的都是安装求助之类的旧帖，没有一条讲被入侵。

第三，噪音标注按事先写定的规则只做了一遍，没有第二个标注者独立复标。「信号」和「转述」的边界有主观成分，例如一条把通告重写成处置清单的帖子，我们算转述；换一个人可能算信号。

第四，SSVC 和 EPSS 的观察针对的是「描述原文已经写明被利用」这一种情形，不能推广成「这两类字段总是慢」。EPSS 的目的本来就是估计概率，不是复述 KEV。

常见问题

CVE 一般什么时候发布？漏洞修复了是不是就有 CVE？ 不一定。本案修复版 9 月 11 日发布，CVE 10 月 14 日才公开，中间 32.5 天没有任何编号；Patchless Window 研究测到 2026 年 8 月的中位数是 39.2 天。开源项目可以自己申请成为编号机构来缩短这段时间。（问题出自搜索联想词「cve 什么时候发布」。）

怎么判断一个漏洞已经被在野利用？ 看三类证据：受害者自己贴出的日志和现象（本案 GitHub 议题）、厂商或 CVE 描述里的「exploited in the wild」字样、KEV 收录。前两类更早，第三类更权威。SSVC 和 EPSS 在本案里都比描述原文慢了 9–11 天。（问题出自搜索联想词「漏洞 在野 利用」。）

KEV 里的漏洞和 CVE 是什么关系？没进 KEV 是不是就不用急？ KEV 只收已有 CVE 编号、有可靠利用证据、有明确修复动作的漏洞，所以它天然晚于 CVE。本文统计的 24 个里，12 个是 CVE 当天或第二天进 KEV，中位间隔 1.5 天；PHP2Shell 截至 10 月 26 日仍未进 KEV，但已有多家机构通报利用尝试。没进 KEV 不等于安全。（问题出自搜索联想词「cve kev」。）

相关阅读

• 平台页：X (Twitter) 爬虫 API、Reddit 爬虫 API、微博爬虫 API
• 能力页：X (Twitter) 关键词搜索爬虫 API、Reddit 关键词搜索爬虫 API、YouTube 关键词搜索爬虫 API、LinkedIn 关键词搜索爬虫 API、Threads 关键词搜索爬虫 API、微博关键词搜索爬虫 API
• 同系列：漏洞情报怎么做成可执行产品：从告警列表到修复队列、荐股群拉高出货：公开社交数据能测到哪些早期信号、社媒数据做研究样本：同一查询重搜两次，一半结果变了

参考资料

1. CollaboraOnline/richdocumentscode，GitHub 议题 #354「Security issue - Hack」，2026-09-11，https://github.com/CollaboraOnline/richdocumentscode/issues/354
2. CollaboraOnline/richdocumentscode，版本 26.4.303 发布页，2026-09-11，https://github.com/CollaboraOnline/richdocumentscode/releases/tag/26.4.303
3. GitHub，REST API 文档：Issues，读取于 2026-10-26，https://docs.github.com/en/rest/issues/issues
4. Nextcloud 社区论坛，《To Collabora Built-in User: Update ASAP》，2026-10-03，https://help.nextcloud.com/t/to-collabora-built-in-user-update-asap/250516
5. Discourse，API 文档，读取于 2026-10-26，https://docs.discourse.org/
6. CVE Program，CVE-2026-110447 记录，2026-10-14，https://www.cve.org/CVERecord?id=CVE-2026-110447
7. CVE Services API，CVE-2026-110447 记录元数据，读取于 2026-10-26，https://cveawg.mitre.org/api/cve/CVE-2026-110447
8. NIST NVD，CVE-2026-110447 详情页，2026-10-14 发布、2026-10-24 修改，https://nvd.nist.gov/vuln/detail/CVE-2026-110447
9. NIST NVD，CVE 变更历史 API 文档，读取于 2026-10-26，https://nvd.nist.gov/developers/vulnerability-change-history
10. Collabora Online，安全通告 GHSA-g3vx-3m76-fghh，2026-10-14，https://github.com/CollaboraOnline/online/security/advisories/GHSA-g3vx-3m76-fghh
11. Collabora Online，《Stay Safe: Upgrade Everything Regularly》，2026-10-14，https://www.collaboraonline.com/blog/stay-safe-upgrade-everything-regularly/
12. Censys，《Oct 16 Advisory: Collabora Online Built-in CODE Server OS Command Injection》，2026-10-16，https://censys.com/advisory/cve-2026-110447/
13. CISA，Known Exploited Vulnerabilities Catalog，读取于 2026-10-26，https://www.cisa.gov/known-exploited-vulnerabilities-catalog
14. CISA，KEV JSON 数据（2026.10.23 版），读取于 2026-10-26，https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
15. CISA，《Reducing the Significant Risk of Known Exploited Vulnerabilities》（收录标准），读取于 2026-10-26，https://www.cisa.gov/known-exploited-vulnerabilities
16. Second Security，《The Patchless Window》，2026-10，https://thepatchlesswindow.com/
17. BleepingComputer，《Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers》，2026-10-15，https://www.bleepingcomputer.com/news/security/hackers-exploit-collabora-rce-flaw-to-backdoor-nextcloud-servers/
18. NIST，《NIST Updates NVD Operations to Address Record CVE Growth》，2026-04-15，https://www.nist.gov/news-events/news/2026/04/nist-updates-nvd-operations-address-record-cve-growth
19. Hacker News，Algolia 搜索 API 文档，读取于 2026-10-26，https://hn.algolia.com/api
20. Hacker News，《Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers》链接帖，2026-10-15，https://news.ycombinator.com/item?id=50111052
21. 网易号「安全圈」，《黑客利用 Collabora RCE 漏洞为 Nextcloud 服务器植入后门》，2026-10-17，https://www.163.com/dy/article/L9FD1AUD0511A5GF.html
22. iThome，《雲端版辦公室軟體 Collabora Online 漏洞遭到利用，攻擊者試圖入侵 Nextcloud 伺服器》，2026-10，https://www.ithome.com.tw/news/179782
23. Unclecheng-li/cybersecurity-daily，《网安日报速递-2026年10月17日》，2026-10-17，https://github.com/Unclecheng-li/cybersecurity-daily/blob/main/%E7%BD%91%E5%AE%89%E6%97%A5%E6%8A%A5%E9%80%9F%E9%80%92-2026%E5%B9%B410%E6%9C%8817%E6%97%A5.md
24. cisagov，Vulnrichment 项目仓库，读取于 2026-10-26，https://github.com/cisagov/vulnrichment
25. FIRST，EPSS Frequently Asked Questions，读取于 2026-10-26，https://www.first.org/epss/faq
26. CISA，BOD 26-04: Prioritizing Security Updates Based on Risk，2026-06-10，https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
27. FIRST，EPSS Get the Data（含 API），读取于 2026-10-26，https://www.first.org/epss/data
28. CISA，《Critical Zero-Day Vulnerabilities Exploited in Citrix NetScaler ADC, Gateway》，2026-09-27（10-09 更新），https://www.cisa.gov/news-events/alerts/2026/09/27/critical-zero-day-vulnerabilities-exploited-citrix-netscaler-adc-gateway
29. Citrix，安全公告 CTX697096，2026-09-27，https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX697096
30. Plex 论坛，《Important Security Update for Plex Media Server v1.43.2 and earlier》，2026-09-01，https://forums.plex.tv/t/important-security-update-for-plex-media-server-v1-43-2-and-earlier/942319
31. 意大利国家网络安全局（ACN），《Plex Media Server: rilevato sfruttamento in rete della catena di attacco Plex2Shell》，2026-10，https://www.acn.gov.it/portale/w/plex-media-server-rilevato-sfruttamento-in-rete-delle-catena-di-attacco-plex2shell
32. boredhackerblog，《Plex vulnerabilities being exploited in the wild to drop a cryptominer》，2026-10-17，https://www.boredhackerblog.info/2026/10/plex-vulnerabilities-being-exploited-in.html
33. CISA，《CISA Adds Six Known Exploited Vulnerabilities to Catalog》，2026-10-20，https://www.cisa.gov/news-events/alerts/2026/10/20/cisa-adds-six-known-exploited-vulnerabilities-catalog
34. AWS Security Blog，《Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot》，2026-10-21，https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/
35. CERT-EU，Security Advisory 2026-018《Critical Vulnerabilities in PHP》，2026-10-20（10-23 更新），https://cert.europa.eu/publications/security-advisories/2026-018
36. CISA，《CISA Adds One Known Exploited Vulnerability to Catalog》（CVE-2026-110447），2026-10-23，https://www.cisa.gov/news-events/alerts/2026/10/23/cisa-adds-one-known-exploited-vulnerability-catalog-0
37. Akhoundali 等，《GitHub Engagement Signals for CVE Prioritization: The GitHub Popularity Metric (GPM)》，arXiv 2609.31004，2026-09-25，https://arxiv.org/abs/2609.31004
38. 保加利亚科学院信息与通信技术研究所等，《Time-Series and Social-Media Threat Analytics over a Deployed Cyber-Threat Knowledge Graph》，Information 17(8):794，2026-08-19，https://www.mdpi.com/2078-2489/17/8/794
39. Ech-Chammakhy 等，《STINER: Automated Extraction of Strategic Cyber Threat Intelligence from X》，arXiv 2608.14418，2026-08-14，https://arxiv.org/abs/2608.14418
40. Sabottke、Suciu、Dumitraș，《Vulnerability Disclosure in the Age of Social Media: Exploiting Twitter for Predicting Real-World Exploits》，USENIX Security 2015，https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/sabottke
41. X 帮助中心，Advanced search 说明，读取于 2026-10-26，https://help.x.com/en/using-x/x-advanced-search
42. NIST NVD，CVE-2026-88771 详情页，2026-09-27，https://nvd.nist.gov/vuln/detail/CVE-2026-88771
43. NIST NVD，CVE-2026-96652 详情页，2026-09-23，https://nvd.nist.gov/vuln/detail/CVE-2026-96652
44. NIST NVD，CVE-2026-109618 详情页，2026-10-21，https://nvd.nist.gov/vuln/detail/CVE-2026-109618
45. Reddit r/NextCloud，管理员自述「Nextcloud compromised via the built-in Collabora app」，2026-10-22，https://www.reddit.com/r/NextCloud/comments/1xcsjlx/nextcloud_compromised_via_the_builtin_collabora/
46. CISA，Stakeholder-Specific Vulnerability Categorization（SSVC），读取于 2026-10-26，https://www.cisa.gov/stakeholder-specific-vulnerability-categorization-ssvc
47. NIST NVD，CVE API 文档，读取于 2026-10-26，https://nvd.nist.gov/developers/vulnerabilities