Redis 8.10.2 安全修复：cluster bus 认证与事务 ACL 撤销
Redis 8.10.2 于 2026-09-17 发布，属于 8.10 线（8.10.1/8.10.0 同线）。这次安全修复里，两个点需要单独拿出来看：cluster bus 的自身认证，以及事务队列对 ACL 撤销的绕过。同批补丁还覆盖 8.2 到 8.10 各支持线，版本对应关系见文末。参考发布说明：00-RELEASENOTES。
cluster bus：未启用 tls-cluster 时没有自身认证
问题编号 #15722。cluster bus 协议在未启用 tls-cluster 时没有自身认证。只要某个 host 能到达节点的 bus 端口，就可能加入集群并威胁该节点。这里说的是节点之间通信的 bus 端口，不是客户端端口。
现在集群节点在 bus 端口未认证时会在启动阶段告警。新增配置项 cluster-bus-port-protected-mode，默认 no。当设置为 yes 时，节点只有在 tls-cluster 认证 bus 时才会启动，否则拒绝运行。
配置片段：
# 启用集群 TLS，并对 bus 端口做保护
tls-cluster yes
cluster-bus-port-protected-mode yes
如果暂时无法启用 tls-cluster，不要直接把 cluster-bus-port-protected-mode 改成 yes，否则节点会因为 bus 未认证而拒绝启动。此时至少要把 bus 端口限制在可信网络内：安全组、防火墙、iptables/nftables 只允许集群节点互访。bus 端口通常由 cluster-port 决定，默认是客户端端口 + 10000；以实际配置为准。启动时留意新增告警，它表示当前 bus 端口对可达 host 没有认证。
事务中排队的命令与 ACL 撤销
问题编号 #15673。事务中排队的命令仍能访问在事务执行前 ACL 权限已被撤销的 key。也就是说，在 MULTI 之后、EXEC 之前，如果通过 ACL 撤销了某个 key 的访问权限，已经排队的命令仍可能按旧权限执行。
修复后，这类命令会受到执行时 ACL 状态约束。升级后需要检查依赖“先排队、后撤权”逻辑的应用：如果业务在事务期间动态调整 ACL，并期望已排队命令继续执行，行为会变化。应用需要处理权限错误，而不是假设 EXEC 一定成功。
事务示意：
MULTI
GET revoked:key
# 此时通过 ACL SETUSER 撤销 revoked:key 权限
EXEC
同批修复与版本对应
同一批安全补丁还包含：
- TimeSeries：从格式错误的 RDB payload 恢复的压缩时间序列 key，再添加样本时不再导致服务器崩溃。
- RedisSearch：向量字段名很长的索引上 KNN 查询曾导致崩溃。
- Vector Sets：深度嵌套 JSON 用于 Vector Set 查询曾导致服务器崩溃。
覆盖范围：8.10.2、8.8.3、8.6.7、8.4.7 含全套修复；8.2.10 不含事务 ACL 撤销修复。
升级建议
- 确认当前 Redis 版本与支持线。若使用 8.10 线，升级到 8.10.2；其他线按 8.8.3、8.6.7、8.4.7 对应升级。
- 如果在意 #15673 的事务 ACL 撤销问题，不要停在 8.2.10，因为它不包含该修复。
- 升级后检查集群节点启动日志，确认是否出现 bus 端口未认证告警。
- 计划启用
cluster-bus-port-protected-mode yes前，先完成tls-cluster配置与证书轮换，再逐节点重启验证。不要跳过tls-cluster直接设yes。 - 暂未启用集群 TLS 的环境，把 bus 端口限制在可信网络，并避免把节点 bus 端口暴露到不可信网段。
- 对使用
MULTI/EXEC且动态调整 ACL 的业务做回归，确认权限撤销后排队命令按预期失败。
参考发布说明：https://raw.githubusercontent.com/redis/redis/8.10/00-RELEASENOTES