Arbitrary External Call

How arbitrary external calls work

Arbitrary external call is not just a bad parameter, it is a control-flow failure. The program accepts attacker-influenced input and uses it to choose a destination outside the intended trust boundary, such as a function selector, URL, endpoint, webhook, contract address, or other callable target.

That shift matters because the application is no longer deciding where execution should go. The untrusted caller is effectively steering the target, which can turn a normally bounded action into an indirect execution path with attacker-chosen side effects.

Why this flaw is dangerous

The core danger is loss of destination integrity. Once an attacker can redirect a call, the program may send data, funds, or privileged requests to an unintended recipient, or invoke code that performs actions the developer never meant to expose. In blockchain and smart contract settings, that can include calling the wrong contract address or triggering logic in an unexpected external contract.

Because the callee is external, the impact is often larger than a local bug. The called system may trust the request, execute immediately, or cascade the request into additional actions. That makes arbitrary external call flaws especially useful for abuse patterns that depend on trusted execution paths rather than outright code execution on the original host.

Common failure conditions and attack paths

These flaws usually appear when developers concatenate untrusted input into a request target, reuse user-supplied routing data without validation, or treat a caller-controlled identifier as if it were a safe destination reference. In smart contracts, the risk is often magnified when external calls happen before state is finalized, or when the destination can be substituted for a malicious contract that re-enters, drains value, or alters control flow.

Attackers look for places where the application assumes the target is fixed, trusted, or internally derived. If the target itself is user-controlled, the rest of the security model can collapse, because authentication, business logic, and transaction integrity all depend on the call reaching the right endpoint.

How to assess and contain the exposure

Exposure review starts with identifying every place the application can build an external call from parameters, configuration, metadata, or user content. Review the asset inventory for externally reachable call paths, then confirm whether the target is fixed, allowlisted, or otherwise constrained. For smart contracts, use the project guidance in the OWASP Smart Contract Top 10 Guide to map the flaw to the wider class of unchecked or unsafe external calls.

Where the architecture cannot eliminate the pattern, reduce blast radius with strict target allowlists, strong input validation, explicit destination binding, and least-privilege execution. External dependencies should be treated as untrusted until proven otherwise, especially when the call can move value, invoke privileged actions, or cross a security boundary.

Risk and Threat Considerations

Arbitrary external calls can become an abuse primitive for redirecting execution, laundering trust, or moving value to an attacker-controlled destination. The risk is highest when the call target is derived from user input, because the defender loses assurance over where the request actually lands.

Failure mechanism: An attacker supplies a destination that resolves to a malicious endpoint or contract, then the application dutifully sends the request, data, or value to that target.

Impact: This can produce unauthorized side effects, data exposure, fund loss, privilege abuse, or secondary compromise through a trusted execution path.

Practitioner Guidance

What to watch for: Treat any code path that converts user input into an outbound call target as a review hotspot. If the destination can change without a hardcoded allowlist or equivalent trust check, the design should be assumed unsafe until proven otherwise.

Practitioner note: The safest pattern is to separate “what action is allowed” from “where the action is sent”, then bind both to server-side policy. That distinction is often what prevents a routine integration from becoming an attacker-controlled relay.

Related resources from NHI Mgmt Group

• How should teams reduce secret exposure for workloads that call external APIs?
• How should security teams govern multi-agent workflows that call external APIs?
• How should security teams govern custom GPTs that can call external systems?
• How should security teams classify AI agents that can read data and call external systems?