Unintended Proxy or Intermediary ('Confused Deputy')

The product receives a request, message, or directive from an upstream component, but the product does not sufficiently preserve the original source of the request before forwarding the request to an external actor that is outside of the product's control sphere. This causes the product to appear to be the source of the request, leading it to act as a proxy or other intermediary between the upstream component and the external actor.


If an attacker cannot directly contact a target, but the product has access to the target, then the attacker can send a request to the product and have it be forwarded to the target. The request would appear to be coming from the product's system, not the attacker's system. As a result, the attacker can bypass access controls (such as firewalls) or hide the source of malicious requests, since the requests would not be coming directly from the attacker.

Since proxy functionality and message-forwarding often serve a legitimate purpose, this issue only becomes a vulnerability when:

The product runs with different privileges or on a different system, or otherwise has different levels of access than the upstream component;

The attacker is prevented from making the request directly to the target; and

The attacker can create a request that the proxy does not explicitly intend to be forwarded on the behalf of the requester. Such a request might point to an unexpected hostname, port number, hardware IP, or service. Or, the request might be sent to an allowed service, but the request could contain disallowed directives, commands, or resources.


The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.

Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.

Example One

A SoC contains a microcontroller (running ring-3 (least trusted ring) code), a Memory Mapped Input Output (MMIO) mapped IP core (containing design-house secrets), and a Direct Memory Access (DMA) controller, among several other compute elements and peripherals. The SoC implements access control to protect the registers in the IP core (which registers store the design-house secrets) from malicious, ring-3 (least trusted ring) code executing on the microcontroller. The DMA controller, however, is not blocked off from accessing the IP core for functional reasons.

The code in ring-3 (least trusted ring) of the
                     microcontroller attempts to directly read the protected
                     registers in IP core through MMIO transactions. However,
                     this attempt is blocked due to the implemented access
                     control. Now, the microcontroller configures the DMA core
                     to transfer data from the protected registers to a memory
                     region that it has access to. The DMA core, which is
                     acting as an intermediary in this transaction, does not
                     preserve the identity of the microcontroller and, instead,
                     initiates a new transaction with its own identity. Since
                     the DMA core has access, the transaction (and hence, the
                     attack) is successful.

The weakness here is that the intermediary or the proxy agent did not ensure the immutability of the identity of the microcontroller initiating the transaction.

                     core forwards this transaction with the identity of the
                     code executing on the microcontroller, which is the
                     original initiator of the end-to-end transaction. Now the
                     transaction is blocked, as a result of forwarding the
                     identity of the true initiator which lacks the permission
                     to access the confidential MMIO mapped IP core.

See Also

Privilege Separation and Access Control Issues

Weaknesses in this category are related to features and mechanisms providing hardware-based isolation and access control (e.g., identity, policy, locking control) of s...

Identify Actors

Weaknesses in this category are related to the design and architecture of a system's identification management components. Frequently these deal with verifying that ex...

SFP Secondary Cluster: Channel Attack

This category identifies Software Fault Patterns (SFPs) within the Channel Attack cluster.

Comprehensive CWE Dictionary

This view (slice) covers all the elements in CWE.

Weaknesses without Software Fault Patterns

CWE identifiers in this view are weaknesses that do not have associated Software Fault Patterns (SFPs), as covered by the CWE-888 view. As such, they represent gaps in...

Weaknesses Introduced During Design

This view (slice) lists weaknesses that can be introduced during design.

Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.