当 AI 发现我们遗漏的 Bug：MariaDB 安全领域忙碌的一年

来源： MariaDB.org
作者： Frédéric Descamps
发布时间： 2026/10/2 23:03:32
原文链接： https://mariadb.org/when-ai-finds-the-bugs-we-missed-a-very-busy-year-for-mariadb-security/

---

你可能已经注意到，最近一些 MariaDB Server 版本比预期稍晚发布。对此我们深表歉意！但这背后有一个很好的理由。

在过去几个月里，MariaDB 项目经历了我们前所未见的情况：安全报告数量大幅增加。而当我说“大幅”时，看看这张图：

图片链接: https://mariadb.org/mariadb-on-hackerone/

多年来，我们每个季度都会收到几份 security reports（安全报告）。有时 3 份，有时 6 份、11 份……图表中的最高值是 16 份。

然而突然之间，在某个季度，我们收到了 81 份报告。

下一个季度：92 份！

但这里需要做一个重要区分：

173 份安全报告并不意味着 173 个 vulnerabilities（漏洞）。

每份报告都必须经过调查。有些会转化为已确认的安全漏洞。另一些则揭示出有效的 bugs（缺陷）或有趣的 edge cases（边界情况），但最终并未被归为同一类。

无论哪种情况，都需要有人复现问题、理解问题，并确定需要修复什么。

以下是该流程的概述：

图片链接: https://mariadb.org/wp-content/uploads/2026/10/hackerone.png

那么，发生了什么？

AI 也在寻找漏洞

我们都知道，AI 正在改变开发者编写代码的方式。无论我们喜欢与否，这正在发生。

但它还有另一面：AI 也在改变安全研究员寻找漏洞的方式。

现代 AI 辅助工具能够分析非常庞大的代码库、跟踪代码路径、识别可疑模式、生成测试用例，并帮助安全研究员调查那些以前需要大量人工工作才能覆盖的领域。

MariaDB Server 是一个大型且成熟的项目，其代码涵盖了数量庞大的功能、协议、存储引擎、平台以及它们的各种不寻常组合。

突然间，配备了新工具的研究员开始以以前根本不切实际的方式审视这一切。

结果就是你在这张图表中看到的。

这是 AI 垃圾吗？

当然，当我们开始收到这么多报告时，这是一个担忧。如果你最近在 GitHub 上花过一些时间，你大概知道我在说什么。AI 可以生成一份非常有说服力的漏洞报告，而那个漏洞根本不存在。

漂亮的解释、漂亮的代码、漂亮的堆栈跟踪……但背后什么都没有。这不是发生在我们身上的情况。

我们收到的几乎所有报告都是好报告。真实的问题，背后有真实的工作。而最重要的部分：我们把它们全部修复了！

我们调查了它们

我们的工程团队审查了这些报告，复现了发现的问题，评估了它们的影响，在需要的地方开发了修复方案，审查了这些方案，对它们进行了测试，并且经常把修复反向移植到多个维护分支。

对于已确认的漏洞，修复已包含在受影响且受支持的 Community 和 Enterprise Server 版本的最新维护版本中。

我们还开始发布自己的 MariaDB 安全公告。这让我们能够传达已确认的漏洞及其修复，而不必等待数周才能完成 CVE 分配流程。

在撰写本文时，其中已有 27 份公告公开且已修复。

连接器（Connector）也有其专用的安全公告 \[1]\[2]\[3]。

现在，把调查和工程工作乘以我们在 2026 年收到的前所未有的报告数量。这就解释了为什么有些版本发布比预期耗时更长。

更多报告并不意味着 MariaDB 突然变得不那么安全了

这个区分很重要。图表显示的是收到的报告，而不是已确认的漏洞。从流程中你可以看到，有些问题与服务器无关（比如连接器），有些虽然已修复但不会产生公告和/或 CVE，还有一些是重复项。这就解释了 81 份报告与 27 份公告之间的差距。

