Because model settings can change what code the runtime loads and executes. If the application accepts a repository reference and flags such as trust_remote_code, then user input can direct the server to fetch and run attacker-controlled code. That is code execution by configuration, not by payload delivery alone.
Why configuration becomes an execution primitive
Client-controlled model settings are dangerous when the settings do more than tune behaviour. If a server treats a repository URL, model name, loader flag, or execution option as trustworthy input, the configuration path can become a code path. That changes the question from “can an attacker influence output?” to “can an attacker influence what the server imports, initialises, or runs?”
That distinction matters because the runtime is not merely reading data. It may resolve a remote module, unpack a package, or execute startup hooks before any safety checks on the generated output ever apply. In practice, a small configuration surface can grant the caller control over where code comes from and whether it is trusted.
The core failure is boundary collapse: settings intended for operator control are exposed to untrusted users. Once that happens, the server may fetch remote code, resolve dependencies, or switch into a “trust” mode that disables protective barriers and gives the attacker a path to execution without needing a classic exploit payload.
Which settings turn into RCE risk
The highest-risk pattern is a setting that changes code provenance, loading behaviour, or execution trust. Repository references, plugin identifiers, dynamic import options, and “run remote code” style flags are all dangerous if the application accepts them from the client and uses them server-side.
Model systems are especially sensitive because the same request can carry both content and control. A user may appear to be asking for inference, but if the application forwards a model reference or a trust flag into the backend, the request can instruct the platform to download code from an attacker-chosen location and execute it in the server process.
This is why configuration-driven execution is often more dangerous than prompt injection alone. A malicious prompt may alter output, but a malicious setting can alter the execution environment itself. The risk increases when the loader has network access, broad filesystem access, or access to secrets already present in the runtime.
Where the attack path becomes practical
The practical attack path is usually simple: the attacker supplies a repository or package reference, the service resolves it, and the imported code runs during model initialisation or tool setup. The dangerous part is that the server is doing exactly what the configuration told it to do, which makes the behaviour look legitimate unless the application explicitly constrains where code can come from.
This attack is easier to miss when the application blends user choice with administrative capability. A field that seems like a harmless model selector can become a remote loader when it accepts arbitrary references. Likewise, a trust flag can disable safeguards that would otherwise block dynamic code execution, turning a convenience feature into a server-side execution path.
For practitioners, the important question is not whether the setting is called “model configuration” or “deployment option.” The question is whether the setting can change the provenance, trust, or executable contents of the runtime. If it can, then it should be treated as an execution boundary, not a display preference.
Risk and Threat Considerations
When untrusted users can influence model loading or trust settings, the outcome can be full server compromise rather than just model manipulation. The attacker is not limited to altering output quality, because the runtime may fetch code, load modules, and execute attacker-chosen logic before normal application controls have a chance to intervene.
Failure mechanism: A client-supplied setting changes code provenance or disables a trust barrier, allowing the server to import and run remote or attacker-controlled code during model setup.
Impact: The result can be remote code execution, secret exposure, lateral movement, or persistence inside the host or container running the model service.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Client-controlled loader flags and trust settings are an API misuse and misconfiguration risk. |
| Recommendation — Reject client-supplied execution flags and enforce a server-side allowlist for code-loading settings. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Remote code loading becomes worse when the runtime can access broad host resources and secrets. |
| Recommendation — Limit the model runtime to the minimum filesystem, network, and secret access it actually needs. | ||
| OWASP Agentic AI Top 10 | ASI05 — Unexpected Code Execution | If model settings can trigger remote code loading, the agent or runtime may execute untrusted code unexpectedly. |
| Recommendation — Disable attacker-influenced code loading paths and require explicit approval for executable runtime changes. | ||
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Server-side execution via configuration maps to attacker abuse of interpreter-capable runtimes. |
| Recommendation — Detect and block unexpected interpreter activity initiated by configuration or model bootstrap paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege and Access Management | Execution-capable settings should be tightly controlled and not exposed to untrusted callers. |
| Recommendation — Restrict who can change execution-relevant settings and separate operator permissions from user inputs. | ||
Practitioner Guidance
What to verify: Treat every field that can alter model source, loader behaviour, or execution trust as privileged input. Verify that the backend rejects arbitrary repository references, ignores client-supplied trust flags, and enforces an allowlist for any dynamic code source.
What good looks like: The application separates user intent from operator-controlled execution settings, with remote code loading disabled by default and only enabled through a controlled deployment path. The service should also log when code provenance changes so reviewers can distinguish a normal inference request from an execution-capable request.
Practitioner takeaway: If a setting can change what the server loads or runs, secure it as if it were an execution API, because that is exactly what an attacker will try to turn it into.
Related resources from NHI Mgmt Group
- Why do unsafe XSLT processing settings create remote code execution risk in metadata catalog platforms?
- Why does user-controlled data in a Spring view name create a remote code execution risk?
- Why does attacker-controlled JNDI input create remote code execution risk in Java apps?
- Why does user-controlled file path handling create remote code execution risk in PHP applications?