/

CVE-2026-18394

Severity:

HIGH RISK

(7.4)

Authorization Bypass (CWE-863) in Strands HTTP Tool

CVE-2026-18394

Awaiting Analysis

Vulnerability type

Category:

Incorrect Authorization

CWE:

CWE-863

Impact:

Credential Exposure and Unauthorized Access

Severity:

HIGH RISK

(7.4)

CVSS version:

3.1

Catch this CVE while code is being written

Detect vulnerable code directly in pull requests, so CVEs are fixed before merge.

Summary

An incorrect authorization implementation in the http_request tool of Strands Agents Tools allows LLM-influenced requests to leak credentials stored in HTTP_REQUEST_TOKEN_CONFIG.

If an attacker can steer the LLM to route traffic through an attacker-controlled proxy, they may capture these credentials and reuse them against downstream services.

Affected context

This vulnerability affects deployments using Strands Agents Tools' http_request capability where:

  • The HTTP_REQUEST_TOKEN_CONFIG is populated with access tokens or credentials
  • LLM-driven agents are allowed to dynamically select endpoints or proxies
  • Outbound HTTP traffic can be directed to infrastructure not strictly controlled by the organization

In such setups, an attacker who can influence prompts, tools, or conversation flow may coerce the LLM into routing authenticated requests through malicious proxies.

Exploit preconditions

  • Attack surface: LLM agent workflows that use the http_request tool
  • Required access: Ability to influence the LLM's decisions (e.g., prompt injection, compromised upstream content, or control of task descriptions)
  • Trigger point: The LLM is persuaded to configure or use an attacker-controlled proxy or endpoint when making authenticated HTTP requests
  • Why exploitation is possible: The http_request tool applies credentials from HTTP_REQUEST_TOKEN_CONFIG without enforcing strong destination or trust constraints, allowing authenticated requests to be sent to untrusted infrastructure

Why this happens

The root cause is an authorization design flaw where credentials stored in HTTP_REQUEST_TOKEN_CONFIG are applied to requests without adequately verifying that the destination is authorized or trusted.

This maps to CWE-863: Incorrect Authorization, as the system fails to distinguish between legitimate upstream services and arbitrary endpoints negotiated by an LLM.

By delegating routing decisions to an AI agent without constrained policies or proper binding of credentials to specific audiences, the tool effectively extends privileged access to untrusted network paths.

Potential impact

  • Exposure of API tokens, access keys, or session credentials to attacker-controlled proxies
  • Unauthorized use of leaked credentials against backend services or APIs
  • Impersonation of legitimate services or accounts associated with the compromised tokens
  • Lateral movement within cloud or SaaS environments that trust the exposed credentials
  • Loss of confidentiality for data accessed via authenticated HTTP requests

General mitigation guidance

Mitigations focus on constraining where and how credentials can be used and reducing trust in LLM-controlled routing:

  • Bind credentials to explicit, allow-listed domains or services, and refuse to send them to non-approved hosts or proxies
  • Introduce policy checks in the http_request tool to enforce strict destination validation before attaching tokens
  • Separate credentials per service and avoid sharing generic tokens across multiple endpoints or agents
  • Limit LLM autonomy over network configuration (such as proxies or arbitrary URLs) and require human or policy approval for sensitive destinations
  • Apply least-privilege principles to tokens, ensuring they grant only minimal scopes required for the intended tasks

How teams detect issues like this

Detection efforts can focus on both configuration and runtime behavior:

  • Use static or configuration analysis to flag http_request setups where HTTP_REQUEST_TOKEN_CONFIG is not bound to specific domains or where destination checks are absent
  • Review agent and tool code for patterns where LLM output directly influences network routing, proxies, or target URLs without policy enforcement
  • Monitor logs for authenticated requests sent to unexpected domains, IP addresses, or proxy hosts, especially those outside known allow-lists
  • Implement outbound network egress controls and alerts for traffic carrying authentication headers to unrecognized destinations
  • Incorporate automated security review tools into CI pipelines to identify incorrect authorization patterns in agent tools

Sources

SourceLink
aws.amazon.comaws.amazon.com/security/security-bulletins/2026-069-aws/
github.comgithub.com/strands-agents/tools/releases/tag/v0.8.2
github.comgithub.com/strands-agents/tools/security/advisories/GHSA-qhw6-2h72-m84v

Frequently asked

questions

Yes, it can be exploited remotely if an attacker can influence the LLM's behavior, for example through prompt injection, compromised content sources, or malicious instructions that cause the agent to use attacker-controlled proxies.

The attacker does not need direct system access but must be able to shape the LLM's decisions, such as by providing crafted prompts or content that steer the http_request tool to send authenticated traffic through infrastructure they control.

The most robust pattern is to bind credentials to specific, allow-listed destinations and enforce strict authorization checks before attaching tokens, ensuring that authenticated requests cannot be directed to arbitrary endpoints or proxies.

Design LLM-integrated tools with clear trust boundaries: constrain network destinations, separate credentials by service, apply least privilege, and implement policy enforcement layers that validate where tokens can be used rather than relying solely on LLM-driven routing decisions.

Find out what's already
exploitable in your codebase.