# Wrong caller identity forwarded to callee

Cross-contract calls that pass an EOA or user-supplied sender where the callee expects the contract's own address

_Area: Smart contract access control and control flow. Seen in 3 disclosed reports; latest 2026-08-20. Updated 2026-10-23._

## How it works
A contract authenticates a caller locally, then calls another contract and tells it who the caller is. The callee runs its own authorization check against that forwarded identity. The assumption that breaks: the identity checked locally is the same identity the callee expects. When the forwarder passes the admin EOA (or an arbitrary calldata sender) instead of its own address, the callee either rejects a legitimate call or accepts one on behalf of the wrong party. The local check can be perfectly correct and the flow still fails at the boundary.

## Where it shows up
- Cross-contract calls where an `admin`/`caller`/`from` argument is passed explicitly rather than derived from `address(this)` or `msg.sender`.
- Callee checks like `validate_pool_configurator` or `onlyModule` that compare against a contract address, while the caller forwards an EOA.
- Upgrade paths (`update_atoken`, `update_variable_debt_token`, `update_token_implementation`) where the configurator and router disagree on the expected actor.
- Any handoff where the caller authenticates the admin locally and then forwards that admin onward as the caller.

## How to review
For every cross-contract call, write down the identity the callee authorizes and the identity the caller actually sends. The invariant: the forwarded actor must equal the address the callee's check expects. Trace the full handoff, not just the local check. A locally-correct admin check does not prove the downstream call will pass; confirm the value placed in the caller/from field is the contract's own address when the callee authorizes the contract.

## Variants seen
- Configurator forwards admin EOA instead of its own address; router expects the configurator contract, so upgrades always revert Unauthorized [E3](https://bugbountylibrary.com/r/c4%3A2026-04-k2%3AM-34.md).

## Impact and severity
In the evidence this bricked a privileged flow: token implementation upgrades always reverted, permanently blocking the upgrade path [E3](https://bugbountylibrary.com/r/c4%3A2026-04-k2%3AM-34.md). Severity is high when the broken flow is the only route to a privileged action, since the failure is deterministic and affects every call, not just adversarial ones. No fund loss appeared in the evidence for this pattern.

## Adjacent patterns (not instances)
- Forwarding user-supplied payloads to a module that makes arbitrary external calls, reaching a privileged function [E1](https://bugbountylibrary.com/r/sherlock%3A2024-03-arrakis%3AH-1.md) — a payload-forwarding flaw, not an identity mismatch.
- A selector with no caller auth or ownership check on token amounts [E2](https://bugbountylibrary.com/r/dhl%3A20250822-unverified-6f7a.md) — missing access control, not a forwarded-identity error.

## Evidence
- E1: https://bugbountylibrary.com/r/sherlock%3A2024-03-arrakis%3AH-1.md
- E2: https://bugbountylibrary.com/r/dhl%3A20250822-unverified-6f7a.md
- E3: https://bugbountylibrary.com/r/c4%3A2026-04-k2%3AM-34.md