CVE-2026-59318

CVE-2026-59318 represents a request isolation failure in Spring AI's tool calling mechanism. The vulnerability is not a bug in how tools are advertised to the model — it's a failure to enforce those boundaries at dispatch time. When you configure ChatOptions with a constrained tool set, that constraint is treated as advisory metadata for prompt construction rather than a runtime authorization gate that the dispatch layer must re-validate before execution. Under certain conditions — most likely involving concurrent requests, state manipulation between advertisement and dispatch, or async tool execution — an unauthorized tool can execute even though it was never included in the request's declared scope. The privilege escalation consequence is the critical interpretation point: a user or system that did not authorize tool X can have tool X execute anyway. In multi-tenant or multi-user deployments, this means one user's authorized tools can leak into another user's request context. The "certain conditions" qualifier is analytically significant — if those conditions are achievable through typical deployment patterns (streaming responses, async execution, request interleaving), then the blast radius extends to every Spring AI application with non-trivial tool sets, not just edge cases with specific concurrency configurations. The CVSS 6.5 appears conservative. Request-isolation failures that cross tenant boundaries are not medium-severity issues by any model that treats tenant isolation as a security control rather than a configuration detail. The more pressing question for defenders is what to do about it. A fix limited to hardening the FunctionCallbackRegistry alone will not be sufficient. The fundamental issue is architectural: Spring AI introduced tool advertising at the prompt layer without updating the execution layer to receive and enforce authorization context. The dispatch path that predates the advertising feature still operates on a reference to a shared tool registry rather than a snapshot of allowed tools for the specific invocation. You need one of two things: either immutable tool lists per request (a defensive copy made at request creation and enforced at dispatch), or mandatory re-verification of tool authorization at the exact point where execution happens. Without making this contract explicit in the framework, future developers will face the same confusion — tool lists appear constrained but neither layer is authoritative. Check your deployment for any use of streaming, async tool execution, or request interleaving. If those patterns exist, treat this vulnerability as higher severity than the CVSS suggests. Review whether your tool registry includes high-privilege operations (database writes, external API calls, microservice orchestration) — if it does, unauthorized invocation is a pivot point into broader system access, not just a framework-level permission violation.

Reviewed through automated stages and approved by a human before publication.