Arbitrary method dispatch is a programming flaw where an attacker can make software invoke a chosen method or function. It usually arises when untrusted input controls a method name, object type, or reflection call, turning normal control flow into code execution or unauthorised actions.
What Arbitrary Method Dispatch Means in Practice
Arbitrary method dispatch is dangerous because it breaks the boundary between data and code. When untrusted input can choose which method runs, the program may perform actions the developer never intended, including privileged operations or unsafe control-flow transitions.
This flaw usually appears in reflective invocation, dynamic routing, plug-in lookups, or object deserialization patterns where method names or target classes are treated as trustworthy. The security problem is not reflection itself, but letting attacker-controlled values decide what executable path the application follows.
How the Flaw Turns Input Into Execution
The common failure mode is a lookup or dispatch step that trusts user input too early. Instead of mapping an allowed request to a fixed operation, the application resolves a method name, object member, or handler at runtime and then invokes it directly.
That design can convert a routine request into arbitrary function calls, privilege-sensitive operations, or unexpected side effects. In practice, the danger grows when the chosen method can alter authentication state, file access, configuration, or backend workflow without additional authorization checks.
Where Arbitrary Dispatch Usually Emerges
Arbitrary method dispatch is most often introduced by convenience features in frameworks and application code. Dynamic language features, reflection APIs, serialisation hooks, template engines, and “action by name” controller patterns all become risky when the method selector is derived from attacker-controlled input.
It also appears in extensible systems where plug-ins, message handlers, or command objects are selected at runtime. If the allowlist is weak, incomplete, or absent, the attacker may reach code paths that were meant only for internal use, administrative actions, or trusted integration flows.
Why It Matters for Security and Review
The security impact is broader than a single bad method call. Arbitrary dispatch can be a stepping stone to remote code execution, forced state changes, data exposure, and security control bypass, especially when the invoked method performs high-trust operations on behalf of the application.
It also complicates testing and code review because the vulnerable behaviour is often indirect: the dangerous action is hidden behind generic dispatch logic, not an obviously malicious call site. As a result, the flaw can survive normal functional testing unless reviewers trace how user input is mapped to executable targets.
Risk and Threat Considerations
When arbitrary method dispatch is exploitable, the main risk is loss of control over application behaviour. Attackers can steer execution into privileged or unintended paths, which can expose data, mutate records, or trigger administrative functions that were never meant to be user-selectable.
Failure mechanism: Untrusted input is accepted as a method selector, object type, or reflective target, and the application invokes that target without strict allowlisting and context-aware authorization.
Impact: The attacker may gain code execution, unauthorized action, workflow abuse, or a path to broader compromise if the chosen method can access sensitive resources or security-relevant state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Arbitrary dispatch is a secure-coding flaw in how code paths are selected at runtime. |
| Recommendation — Constrain dynamic dispatch to approved targets and review control flow for unsafe reflection or routing. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | The flaw starts when attacker-controlled input is trusted as an executable selector. |
| Recommendation — Validate and constrain dispatch inputs before they can influence executable code paths. | ||
| MITRE ATT&CK | T1203 — Exploitation for Client Execution | Abuse of unsafe dispatch can drive execution into attacker-chosen code paths. |
| Recommendation — Map unsafe dispatch behaviours to execution abuse paths and validate defensive controls. | ||
Practitioner Guidance
What to watch for: Treat any runtime dispatch that accepts names, types, or handlers from outside the trust boundary as a security-sensitive interface. The safest designs constrain dispatch to a fixed set of known operations and validate that the selected action is appropriate for the current user and context.
Practitioner takeaway: If the application can choose an action dynamically, the security question is no longer “can it dispatch?” but “who is allowed to influence the dispatch target, and what can that target do?”
Related resources from NHI Mgmt Group
- When does a phishing-resistant login method still leave organisations exposed?
- What breaks if an EUDI wallet is treated like a generic login method?
- What breaks when Java auth is added without method-level authorization?
- What breaks when banks rely on SMS OTP as the only transaction authentication method?