文章总结： MongoDBBIConnectorODBC驱动披露五项漏洞，最严重的CVE-2026-19001评分为9.8。该漏洞因catalog函数处理超长名称时整数溢出导致固定缓冲区越界写入，可实现无认证远程代码执行，影响全平台旧版本但不涉及服务端。建议立即升级驱动至1.4.9，或临时在调用相关函数前严格校验并截断名称长度以降低风险。 综合评分： 88 文章分类： 漏洞预警,漏洞分析,应用安全
【漏洞预警】近期MongoDB 公布了5个漏洞，最严重的一个可以不认证、远程就能拿下你电脑
YGnight YGnight
night安全
2026年8月20日 18:05 四川
在小说阅读器读本章
去阅读
一、漏洞描述
MongoDB BI Connector ODBC Driver 是装在客户端的驱动，让 Tableau、Excel 这类报表工具能直接读 MongoDB 里的数据。2026 年 8 月 12 日，MongoDB 一次性披露该驱动的 5 个漏洞，全部在 v1.4.9 修复。其中 CVE-2026-19001 评分 9.8，是这批里最重的一个。
| CVE 编号 | CVSS 3.1 | CWE | 漏洞简述 | | — | — | — | — | | CVE-2026-18888 | 6.5 中危 | CWE-787 | 浮点数转文本时未检查结果是否超出目标缓冲区，读取大浮点可致越界写入，应用崩溃 | | CVE-2026-19001 | 9.8 严重 | CWE-190 | catalog 函数处理超长 catalog/schema/object 名称时整数溢出，固定缓冲区越界写入，可致任意代码执行 | | CVE-2026-19002 | 8.1 高危 | CWE-120 | 解析存储过程参数元数据时缺少边界检查，需控制或冒充驱动连接的服务端 | | CVE-2026-19003 | 7.8 高危 | CWE-121 | 数据源定义含超长文件路径时，ODBC 设置对话框的文件/文件夹选择处理存在错误的缓冲区容量计算 | | CVE-2026-19004 | 8.1 高危 | CWE-122 | 处理存储过程输出参数时的内存安全问题，需连接到不可信或冒充的数据库服务器 |
CVE-2026-19001 出在驱动的元数据检索函数。应用往 catalog 函数传入超长的库名、表名或列名时，驱动内部的长度计算溢出，固定大小的缓冲区被写穿。这个漏洞远程就能触发，不需要任何登录凭证。
受影响版本
- MongoDB BI Connector ODBC Driver 1.0.0 到 1.4.9 之前所有版本
- Windows、Linux、macOS 三个平台全覆盖
- 任何用这个驱动连 BI Connector、且代码里调了 catalog 函数的应用都在暴露面内
修复版本
- MongoDB BI Connector ODBC Driver 1.4.9 及以上
漏洞爆在客户端驱动进程里，对 MongoDB 服务端本身没有直接影响。普通的 SELECT 查询碰不到这个口子，只有应用调 catalog 函数、且传了超长名称时才会触发。
二、漏洞原理
ODBC 规范里有一类叫 catalog 函数的接口，专门让报表工具去访问数据库。常见的有 SQLTables、SQLColumns、SQLTablePrivileges 这几个。调用的时候需要把库名、表名、列名，连同各自的长度字段一起传进去。长度字段的类型是 SQLSMALLINT，一个 16 位有符号整数，最大只到 32767 。
驱动拿到这些名称后要干几件事：把名称拷进内部缓冲区，在末尾补一个 null 终止符，有时还得拼成查询语句。这些事都离不开长度计算，比如把”名称长度 + 1″当成目标缓冲区的容量。
麻烦就在这个加号上。名称很长、长度值已经快顶到类型上限时，再做一次”长度 + 1″，结果就会溢出，变成负数，或者回绕成一个小得离谱的正数。驱动后面用这个错误的小值去分配和检查缓冲区，可真正拷贝数据时用的却是字符串的真实长度，一个远比缓冲区大的数。拷贝直接越过缓冲区边界，把多出来的字节写进了旁边的内存。
漏洞代码的简化逻辑如下：
// ODBC catalog 函数处理名称参数的典型路径
SQLRETURN handle_catalog_name(SQLCHAR *name, SQLSMALLINT name_len,
catalog_buf_t *out)
{
// name_len 是 SQLSMALLINT (16 位有符号)，范围 [-32768, 32767]
SQLSMALLINT need = name_len + 1; // ← 接近上限时溢出为小值
// 以溢出后的小值校验固定缓冲区
if (need > FIXED_BUF_SIZE) { // FIXED_BUF_SIZE 比如 128
need = FIXED_BUF_SIZE; // 截断逻辑（修复后才补上的 clamp）
}
// 拷贝时用的是真实 name_len，而非溢出后的 need
memcpy(out->fixed_buf, name, name_len); // ← name_len 远大于 buf
out->fixed_buf[name_len] = '\0'; // ← 越界写入 null 终止符
return SQL_SUCCESS;
}
触发的过程是在上层应用调一个 catalog 函数，比如 SQLColumns，往库名参数里塞一个超长字符串，同时把长度字段设到接近 SQLSMALLINT 上限。驱动内部一算长度就溢出，校验逻辑被绕过，拷贝接着把这一长串名称一股脑写进那个固定大小的缓冲区，旁边内存跟着被覆盖。被盖掉的是普通数据就导致应用当场崩溃。如果盖到函数返回地址或者函数指针这种就能改程序走向，攻击者就能把程序引到自己指定的地址去跑代码。
三、修复建议
- 升级到 1.4.9
- 暂时升不了的可以调 catalog 函数之前先校验库名、表名、列名的长度，超长直接截掉
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：night安全 YGnight YGnight《【漏洞预警】近期MongoDB 公布了5个漏洞，最严重的一个可以不认证、远程就能拿下你电脑》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论