How the attack works
An application uses Spring AI's ChatMemory feature to give the AI model context from earlier turns in a conversation. If the advisor doesn't enforce a unique conversation_id per session, two unrelated requests can end up sharing the same memory bucket. Memory written by User A during their session is then retrieved and silently injected into User B's prompt as though it were B's own history. The model processes A's private content on B's behalf, and B may see or receive responses shaped by A's data without either user knowing it happened.
Why it matters
Private conversation content, prior queries, and tool outputs from one user can be exposed to a different, unrelated user, which is a direct confidentiality breach and a compliance problem for any application handling sensitive or regulated user data.
What you can do
- Upgrade to Spring AI 1.0.0 or later, which fixes this issue.
- Confirm every request to a ChatMemory-backed advisor carries a unique, correctly scoped conversation_id and that it's enforced server-side, not just client-supplied.
- Audit memory-fetch logs for cases where the retrieved user-id or conversation-id doesn't match the active session.
- Review stored chat memory for any cross-session mixing, especially in multi-tenant or high-concurrency deployments.
Known benign look-alikes
- Legitimate documentation or changelog text discussing CVE-2026-41712 patch notes.
- Static analysis tooling output documenting cross-user memory leakage patterns for defensive purposes.
- Patched Spring AI PromptChatMemoryAdvisor deployments that enforce per-conversation_id partitioning.
- Multi-tenant test fixtures that intentionally include foreign conversation IDs for QA purposes.