FalkorDB 是一个把图数据库做成 Redis 模块的项目常被用在 AI 推理管线、图分析和研究环境里。这一周它集中披露了一组漏洞其中两个比较重。一、漏洞清单编号评分内容CVE-2026-107910CVSS 8.1厂商标 9.2Bolt 端点的is_authenticated函数在 Redis瞬时错误状态下被绕过CVE-2026-7826CVSS 9.1厂商标 8.8序列化 I/O 缓冲区堆越界读经由 Redis 复制触发CVE-2026-107908—需一并升级CVE-2026-5759—修复版本 4.18.1CVE-2026-7827—修复版本 4.18.4第一个的触发条件值得单独看一眼认证绕过发生在 Redis 处于LOADING、MASTERDOWN、OOM这三种瞬时状态之一时。这三种状态下 Redis 会拒绝或降级部分操作而鉴权函数在这种「非常规状态」下给出了错误的返回值。这类漏洞的形态是在系统状态异常时安全检查也一起失效了。而系统处于异常状态恰恰是最需要安全检查的时候。二、共同点断言在发布构建里不存在这批 CVE 在公开分析里被归到同一个根因上debug-only 的ASSERT()边界检查在 release 构建中被剥离也就是说开发环境里存在的保护在生产环境里不存在。这是 C 系语言项目里一个长期存在的结构性差异。assert()的语义是「开发期检查发布期关闭」——它被设计成可以在编译时整体拿掉因为发布版本要以性能为先。所以在开发环境里一个越界写入会立刻触发断言、崩在当场在发布版本里同一个越界写入会静默地写坏内存。对漏洞而言这意味着开发环境测不出来的问题生产环境未必没有——因为检查根本没编进去崩溃反而是好事。带断言的构建崩了说明断言抓到了不带断言的构建不崩说明它已经越界了。第三个 CVE 的攻击路径也值得记一笔经由未认证的 Redis 复制触发。而公开分析里同时提到一个现实情况——很多 Redis 部署默认不开认证。两件事叠在一起不需要凭据就能连上连上就能触发那条带堆越界的代码路径。三、面对这类组件加固清单要改一改常规的中间件加固顺序是「升版本 → 改配置 → 加网络隔离」。对这批漏洞这个顺序不够因为版本号不能完全代表保护强度升级是按版本做的不是按感觉做的。这批漏洞分布在 4.18.1、4.18.4、4.20.0 三个修复版本上要对着自己的实际版本逐个核不能只升到「最新的」认证必须真的开。复制路径是攻击面未认证的复制等于把入口敞开确认生产构建的编译选项。如果一个组件的保护依赖断言那么在 release 构建里它就是不存在的——这需要看构建配置而不是看文档区分「服务能连」和「服务能连什么」。网络可达性控制谁能连到端口与协议层鉴权是两道独立防线缺一道时另一道必须更严。最后一条在信创环境里更具体国产化环境的部署形态往往更集中中间件与缓存组件在同一个网络域里的情况并不少见。金蝶天燕 Apusic 分布式缓存 AMDC 完全兼容 Redis 协议、业务应用无需改造即可接入同时在鉴权侧提供 SM2 密钥认证、ACL 细粒度权限控制与 IP 白名单传输层支持 TLS/SSL 与国密算法——在兼容一个开源生态的同时把认证与权限控制做成默认开启的能力是这类替换场景里最容易被漏掉的一环。很多替换项目做了协议兼容验证、做了性能压测唯独没验证「不开认证时它会不会被连上」。四、结论三条要点根因是构建差异不是编码疏忽。检查存在于调试构建、不存在于发布构建这是语言与构建体系决定的结构性问题异常状态下失效的安全检查最难发现。触发条件是 LOADING/MASTERDOWN/OOM这些都发生在最不该出问题的时刻判断加固是否到位要问四件事版本对不对、认证开没开、构建选项是什么、网络能不能连上。边界本文漏洞信息取自公开周报汇总评分同时给出了 NVD 与厂商两个值两者不一致已在表中标出最终以官方公告为准FalkorDB 官方对本批漏洞的技术说明细节本文未获取。所引攻击路径与默认配置情况来自同一来源未经本地复现。你们线上跑的中间件与缓存组件认证是默认开着的还是等评审时才补的如果不看文档、只看构建配置你能确认生产版本里的边界检查是什么样的吗