11 月 5 日，MariaDB 公开了 CVE-2026-102523，CVSS 3.1 8.0 分：ALTER TABLE ... CONVERT ... PARTITION 在拼文件路径时，没有对分区名做文件名编码。一个带连字符的分区名，就能让转换操作落到调用者无权访问的表文件上，已认证的普通用户借此越权读、改别人的表。

MariaDB CVE-2026-102523，CVSS 8.0 分区转换授权绕过：升到 10.11.19 / 11.4.13 / 11.8.9 / 12.3.3 / 13.0.2

洞在哪：分区名直接进了文件路径

MariaDB 把分区表按分区名存成对应的文件，文件名里不能直接放的字符（比如连字符 -）本应先过 tablename_to_filename 编码再拼路径。这条 CONVERT ... PARTITION 的转换路径偏偏没编：用户给的分区名原样拼进文件路径，转换操作就落到了别的表文件上。

根因是编码这一步漏了，不是权限检查漏了。修复版在 create_partition_name 里把 translate 置为 true，强制走编码，路径就拼不歪了。对应上游编号 MDEV-40413，通告 GHSA-h4vr-wpff-jfx4，弱点分类 CWE-73（对文件名或路径的外部控制）。

影响范围：先查这两件事

受影响的版本：10.11.1–10.11.18、11.4.1–11.4.12、11.8.1–11.8.8、12.3.1–12.3.2、13.0.1；修复版按分支是 10.11.19、11.4.13、11.8.9、12.3.3、13.0.2。10.6 分支不在这条的影响名单里。

DBA 先查两件事：SELECT VERSION() 看分支和版本；在 information_schema.PARTITIONS 里看有没有分区表在用。利用需要三个条件凑齐：已认证、有 ALTER 权限、目标库在做分区转换。权限收得紧的库，这条够不着；把 ALTER 随便给业务账号的库，就在射程里。

和 10 月那批的关系

修复版和 10 月那批 MariaDB 高危（CVE-2026-107815 等，专栏 10 月 15 日写过）是同一批版本号。10 月按那篇升过级的，已经顺带修了这条；还停留在受影响版本的，这条是新的升级理由。

利用现状：条件苛刻，但权限一松就够得着

截至 11 月 9 日核查：无公开 PoC、未列入 CISA KEV、EPSS 0.56%；CISA SSVC 评估：未见利用、不可自动化、技术影响为 total。条件比 Babelfish 那条苛刻得多——要 ALTER 权限，还要走到分区转换这一步。但反过来想：权限模型一旦放得宽，触发它的就是一个普通业务账号，不需要什么高权限。

该干什么，照着做

  1. 按分支升级到修复版：10.11.19 / 11.4.13 / 11.8.9 / 12.3.3 / 13.0.2
  2. 升不上去的，先收 ALTER 权限：REVOKE ALTER ON <库>.* FROM '<用户>'@'<主机>';，只留给真正要做表结构变更的账号；同时把 MariaDB 的网络访问收到可信主机
  3. 实在要禁分区功能才用 --skip-plugin-partition 启动——先确认业务有没有分区表在用，别直接禁
  4. 自查：SELECT VERSION() 确认版本，再查 information_schema.PARTITIONS 确认分区表情况

分数口径

标题的 8.0 分是 CVSS 3.1，GitHub 作为 CNA 给出的评分，向量 CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H；NVD 尚未给出自己的评估。

原文作者: liups.com

原文链接: https://liups.com/posts/c93790c5/

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