Strands Agents Memory Tool Let Prompts Redirect an Elasticsearch API Key — CVE-2026-15746
AWS has disclosed a credential-exfiltration flaw in the elasticsearch_memory tool shipped with Strands Agents Tools. In versions before 0.7.0, the tool exposed its Elasticsearch URL, cloud identifier, and API-key parameters in the schema available to the large language model. A crafted prompt could make the agent select an attacker-controlled Elasticsearch host while omitting the key argument, causing the tool to fall back to the operator's ELASTICSEARCH_API_KEY environment variable and send that secret in the outbound authorization header.
The issue is tracked as CVE-2026-15746 and AWS bulletin 2026-056-AWS, published July 15. AWS scores it Medium: CVSS 4.0 6.9 and CVSS 3.1 6.5, with active user interaction required and high confidentiality impact. The advisory nevertheless recommends that every operator rotate the Elasticsearch API key as a precaution, even without evidence of exposure.
The model could choose the destination, but the process supplied the secret
The vulnerable design combined two individually convenient behaviors. First, es_url, cloud_id, and api_key were arguments to the decorated tool function, which placed them inside the model-visible tool contract. Second, if the model did not provide a value, the implementation loaded the corresponding environment variable. That fallback turned operator configuration into implicit authority available to any invocation.
An attacker did not need the model to reveal the key as text. The prompt only needed to steer the tool toward a hostile es_url while leaving api_key unset. The Elasticsearch client then performed the disclosure itself by authenticating to the model-selected host. AWS classifies the weakness as server-side request forgery, but the most important operational consequence is destination-confused credential use: untrusted reasoning chose where a trusted process presented a bearer-equivalent secret.
This pattern is more dangerous than a conventional hallucinated parameter. Tool arguments are not merely generated text; they cross into executable control flow. When a parameter selects a network endpoint and a separate fallback supplies credentials, the schema silently grants the model a capability to pair trusted secrets with untrusted destinations.
Version 0.7.0 removes connection authority from the tool schema
The fix, merged in Strands Agents Tools pull request 477, removes es_url, cloud_id, and api_key from the elasticsearch_memory function signature. Version 0.7.0 reads all three connection settings only from ELASTICSEARCH_URL, ELASTICSEARCH_CLOUD_ID, and ELASTICSEARCH_API_KEY. A regression test asserts that none of the credential or connection parameters remains in the callable signature.
This is a breaking but structurally sound change. Applications that passed those values directly as keyword arguments must migrate them to environment configuration. More importantly, the LLM can still choose memory operations, content, indexes, namespaces, and retrieval parameters without being allowed to redirect the underlying authenticated client. The patch narrows model agency at the correct boundary instead of attempting to teach the model which hosts are safe.
The chronology also matters for asset inventories. The project released the fixed 0.7.0 package on May 29, weeks before the July advisory. A deployment can therefore already be safe even if its operators never saw a security-labelled release note, while an older pinned image can remain vulnerable despite appearing stable.
Environment variables are not a security boundary
Moving connection settings out of the tool signature prevents this specific model-controlled redirect, but environment storage alone does not make a credential safe. Any code running in the same process can potentially read that environment, and an agent with arbitrary code execution or broad shell tools may still reach it. The durable control is to ensure that the component which uses a secret has a fixed, independently enforced audience.
The failure resembles the site's recent analysis of the AWS HealthLake MCP pagination SSRF: a data-looking field gained authority over the destination of an authenticated request. It also reinforces the case for secret-use delegation, where an agent receives permission for a narrowly defined operation rather than possession of a reusable credential.
Defensive engineering guidance
- Upgrade to strands-agents-tools 0.7.0 or later. Verify the version inside the actual agent environment, rebuild pinned containers and lockfiles, and restart persistent workers after deployment.
- Rotate
ELASTICSEARCH_API_KEY. AWS recommends rotation for all operators as a precaution. Replace the key in every runtime and secret store, then revoke the old credential rather than leaving both active. - Audit for hostile destinations. Review DNS, proxy, firewall, and Elasticsearch client telemetry from affected agent hosts. Look for outbound connections to endpoints other than the approved cluster, especially following untrusted prompt or memory content.
- Stop using the tool if patching is delayed. AWS's stated workaround is to avoid
elasticsearch_memory. If continued use is unavoidable, do not expose the API-key environment variable to the tool and restrict egress to the trusted Elasticsearch endpoint. - Inventory model-visible schemas. Flag tool fields named like URLs, hosts, credentials, tokens, commands, paths, or cloud identifiers. Check whether omitted fields inherit privileged environment or configuration values.
- Bind credentials to destinations outside the model. Prefer a preconfigured client, broker, or egress proxy that fixes the protocol and host. Do not let generated arguments choose both an operation's authority and its audience.
- Use least-privilege Elasticsearch keys. Restrict the key to required indexes and actions, separate read from write identities where practical, and monitor its use from new source networks.
CVE-2026-15746 captures a recurring agent-security design error: a model-controlled field becomes dangerous when trusted runtime state fills in everything the model leaves blank. Defenders should review tool schemas as capability interfaces, not documentation. If an argument can redirect a credential-bearing client, it belongs in trusted configuration—not in the language model's action space.
Sources: