# Dynamic Module Loading for Code Execution

- **Severity:** High
- **Signature ID:** `fcb4143d-23d3-4aef-8792-3711002e3180`
- **MITRE ATLAS:** AML.T0050 (Command and Scripting Interpreter)
- **OWASP:** ASI05 (Cascading Failures in Multi-Agent Systems), LLM06 (Excessive Agency)

## Summary

Some applications load extra code modules while running, rather than having all modules fixed in advance. If the path to that module comes from a variable instead of a fixed string, an attacker who can influence that variable can make the application load and run code they control.

## How the attack works

The application contains a dynamic import or module-loading call where the module path is a variable instead of a hardcoded string. An attacker finds a way to influence that variable's value, for example through user input, a config file, an agent's tool output, or a manipulated file path. The application then loads whatever module is at that attacker-influenced path, which can be a malicious script, a WebAssembly file, or a native library. Because the load happens dynamically, this code is not visible in the application's static imports and is harder to audit or catch before it runs.

## Why it matters

An attacker who controls the load path gets arbitrary code execution inside the application's process, which can lead to data theft, further compromise of connected systems, or hijacking of an AI agent's tool-calling behavior.

## What you can do

- Replace variable-based module paths with static, hardcoded imports wherever possible.
- If dynamic loading is required, restrict it to an explicit allowlist of known module names or paths and reject anything else.
- Never build a module path directly from user input, agent output, or external data without validation.
- Review any lazy-loading or plugin systems to confirm the resolved paths cannot be influenced by untrusted sources.

## Known benign look-alikes

- Plugin systems with allowlisted module paths
- Legitimate lazy-loading of known application modules
- Build tools or bundlers that use dynamic import() with computed chunk names for code-splitting optimization
- Documentation or training materials that include code examples showing dynamic module loading patterns
- Test harnesses that use importlib.import_module to load test fixtures from a controlled directory

## References

- https://agentthreatrule.org/en/rules/ATR-2026-00112

---
Source: https://www.netzilo.com/threats/atr-dynamic-module-loading-for-code-execution