MariaDB 10 月 9 日连爆三个 8 分以上高危：CONNECT 引擎、systemd、FRM 元数据

2026 年 10 月 9 日，MariaDB 一口气发了 6 个分支的安全修复版：10.6.28、10.11.19、11.4.13、11.8.9、12.3.3、13.0.2。同一批 CVE 里有三个 8 分以上的狠角色：CVE-2026-107815（CVSS 8.5），CONNECT 引擎 OS 命令注入；CVE-2026-107818（CVSS 8.4），systemd service 文件的环境变量注入；CVE-2026-107821（CVSS 8.0），FRM 元数据越界读写。再加上一个 6.4 的权限缓存串味（CVE-2026-107822），10 月第二周的数据库安全头条，被 MariaDB 包了。

MariaDB 10 月 9 日安全批量修复，三个 8 分以上高危

先说结论：这次没有”云托管自动修了就没事”的侥幸——MariaDB 的自建比例比 Redis 高得多，6 个分支全中招，10.11 和 11.8 两个 LTS 一个没跑掉。SELECT VERSION() 对一下修复线，低于的就是裸奔。

CVE-2026-107815：CONNECT 引擎，OS 命令注入，8.5 分

CONNECT 是 MariaDB 那个”万能外挂”存储引擎：能把 ODBC 数据源、CSV、XML 甚至 DOS 表映射成 SQL 表来查。平时没人理它，出事全是大事。这次的问题出在 DOS 表类型上——攻击路径可以一路走到 OS 命令注入（GHSA-4wgx-ffg9-jrwq，MDEV-40637）。

扎心的是利用门槛：CONNECT 引擎在很多发行版里是默认编译进插件目录的，不少 DBA 装完就没管过它。SHOW ENGINES 里看到 CONNECT 的 SUPPORT 是 YES 或 DEFAULT，这台机器就在影响面上。更麻烦的是，CONNECT 本来就是用来”连外部”的，权限模型天生比 InnoDB 松一截。

CVE-2026-107818：systemd 读了个不该读的文件，8.4 分

这个洞的利用链写出来像段子，但每个环节都是真的（GHSA-mhvc-vqcq-7vq5，MDEV-40629，CWE-15）：

MariaDB 的 systemd unit mariadb.service 在重启时会读取 /run/mysqld/wsrep-new-cluster；
一个只有 FILE 权限的数据库用户，如果 secure_file_priv 允许写到 /run/mysqld，就能创建这个文件；
文件内容会被当成环境变量注入进重启后的 MariaDB 服务进程。

翻译成人话：你给应用账号开的 FILE 权限（”就导个 CSV 嘛”），配上一个没配好的 secure_file_priv（空值=随便写），等于把数据库服务进程的环境变量控制权交了出去。FILE 权限和 secure_file_priv 这两个 DBA 面试必考、生产天天见的配置项，这次直接变成了 8.4 分高危利用链的一环。

另外两个也别漏

CVE-2026-107821（CVSS 8.0）：打开二进制 FRM 文件时，对元数据里的计数、偏移、长度、字段边界校验不足。攻击者只要能往 datadir 里放一个精心构造的 .frm 文件，就能触发越界读写、搞崩服务，甚至可能执行代码。datadir 写权限管得松的，自己体会。

CVE-2026-107822（CVSS 6.4）：权限缓存的 key 生成撞车了——role 和 localhost 用户名因为 IP 部分都是空的，算出了同一个缓存 key。有 CREATE USER 权限的攻击者可以创建一个”撞名”账号，等原账号的库权限进了缓存，就能冒用对方的权限。中危，但修起来就是一次升级的事，顺手一起修了。

影响版本和修复线

分支	修复版本
10.6	10.6.28 及以上
10.11（LTS）	10.11.19 及以上
11.4	11.4.13 及以上
11.8（LTS）	11.8.9 及以上
12.3	12.3.3 及以上
13.0	13.0.2 及以上

查版本一条命令：

1	SELECT VERSION();

注意：这次是 6 个分支同步发修复版，说明漏洞在代码主干里躺了很久，各分支 cherry-pick 回去。你的版本只要低于上表对应分支的修复线，就是受影响的。目前没有公开利用代码，也还没进 CISA KEV——但 Atlassian 那个 CVE 的剧本上周刚演过：PoC 公开 2 小时内就有野外扫描。补丁窗口按天算都嫌多。

DBA 两步自查

MariaDB 高危自查两步：查版本对修复线，查 CONNECT 引擎、FILE 权限、secure_file_priv

第一步：查版本，对修复线。

1	SELECT VERSION();

低于上表的，排升级窗口。10.11 和 11.8 是 LTS，大部分生产都在这两条线上，优先处理。

第二步：查风险面，三条 SQL。

-- 1. CONNECT 引擎开着吗（CVE-2026-107815 的影响面）
SELECT ENGINE, SUPPORT FROM information_schema.ENGINES WHERE ENGINE = 'CONNECT';

-- 2. 哪些账号有 FILE 权限（CVE-2026-107818 的利用前提）
SELECT GRANTEE FROM information_schema.USER_PRIVILEGES
WHERE PRIVILEGE_TYPE = 'FILE';

-- 3. secure_file_priv 是不是空的（空 = 任意目录可写，CVE-2026-107818 的另一半前提）
SHOW VARIABLES LIKE 'secure_file_priv';

第 2 条要是拉出一堆应用账号，第 3 条要是空值——先别急着升级，把这两项收紧本身就是止血：FILE 权限按最小化回收，secure_file_priv 指到一个专用目录。来不及升级的，CONNECT 引擎不用的可以直接卸载插件：

1	UNINSTALL SONAME 'ha_connect';

重启服务前，顺手看一眼 /run/mysqld/ 底下有没有多出 wsrep-new-cluster 这种不该存在的文件。

写在最后

10 月的数据库安全月才过半：GitLab 路径遍历、Redis RediShell，现在 MariaDB 一天四个 CVE。剧本高度一致——冷门组件 + 老配置项 = 高危利用链。CONNECT 引擎这种”装了就没人看”的东西，和 FILE 权限这种”给了就没人收”的东西，凑在一起就是 8.5 分。

DBCheck 这边，MySQL 巡检引擎的逻辑直接适用 MariaDB：版本低于修复线直接告警，FILE 权限泛滥、secure_file_priv 为空、冷门插件启用这些危险配置一次扫出来，附可执行 SQL。老规矩，dbcheck.org，上传采集包就能拿完整报告，免费。

原文作者: liups.com

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

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

文章目录