Spring AI 三版本齐发：安全漏洞修复与向量存储关键 Bug 修正

预计阅读时间：8 分钟

Spring AI 同时放出了 1.0.8、1.1.7 和 2.0.0-M7 三个版本，覆盖了维护线、稳定线和前沿里程碑线。这次更新不只是例行修修补补——1.1.7 和 2.0.0-M7 修补了一个编号为 CVE-2026-41863 的安全漏洞，而 1.0.8 则修复了一个让人头疼的数据丢失问题：RedisVectorStore#doDelete 在静默删除时只保留了前 10 条消息（issue #6068）。如果你的项目用到了 Redis 向量存储或者还在跑旧版 Spring AI，这轮更新值得立刻关注。

CVE-2026-41863：安全修复覆盖两条版本线

CVE-2026-41863 的修复出现在 1.1.7 和 2.0.0-M7 中，1.0.8 并未包含。这意味着：

跑 1.1.x 稳定线的项目，升级到 1.1.7 即可拿到补丁。
跑 2.0 里程碑的早期采用者，需要切到 2.0.0-M7。
仍在 1.0.x 的项目，如果受该 CVE 影响，应评估是否需要升级到 1.1.7——1.0 线本身不再接收此修复。

具体 CVE 细节在公告中未完全展开，但从版本覆盖范围看，这大概率涉及模型调用、提示词处理或传输层中的注入/泄露风险。对于面向公网暴露 AI 端点的服务，建议不要拖延升级。

RedisVectorStore 的"静默丢失"Bug

issue #6068 描述的问题非常具体：RedisVectorStore#doDelete 在执行静默删除操作时，只保留了前 10 条消息，超出部分被丢弃。

这意味着什么？如果你的应用使用 Redis 作为向量存储后端，并且依赖删除操作来清理过期或无效的嵌入数据，那么在旧版本中，超过 10 条的批量删除实际上会丢失数据——而且这个过程是"静默"的，不会抛异常，不会打警告日志。数据悄悄没了，排查起来极其困难。

1.0.8 修复了这个问题，确保删除操作正确处理全部记录，而不是截断到前 10 条。

升级实操：从依赖变更到验证

下面是一个完整的升级和验证流程，以 1.1.6 → 1.1.7 为例（1.0.x 升级同理）。

第一步：更新依赖版本

Maven 项目修改 pom.xml：

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.ai</groupId>
            <artifactId>spring-ai-bom</artifactId>
            <version>1.1.7</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

<!-- 具体依赖无需改版本号，BOM 统管 -->
<dependencies>
    <dependency>
        <groupId>org.springframework.ai</groupId>
        <artifactId>spring-ai-redis-store-spring-boot-starter</artifactId>
    </dependency>
    <dependency>
        <groupId>org.springframework.ai</groupId>
        <artifactId>spring-ai-openai-spring-boot-starter</artifactId>
    </dependency>
</dependencies>

Gradle 项目在 build.gradle 中：

dependencies {
    implementation platform("org.springframework.ai:spring-ai-bom:1.1.7")
    implementation 'org.springframework.ai:spring-ai-redis-store-spring-boot-starter'
    implementation 'org.springframework.ai:spring-ai-openai-spring-boot-starter'
}

第二步：验证 RedisVectorStore 删除行为

升级后，写一个简单测试确认删除不再截断：

import org.junit.jupiter.api.Test;
import org.springframework.ai.vectorstore.RedisVectorStore;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.context.SpringBootTest;

import java.util.List;
import java.util.stream.IntStream;

@SpringBootTest
class RedisVectorStoreDeleteTest {

    @Autowired
    private RedisVectorStore vectorStore;

    @Test
    void batchDeleteShouldHandleAllRecords() {
        // 先插入 20 条文档，确保超过旧版 10 条截断阈值
        List<String> docIds = IntStream.range(0, 20)
                .mapToObj(i -> "test-doc-" + i)
                .toList();

        // 执行删除（具体 API 以你所用版本为准）
        vectorStore.delete(docIds);

        // 验证：逐条查询，确认全部已删除而非只删了前 10 条
        for (String id : docIds) {
            // 如果旧版 Bug 仍存在，id 从 test-doc-10 开始会仍然存在于 Redis
            // 修复后应全部清除
            assertDocumentNotFound(id);
        }
    }

    private void assertDocumentNotFound(String id) {
        // 根据你的 Redis 查询方式实现，例如通过 key 直接检查
        // 伪代码示意，实际用 RedisTemplate 或 vectorStore.search()
        boolean exists = checkKeyExists("spring-ai:document:" + id);
        assert !exists : "文档 " + id + " 删除后仍存在，Bug 未修复";
    }
}

注意：RedisVectorStore 的 delete 方法签名在不同小版本间可能有差异，请对照你所用版本的 API 文档调整调用方式。上面的测试逻辑是验证思路，checkKeyExists 需根据实际 Redis key 命名规则实现。

第三步：安全漏洞快速自查

如果你有对外暴露的 AI 接口，升级后做一次基础安全检查：

# 检查当前依赖是否已包含修复版本
mvn dependency:tree | grep spring-ai

# 或 Gradle
gradle dependencies | grep spring-ai

# 确认 BOM 版本号是 1.1.7+ 或 2.0.0-M7+
# 如果仍看到 1.1.6 / 1.0.7，说明依赖没生效，检查是否被其他 BOM 覆盖

版本选择建议

场景	推荐版本	原因
生产环境，已用 1.1.x	1.1.7	稳定线 + CVE 修复
生产环境，已用 1.0.x	1.1.7	1.0 线不再收 CVE 补丁，建议跳到 1.1
试用新特性 / MCP / Agentic	2.0.0-M7	里程碑线含 CVE 修复，但 API 不稳定
仅受 Redis 删除 Bug 影响，不涉及 CVE	1.0.8	最小改动，只修数据问题

几个需要留意的点：

不要停留在 1.0.7 及更早版本——Redis 删除 Bug 会悄悄丢数据，而且这条线不会再收安全补丁。
2.0.0-M7 是里程碑版，API 随后续里程碑可能变动，生产环境慎用，但如果你在做 Agent/MCP 相关的预研，这个版本值得跟进。
升级后跑一遍向量存储的批量操作测试，尤其是删除和更新，确认数据完整性没有异常。

三个版本同时发布，说明 Spring AI 团队在并行维护多条线。对于使用者来说，选对版本线、及时打上安全补丁、验证向量存储的关键操作——这三件事做完，就可以安心继续往下走了。