一句话结论：AI 把”挖洞→披露→被利用”的链条压到了 4 天，而 DBA 的补丁节奏还停留在”季度 CPU、按月打小版本”。 这个时间差，就是现在攻击者最好的窗口。

AI 机械眼扫描代码流，背景是倒计时钟表

两个数字

第一，AI 挖出的漏洞，一半以 RCE 收尾。

Google 威胁情报团队的最新统计：归因于 AI agent 发现的漏洞中，约一半最终是远程代码执行（RCE）；而整个 CVE 生态里，这个比例只有约四分之一。AI 不只是在”找得多”，它找的恰恰是最值钱的那类——能直接拿 shell 的。

AI 发现的漏洞 50% 以 RCE 收尾，传统方式仅 26%

第二，从披露到被利用：4 天。

CVE-2026-1731，BeyondTrust 远程访问漏洞，由 Hacktron AI agent 发现。从公开披露到出现主动利用，只用了 4 天。4 天是什么概念？一个 Oracle CPU 季度补丁从发布到你排期打上，通常要几周；一次 PG 小版本升级走变更流程，也要几天。等你走完流程，PoC 已经在野了。

从漏洞披露到被利用只要 4 天，远快于传统补丁周期

顺带回顾一下昨天那篇：CVE-2026-15742（PG fuzzystrmatch 整数回绕，CVSS 8.8），PoC 公开，低权限数据库用户可执行操作系统命令——正是”一半 RCE”里的典型样本。

对 DBA 意味着什么

以前的安全模型是：高危 CVE 出来 → 评估影响 → 排期 → 打补丁，窗口按”周”算。现在 AI 把攻击侧的准备时间压到”天”：

  1. 补丁优先级要重排。 不是所有 CVE 都值得连夜打，但”可远程利用 + 有 PoC + 影响数据库核心组件”的，必须进紧急通道。fuzzystrmatch 这种”装了扩展就中招”的，属于最高一档。
  2. 资产清单比补丁本身更重要。 4 天窗口里，你最大的敌人不是补丁难打，而是不知道自己哪里装了有问题的东西：哪些实例装了 fuzzystrmatch？哪些还在 EOL 分支？哪些 MySQL 还在用 mysql_native_password？答不上来，4 天就白给了。
  3. 应急手段要预演。 来不及升级时，DROP EXTENSION、禁用插件、网络层封禁，这些”先止血”的操作要平时就练熟，而不是在 4 天窗口里现查文档。

DBA 行动清单

  • 给所有 PG/MySQL 实例建一份”扩展与插件清单”：装了什么、哪个版本、哪条版本线（SELECT * FROM pg_extension / SHOW PLUGINS 先跑一遍）
  • 把 EOL 分支的实例标出来：PG 13 及更早、MySQL 8.0（4 月已 EOL）——这些分支不会再有安全补丁，是 4 天窗口里最先被扫的
  • 订阅 2 个情报源：PostgreSQL 官方安全公告 + 你用的发行版/云厂商的安全通告，别等中文媒体翻译
  • 演练一次”来不及升级”的应急：挑一个测试库，实际走一遍 DROP EXTENSION / 参数热改 / 回滚，计时

一次巡检，回答”4 天窗口”里最要命的问题

4 天窗口真正考验的不是你打补丁的手速，而是你对自家实例的家底清不清楚：版本线、扩展清单、已知高危缺口。

DBCheck 的巡检就是干这个的：上传采集包，一次把版本升级风险点、安全补丁缺口、被砍功能影响扫出来，附可执行 SQL。可以先免费帮你看一遍采集包，出份简版评估；正式报告单次巡检 199 元，首单 99 元。微信/邮箱：

参考：

  • Google Threat Intelligence: Vulnerability discovery and exploitation trends in the AI era
  • infosecurity-magazine: AI-found vulnerabilities lead to RCE at nearly twice the usual rate（CVE-2026-1731，披露到利用 4 天）

原文作者: liups.com

原文链接: http://liups.com/posts/c0906e9/

许可协议: 知识共享署名-非商业性使用 4.0 国际许可协议