Redis 这几个 RCE 都写着「需要已认证」：把 ACL 当边界，比只绑 127.0.0.1 更接近实际
相关页面：Redis Releases · Redis Security Advisories
8.10.3 / 8.8.4：cluster bus 上的 4GB PUBLISH
2026-10-26 发布的 8.10.3 在发布说明里标了 SECURITY，修复项是：集群模式下通过 cluster bus 传播大于 4GB 的 PUBLISH/SPUBLISH 消息时发生堆缓冲区溢出。8.8.4 包含同一修复。
这和下面几条不同，没有「需要已认证」的前置条件描述，发布说明直接按安全更新处理。集群环境里 cluster bus 的连通性往往比客户端端口更宽松，升级应优先安排。
三个已公开 advisory 的前置条件
- CVE-2026-25243（GHSA-c8h9-259x-jff4）：
RESTORE命令对序列化值的校验不足，构造过的 payload 会触发非法内存访问，可能导致 RCE。影响所有 Redis 版本。前置条件只有一个：攻击者已通过实例认证。 - CVE-2026-23631（GHSA-8ghh-qpmp-7826）：Lua 的 use-after-free，可导致 RCE。利用依赖主从同步机制，且只影响配置了（或可能被配置成）
replica-read-only no的副本；所有带 Lua 脚本的版本都存在。Workaround 是禁止用户执行 Lua，或避免使用关闭只读的副本。由 Yoni Sherez（DarkReplica）在 Wiz Zerothday Cloud 活动报告。 - CVE-2026-23479（GHSA-93m2-935m-8rj3）：阻塞客户端在被驱逐时重新执行阻塞命令，触发 use-after-free，可导致 RCE。Redis 7.2 起存在；代码没有处理
processCommandAndResetClient返回错误值的情况。同样需要已认证用户。
三条放在一起看，前缀几乎一样：已认证。网络层绑定、安全组、只监听 127.0.0.1，解决的只是「谁能连上」。应用侧一旦出现 SSRF、弱口令、或者一个多业务共享的 Redis 实例，攻击者拿到的就是这张「已认证」的票。RESTORE、EVAL、EVALSHA、FUNCTION 这些能力，只要账号能调，边界就已经在账号这一层被突破了。
用 ACL 把「已认证」拆细
ACL 能按账号区分权限、限制命令类别、限制 key 模式，这比全局 rename-command 更贴近实际边界。给业务账号的最小集合：
ACL SETUSER app on >pass ~prefix:* +@read +@write -@dangerous -restore -eval -evalsha -function -script
~prefix:*限定 key 空间，避免一个账号读写全库。-@dangerous去掉危险命令类别，再显式关掉RESTORE、Lua 执行入口和FUNCTION，对应上面三条 advisory 的触发面。SCRIPT是容器命令，-script连同子命令一起关；实际拦截 Lua 执行还要靠-eval -evalsha。
拒绝记录要能看见，否则 ACL 只是写在配置里：
ACL LOG 20 # 查看最近被拒的命令、原因（command/key/channel）与来源
ACL LOG RESET # 清空，便于按时间段观察
定期翻 ACL LOG，能发现扫描式调用 RESTORE、EVAL 的账号，也能反过来验证规则是否误伤了正常业务。
rename-command 仍然可用，但它是全局的、改完要重启、不能按账号区分，还会让依赖该命令的运维脚本一起失效。Redis 7+ 的文档已把它标为不推荐，优先用 ACL。
两条配套项
副本只读：保持 replica-read-only yes。CVE-2026-23631 的利用条件之一就是副本可写，把它关掉直接去掉了这个组合。
PUBLISH/SPUBLISH 的缓冲上限：client-output-buffer-limit pubsub 控制 pubsub 客户端的输出缓冲上限，proto-max-bulk-len 控制单条协议 bulk 的长度（默认 512MB）。4GB 消息要在集群内传播，内存放大路径与这两个参数相关，把 pubsub 输出缓冲压到业务实际需要的量级、不放大 proto-max-bulk-len，会缩小可利用面。这一条是按内存放大路径推断的缓解背景，具体触发条件与修复范围以官方 advisory 为准。
升级到 8.10.3 / 8.8.4 修掉溢出，同时把 ACL 落到账号粒度，才算把「已认证」这张票的权限收窄。