因此，这一突然增长不应被解读为一张显示 MariaDB 在 2026 年突然变得不那么安全的图表。

发生巨大变化的是针对 MariaDB 项目（就像许多其他开源项目一样）所进行的安全研究数量，以及研究员可用于开展这项工作的工具。

以前难以发现或耗时才能发现的问题和边缘情况，现在可以更高效地探索。

而当一份报告指出了真实的问题时，这就给了我们修复它的机会。这正是一直在发生的事情。每一份报告给我们的有效安全问题都已被调查并修复。

修复一个安全问题不仅仅是改几行代码然后推送到 GitHub。如上所述，我们需要复现它、理解它、检查哪些版本受影响、修复它、审查修复、测试它，而且经常要反向移植到多个维护版本，有时还要撰写一份安全公告、分配评分、申请 CVE ID……

为几份报告做这些事是正常的。为 81 份、然后是 92 份报告做这些事，那就是另一回事了！

感谢黑客们！

还有另一张我非常想分享的图表：

图片链接: https://mariadb.org/wp-content/uploads/2026/09/top_hackers_by_submission_count.png

以下是让我们的工作忙碌不已的部分安全研究人员 😉

排在首位的是 fg0x0，提交了令人惊叹的 51 份报告！

这里有一个重要细节：fg0x0 一直专注于 MariaDB Connectors，而不是 MariaDB Server（MariaDB 服务器）本身。

而这项工作已经带来了具体的修复。例如，一份报告的 Connector/Node.js 问题涉及 PAM 认证，以及确保凭据不会通过不安全的传输方式发送。类似的工作还覆盖了其他连接器，包括 R2DBC。

在 Server 方面，我们有 letchu_pkt，提交了 13 份报告；vortfu 提交了 12 份；muhammaddaffa 提交了 10 份；其后还有若干其他研究人员。

顺便提一下，vortfu 来自 Automattic。

其中一些发现非常重要。例如，letchu_pkt 报告了若干 围绕 Galera/wsrep 处理的问题，包括涉及传递给 shell 命令的取值的问题。这些问题此后已在受影响的维护版本中修复。

所以，要向他们所有人献上大大的感谢！

不仅是图表顶部可见的那些人。感谢每一位花时间审视 MariaDB、发现可疑之处并负责任地进行报告的人。

这才是开源安全应有的运作方式。

旧代码值得用新眼光审视

这里还有一个我觉得很有意思的启示。作为开发者，我们自然会仔细审视新代码。新功能会经过审查、会配上测试、会有人试用、会有人把它弄坏。但旧代码呢？

嗯……它一直都在那里，所以肯定没问题，对吧？……其实并非如此 😉

代码陈旧只能说明，此前没有人发现过问题。

而这或许正是 AI（人工智能）在软件开发中的一个非常好的用途。我们不只是用它生成更多新代码，还可以用它回过头去重新审视我们已经拥有的代码。

MariaDB 当然不是唯一能从中受益的项目。大型开源项目中有大量旧代码，我预计安全研究人员会继续借助这些新工具发现有意思的东西。这是好事。

继续寻找

所以，如果你是一名安全研究人员，使用模糊测试（fuzzing）、静态分析、AI、自己写的脚本，或者任何你构建的新工具：继续寻找！

如果你发现了看起来像安全问题的东西，请通过适当的非公开安全渠道进行报告，而不是立即公布漏洞利用代码。并且，请尽可能提供一个可复现的测试用例。这会带来巨大的差别。

致所有在这段异常忙碌的几个月里做出贡献的研究人员：再次感谢你们。

致我们的开发者——他们的日常工作之上突然堆积了如山的（安全）报告：同样向你们致以最诚挚的感谢。

也致我们的用户——你们有时会疑惑，为什么某个版本比预期多花了一点时间……现在你们知道原因了。😉

尽情享用 MariaDB Server 吧！