Spring AI CVE-2026-59318: models could dispatch an unadvertised tool

On 22 August, CVE-2026-59318 received another metadata update after Spring published its official advisory on 20 August and the CVE record appeared a day later. The vulnerability affects tool calling in Spring AI. A function list supplied for one request was presented to the model as a boundary, but under certain conditions the execution layer could resolve a tool through a global resolver and invoke it even though that tool was absent from the current request.

The distinction matters. A model does not acquire a new Java function or break the language runtime. It receives or produces a call name, and the framework decides whether that name resolves to code. If dispatch uses a broader registry than the capability set advertised to the model, capability presentation is no longer an enforced policy. Prompt injection can turn the difference between those sets into privilege escalation.

Scope and fixed releases

Spring lists 2.0.0, 1.1.0 through 1.1.8, and 1.0.0 through 1.0.9 as affected. The open-source fix is 2.0.1. Enterprise Support customers have 2.0.0.1, 1.1.9, and 1.0.10 for the corresponding lines. The advisory rates the issue medium. Its CVSS 3.1 score is 6.5, with a vector that assumes network access, high complexity, low privileges and user interaction.

Do not copy the base score into a risk register without context. A function that reads a public catalogue and one that approves a payment create radically different business impact. The practical questions are which callbacks exist in the global registry, what credentials they possess, whether they mutate state and whether a control outside the model approves the action.

Merely finding Spring AI in a dependency tree does not prove reachability. Confirm tool calling and DefaultToolCallingManager are used, examine resolver registration, and determine whether the application changes the function set per user, tenant, agent or workflow stage. If every request always receives the same set, the dangerous difference may not arise, but upgrading still removes an unsafe assumption.

Two decisions that must agree

An agentic system makes at least two decisions. It first constructs the tool description sent to the model: names, parameters and purpose. It later receives a generated call and maps its name to executable code. A safe design requires the second step to accept only a function from the immutable set approved for that same request.

A global resolver is convenient because it simplifies bean registration and reuse. It must not become an authorisation fallback. It is an implementation catalogue, not evidence that a caller may execute an item. The conventional API equivalent is hiding a button in the interface while the backend still accepts a direct request. AI adds an important twist: an untrusted document can suggest the hidden function name to a model.

Deterministic application code must calculate the boundary from the user identity, tenant, operation purpose and current workflow state. The model may propose an action; it must not decide its own authority. A tool name is untrusted input just like an HTTP parameter.

How prompt injection reaches the semantic gap

The advisory identifies prompt injection as a path to unadvertised dispatch. An instruction may arrive through a RAG document, a web page retrieved by an agent, a customer ticket or a database field. It does not need to alter application configuration. It only needs to induce a correctly formed name that the global resolver recognises but the request should not expose.

Not every attempt causes damage. Dispatch may reject the name, the callback may perform independent authorisation, or a human approval gate may stop the operation. CVE-2026-59318 nevertheless shows why omission from a prompt cannot be treated as sufficient access control. A prompt informs a model; it is not the server’s ACL.

Inventorying exposure

Build a table of every callback reachable through the resolver. Record its owner, registration source, required roles, tenant scope, credentials, egress, side effects and reversal method. Compare that table with the sets sent by each application path. Functions present globally but deliberately removed from some requests deserve priority.

Inspect the final artifact rather than only the build declaration. A BOM, dependency management, private starter or cached container layer can retain an affected release. In a multi-module estate, confirm the runtime version and origin of every framework instance.

Review callbacks for defence in depth. A delete function should re-check the principal’s permission for the specific object. An argument containing tenantId must not establish tenant context by itself. Service credentials need narrow scope so a dispatch mistake does not automatically grant administration of the whole environment.

Upgrade and regression test

Move to the corresponding fixed release, create a fresh artifact, inspect the lockfile or dependency tree and use a canary rollout. Tests should cover valid calls, a missing tool, an unknown name, request retry, parallel tenants and a capability-set change between conversation stages.

A negative test can register a harmless test callback globally, omit it from one request and confirm dispatch rejects it before execution. Do not use a production function with real side effects. Logs should retain a clear denial reason, policy identifier and request identifier without recording a full prompt or secret arguments.

If an immediate upgrade is impossible, remove unnecessary global tools from the process, separate agents with different trust levels into distinct services and enforce authorisation inside every callback. Human approval reduces the effect of high-risk operations but does not repair resolution. Prompt filtering is not a durable mitigation either.

Detection and response

Record advertisedToolIds, the selected function, authorisation outcome, principal, tenant, model, context sources and operation result. Tokenise or redact sensitive arguments. Alert whenever a selected name is absent from the advertised set, even if the fixed framework rejects it. That event is useful prompt-injection and integration-error telemetry.

In historical logs, look for tool calls inconsistent with the agent type or workflow stage, particularly administrative actions after external content was processed. An inconsistency alone does not prove exploitation: a set may have changed legitimately and existing logs may not preserve the request snapshot. Correlate it with the runtime version, configuration and target-system effect.

If unauthorised execution is confirmed, stop the affected workflow, preserve evidence, assess the tool’s downstream system and revoke only credentials that were actually exposed. Updating the framework closes the dispatch path but does not undo previous state changes.

Vendor facts and Breachroad conclusions

Affected versions, the global resolver fallback, unadvertised dispatch, CVSS vector and fixed releases come from Spring’s advisory. It does not report active exploitation. The 22 August date refers to today’s update of the public vulnerability record; Spring first published on 20 August.

Immutable capability snapshots, callback-level authorisation, service separation, telemetry and response guidance are Breachroad conclusions. Secure AI implementation training helps teams separate a model’s decision from executable authority, while an AI security assessment can trace resolvers, callbacks, identities, credentials and egress.

Sources

• Spring — CVE-2026-59318: unadvertised tool dispatch
• NVD — CVE-2026-59318
• Spring AI — tool calling documentation