Submission File: ES2608-94e48d11-new-credential-destination-injection.txt
ID: ES2608-94e48d11
SUBMISSION DATE: 2026-08-20 21:39:22
NAME: Credential Destination Injection
DESCRIPTION:
The product attaches a credential it holds (an API key, access token, or
database credential) to an outbound request or connection whose destination
is determined, wholly or partly, by externally influenced input, without
validating that destination against a trusted allowlist before the
credential is attached.
A product that acts on behalf of a user frequently holds a credential. When
such a product exposes an interface that lets an external party influence
the destination of an outbound request, and the credential is attached
before the destination is validated, the product delivers its own
credential to a destination chosen by that party. The credential is not
exfiltrated through a memory or storage weakness; it is transmitted
voluntarily, over a properly secured channel, to an untrusted endpoint,
because the destination was treated as data rather than as a security
decision.
This weakness is characteristic of tool-invocation layers in AI agent
systems, where the values passed to a tool are selected by a language model
that processes untrusted content as a matter of course. External influence
over a tool argument is the normal operating condition rather than an
exceptional one.
Distinction from CWE-918 (SSRF): CWE-918 concerns reaching an unintended
destination and does not require the product to hold a credential. This
weakness's harm is that the product's own credential accompanies an
otherwise-intended request; an SSRF mitigation that blocks private address
ranges provides no protection here, because the destination may be an
ordinary public address. This weakness may be achieved through CWE-918 but
is not a subset of it.
Distinction from CWE-522 (Insufficiently Protected Credentials): in every
observed instance the credential is protected properly in transit (TLS, not
logged); it is delivered intact and confidential to the wrong recipient,
not intercepted.
Distinction from CWE-441 (Confused Deputy): CWE-441's harm is inbound (the
product's identity is borrowed). Here the harm is outbound: the credential
leaves the product's trust boundary to an untrusted party who may use it
independently later.
Demonstrative example: A product installs a custom HTTP transport that sets
an Authorization header on every request it processes. Because the
transport is invoked once per redirect hop, the header is re-applied after
a redirect, defeating the language runtime's own behavior of stripping
Authorization headers on cross-host redirects. The credential is
transmitted to the host named by the redirect. The protection existed at
the runtime layer and was correct; it was bypassed by ordinary application
code, without the developer intending to defeat it, by installing a
transport that re-applies the header per hop.
Observed example: CVE-2026-14540, a server-side request forgery in an
official vendor AI-agent toolkit. The HTTP tool validated the initial
request URL but followed redirects without re-validating the destination of
each hop, permitting a redirect to return the cloud instance metadata
endpoint's credentials to the caller. Publicly documented and fixed by the
vendor.
Potential mitigations: (1) Resolve outbound destinations from trusted
configuration rather than externally influenced input. (2) Where a caller
must be able to name a destination, validate it against an allowlist using
exact host or exact domain-suffix comparison before attaching any
credential; substring or "contains a delimiter" checks are insufficient.
(3) Where a caller must reach arbitrary destinations, withhold the
credential when the destination is not the trusted one. (4) Where redirects
are followed, re-validate the destination on every hop and strip
Authorization headers when the host changes; verify no custom transport
re-applies credentials per hop, which defeats runtime protections that
already exist.
Detection: static analysis can identify this pattern by locating
constructions where a credential is attached as a connection password or
bearer token while the destination host in the same construction derives
from a variable, with no allowlist validation between the external input
and the credential attachment.
Submission File: ES2608-94e48d11-new-credential-destination-injection.txt
ID: ES2608-94e48d11
SUBMISSION DATE: 2026-08-20 21:39:22
NAME: Credential Destination Injection
DESCRIPTION:
The product attaches a credential it holds (an API key, access token, or
database credential) to an outbound request or connection whose destination
is determined, wholly or partly, by externally influenced input, without
validating that destination against a trusted allowlist before the
credential is attached.
A product that acts on behalf of a user frequently holds a credential. When
such a product exposes an interface that lets an external party influence
the destination of an outbound request, and the credential is attached
before the destination is validated, the product delivers its own
credential to a destination chosen by that party. The credential is not
exfiltrated through a memory or storage weakness; it is transmitted
voluntarily, over a properly secured channel, to an untrusted endpoint,
because the destination was treated as data rather than as a security
decision.
This weakness is characteristic of tool-invocation layers in AI agent
systems, where the values passed to a tool are selected by a language model
that processes untrusted content as a matter of course. External influence
over a tool argument is the normal operating condition rather than an
exceptional one.
Distinction from CWE-918 (SSRF): CWE-918 concerns reaching an unintended
destination and does not require the product to hold a credential. This
weakness's harm is that the product's own credential accompanies an
otherwise-intended request; an SSRF mitigation that blocks private address
ranges provides no protection here, because the destination may be an
ordinary public address. This weakness may be achieved through CWE-918 but
is not a subset of it.
Distinction from CWE-522 (Insufficiently Protected Credentials): in every
observed instance the credential is protected properly in transit (TLS, not
logged); it is delivered intact and confidential to the wrong recipient,
not intercepted.
Distinction from CWE-441 (Confused Deputy): CWE-441's harm is inbound (the
product's identity is borrowed). Here the harm is outbound: the credential
leaves the product's trust boundary to an untrusted party who may use it
independently later.
Demonstrative example: A product installs a custom HTTP transport that sets
an Authorization header on every request it processes. Because the
transport is invoked once per redirect hop, the header is re-applied after
a redirect, defeating the language runtime's own behavior of stripping
Authorization headers on cross-host redirects. The credential is
transmitted to the host named by the redirect. The protection existed at
the runtime layer and was correct; it was bypassed by ordinary application
code, without the developer intending to defeat it, by installing a
transport that re-applies the header per hop.
Observed example: CVE-2026-14540, a server-side request forgery in an
official vendor AI-agent toolkit. The HTTP tool validated the initial
request URL but followed redirects without re-validating the destination of
each hop, permitting a redirect to return the cloud instance metadata
endpoint's credentials to the caller. Publicly documented and fixed by the
vendor.
Potential mitigations: (1) Resolve outbound destinations from trusted
configuration rather than externally influenced input. (2) Where a caller
must be able to name a destination, validate it against an allowlist using
exact host or exact domain-suffix comparison before attaching any
credential; substring or "contains a delimiter" checks are insufficient.
(3) Where a caller must reach arbitrary destinations, withhold the
credential when the destination is not the trusted one. (4) Where redirects
are followed, re-validate the destination on every hop and strip
Authorization headers when the host changes; verify no custom transport
re-applies credentials per hop, which defeats runtime protections that
already exist.
Detection: static analysis can identify this pattern by locating
constructions where a credential is attached as a connection password or
bearer token while the destination host in the same construction derives
from a variable, with no allowlist validation between the external input
and the credential attachment.