Remote Code Executor: Systems & Security

• Remote Code Executor is a mechanism that decouples code selection from execution, functioning as both a deliberate systems abstraction and an exploitable security vulnerability.
• Approaches include monadic invocation, function shipping over RDMA, workspace delegation, and per-request cloud execution, each balancing trust and performance differently.
• Mitigations emphasize sandboxing, least privilege, attestation, and explicit governance to reduce hazards in remote execution infrastructures.

Searching arXiv for the cited papers and closely related work to ground the article in the supplied literature. A remote code executor is a mechanism, interface, or attack path through which code selected on one machine is caused to run in another execution context. In systems work, this ranges from typed abstractions that execute functions over remote JVM values, through RDMA-level function shipping, delegated workspaces for agent collaboration, block-storage-side eBPF programs, and browser-facing multi-language execution engines, to name-based remote function execution in edge networks (Jolly, 2017, Peña et al., 2021, Nie et al., 24 Feb 2026, Kourtis et al., 2020, Hafiz et al., 2021, Qi et al., 2021). In security work, the same phrase denotes the adversarial ability to make a remote system execute attacker-chosen code, as in Java deserialization chains, model-loading pipelines that import remote Python, or GPU-focused payloads embedded in serialized models (Sayar et al., 2022, Siddiq et al., 20 Jan 2026, Szabo et al., 9 Feb 2025).

1. Conceptual scope

Remote code execution has two technically distinct but structurally related meanings. The first is a deliberate systems abstraction: computation is packaged as a function, closure, program fragment, workspace operation, or per-request job and is then executed where data, tools, or specialized hardware reside. The second is a security failure mode: some input path, such as ObjectInputStream.readObject(), pickle.load, torch.hub.load(..., trust_repo=True), or transformers ... trust_remote_code=True, becomes an unintended execution surface for attacker-controlled code (Jolly, 2017, Sayar et al., 2022, Siddiq et al., 20 Jan 2026).

The common technical denominator is a separation between the site where code is chosen and the site where code runs. In “Monadic Remote Invocation,” Remote[T] is a handle to a value of type T living in a remote JVM, and map or flatMap ship a function to the location of that value; get materializes the result locally (Jolly, 2017). In AWCP, the Delegator projects a real filesystem subtree to a remote Executor, who then runs local tools directly against that tree as if it were local; the control plane is distinct from the transport that materializes the workspace (Nie et al., 24 Feb 2026). In the ML security papers, the same decoupling appears negatively: the model artifact or repository is chosen elsewhere, but local loading or inference logic executes code embedded in that artifact (Szabo et al., 9 Feb 2025, Siddiq et al., 20 Jan 2026).

This suggests that “remote code executor” is best understood as a systems boundary rather than a single implementation pattern. The boundary may be explicit and typed, as in a monad or an RPC-like API, or implicit and unsafe, as in a deserialization gadget chain or a model-loading trust flag.

2. Execution abstractions and programming models

A recurring design choice is the granularity of the executable unit. The Remote monad treats the unit as a function over a remote value. Its core type constructor is $\mathsf{Remote} : \mathbf{Type} \to \mathbf{Type}$, with unit $$\mathsf{return} : \forall T.\; T \to \mathsf{Remote}\,T$$ and bind $$\mathsf{bind} : \forall T,S.\; \mathsf{Remote}\,T \to (T \to \mathsf{Remote}\,S) \to \mathsf{Remote}\,S$$, implemented by Remote.apply, map, and flatMap atop Java RMI (Jolly, 2017). The critical property is orthogonality: business objects need not implement java.rmi.Remote; they are wrapped only when remote access is required.

At a lower level, UCX “ifunc” makes binary executable code itself the network payload. An ifunc message contains a code section, an optional payload, and metadata; the sender registers an ifunc library, creates a message, transmits it with ucp_ifunc_msg_send_nbix, and the receiver invokes the shipped function via ucp_poll_ifunc after resolving library symbols and patching the embedded code to local GOT state (Peña et al., 2021). This is not merely RPC: the implementation being invoked is shipped with the message.

AWCP shifts the abstraction again, from functions to workspaces. The protocol defines a Delegator, an Executor, a control layer over HTTP plus Server-Sent Events, and pluggable transports including SSHFS, Archive, Storage, and Git. Instead of a “run-command” RPC, the remote side receives a local-looking directory and operates with unmodified local toolchains (Nie et al., 24 Feb 2026). In practice, this turns remote execution into filesystem manipulation plus local process execution.

Cloud execution engines use a service-per-language abstraction. The “runlang” pattern assigns each language or ecosystem configuration to its own Kubernetes Service and Docker image, with generic describe and execute APIs exposed by a Flask server inside each pod. The router authenticates, dispatches, and stores shareable playground state in Redis, while execution occurs as subprocesses inside the language-specific container (Hafiz et al., 2021).

Abstraction	Execution unit	Representative mechanism
Monadic remote invocation	Function/closure over Remote[T]	map, flatMap, get (Jolly, 2017)
UCX remote function injection	Native code section plus payload	ucp_ifunc_msg_send_nbix, ucp_poll_ifunc (Peña et al., 2021)
Workspace delegation	Filesystem subtree plus local tools	INVITE, ACCEPT, START, DONE (Nie et al., 24 Feb 2026)
Cloud execution engine	Per-request subprocess in language service	describe, execute (Hafiz et al., 2021)

These models differ in transport and trust assumptions, but all expose a programmable remote execution context while trying to keep code, data, and orchestration compositional.

3. Data locality, transport, and orchestration

Remote code executors are often justified by data locality. In disaggregated NVM storage, the paper on eBPF near-data execution argues that the performance bottleneck shifts to the network because a single NVM device can read 10–15 GB/s while a 100 Gbps link tops out around 12.5 GB/s. For a remote increment implemented as read-modify-write, offloading reduces network round trips from two to one and yields ~43% latency reduction under the reported 10GbE and 3DXP NVMe measurements; for binary search over 1 TiB of sorted 8-byte values, reducing 37 round trips to one yields an expected latency reduction of ~86% (Kourtis et al., 2020). The executor here is an eBPF appcode running inside a user-space storage service via helpers such as io_read, io_write, and data_realloc.

R2 addresses a similar locality problem in Named Data Networking. Its request naming format is

$$/r2/\texttt{data-name}/\texttt{sep}/\texttt{function-name}/\{\texttt{params}\},$$

and it decomposes remote execution into two phases: metadata retrieval plus distributed executor selection, followed by data transfer to the chosen executor and return of only the result (Qi et al., 2021). The total delay is modeled as

$$\begin{aligned} D =&\ T^{c,p}_{\text{metadata-interest}} + T^{p,b}_{\text{metadata}} \ &+ T^{b,p}_{\text{result-interest}} + T^{p,i}_{\text{data}} + C_d^i + T^{i,c}_{\text{result}} , \end{aligned}$$

and selection uses metadata-derived estimates such as

$$Te_d^{p,i} = M_{datasize} \times \frac{M_{metasize}}{(T_{start} - T_{current})}, \qquad Ce_d^i = \frac{c \cdot \mathcal{O}(M_{datasize})}{CPU_{frequency}} .$$

In the reported simulations, when data size is 100 KiB and function complexity is $\mathcal{O}(n^2)$, the speedup ratio is 4.61 (Qi et al., 2021).

UCX ifunc is optimized for fast compute migration over RDMA. For small payloads, ifunc is up to 42% slower than UCX active messages, but for a 1 MB payload it achieves 35% lower latency. In throughput experiments, the ifunc message rate is 81% lower than active messages at 1-byte payload, then becomes better beyond 1 KB–2 KB, peaking at ~380% higher for larger payloads before stabilizing at 23–62% higher (Peña et al., 2021). The crossover arises because shipping code has fixed overheads that are amortized only when payloads are large enough.

Cloud orchestration introduces a different optimization problem: capacity management under spiky demand. The remote execution engine on Kubernetes evaluates reactive HPA against predictive HPA using the World Cup ’98 trace and a penalty function that combines latency, failed requests, and average pod count. In representative runs, KNN-based PHPA yields penalty 17.38 with 77 failed requests, reactive HPA yields 18.40 with 65 failed requests, and linear regression yields 19.60 with 123 failed requests (Hafiz et al., 2021). The paper’s conclusion is not that prediction dominates in every metric, but that short-horizon forecasting can improve the latency–cost trade-off.

AWCP adds transport pluralism at the workspace layer. SSHFS provides live bidirectional sync, Archive and Storage provide snapshot-oriented projection, and Git provides branch-based synchronization with auditable changes (Nie et al., 24 Feb 2026). This suggests that remote code execution increasingly depends on transport choice not merely for bandwidth, but for semantic properties such as liveness, auditability, and conflict behavior.

4. Isolation, attestation, and execution control

A remote code executor is also a security substrate, because it determines what ambient authority remotely executed code receives. CapExec takes the position that sandboxing should be introduced by the service manager rather than retrofitted into each service. On FreeBSD, it launches unmodified binaries under Capsicum capability mode, configures Casper services such as system.fileargs, system.dns, system.sysctl, and system.net, and relies on declaration files to specify allowed resources (Jadidi et al., 2019). The effect is that a compromised service process can only access the file descriptors and Casper channels it already holds; ambient operations such as unrestricted filesystem traversal or arbitrary connect() are blocked unless explicitly delegated.

CAIF addresses a different question: how to bind remote channels to known code identities. Each device has an intrinsic secret $IS$, each service has a service hash $sh$, and keys are derived as

$k = \mathsf{kdf}_h(\text{"at"}, IS, sh)$

for local attestation and

$$\mathsf{return} : \forall T.\; T \to \mathsf{Remote}\,T$$0

for protection from source hash $$\mathsf{return} : \forall T.\; T \to \mathsf{Remote}\,T$$1 to recipient hash $$\mathsf{return} : \forall T.\; T \to \mathsf{Remote}\,T$$2 (Dyer et al., 2024). attest-locally(v) returns $$\mathsf{return} : \forall T.\; T \to \mathsf{Remote}\,T$$3, while protect-for(sh_r, v) returns an authenticated encryption under the pairwise key. The paper proves that CAIF is computationally indistinguishable from an ideal functionality defined in terms of logging and confidential escrow, and then uses that functionality to construct Assured Remote Execution, delegated signing keys, and certificate chains that bind messages to processes identified by code hash even under a strong adversary that may execute unauthorized programs on the device (Dyer et al., 2024).

USP proposes yet another control point: a new session layer inserted between transport and application. Its message flow consists of initialize, authenticate, token, connect, and error, with the invariant that security-critical applications do not process user data until authentication succeeds (Anderson, 2023). The architectural claim is that the current stack “unconditionally fulfills every request for a connection into an application,” whereas USP would make authentication a precondition for application-layer parsing. This does not remove post-authentication vulnerabilities, but it aims to eliminate anonymous pre-auth exploitability as a class.

Taken together, these works separate three control problems that are often conflated: least privilege for the process once running, cryptographic assurance about which code is running, and admission control over who can reach an application parser at all.

5. Exploit-oriented remote code execution

In offensive security, a remote code executor is often a serialization or loading path that turns data into code. The Java deserialization study formalizes the standard pattern: an application deserializes attacker-controlled bytes, and gadget classes on the classpath convert automatic callback execution into a gadget chain culminating in command execution (Sayar et al., 2022). The paper runs 256515 experiments across 19 ysoserial exploits, 14 libraries, and 147 JVM versions, and shows that gadget-bearing versions are substantially more widespread than exploit documentation suggests. It further reports that 37.5% of the studied libraries are not patched, and that in a manual study of 104 CVEs, 24.1% rely on workaround-only mitigations rather than code changes (Sayar et al., 2022).

Model-loading ecosystems create a newer execution surface. The empirical study across Hugging Face, OpenCSG, ModelScope, OpenMMLab, and PyTorch Hub treats repositories as RCE-capable when they are marked custom_code or contain standard entry-point files such as hubconf.py, tokenizer.py, modeling_*.py, configuration_*.py, or tokenization_*.py. Out of 128,487 Python files, 67,009 are considered reachable from load-time entry points, and across all platforms roughly 45,000 repositories contain code that can execute during model loading (Siddiq et al., 20 Jan 2026).

Platform	Total models/repos	Custom-code repos
Hugging Face	2,107,935	36,697
OpenCSG	192,556	6,165
ModelScope	68,736	3,193
OpenMMLab	16	16
PyTorch Hub	26	26

The same study reports substantial static-analysis findings in execution-relevant code, including CWE‑502, CWE‑95, and CWE‑78 patterns, and documents persistent developer confusion about what trust_remote_code=True and trust_repo=True actually do (Siddiq et al., 20 Jan 2026). This is reinforced by the GPU-focused RCE paper, which shows two concrete exploit paths: malicious pickle deserialization using a crafted __reduce__, and TensorFlow/Keras Lambda layers that execute os.system(...) while returning x so the model behaves normally (Szabo et al., 9 Feb 2025). In that setting, a model file becomes a remote code executor for cryptocurrency mining, and runtime detection is hard because high GPU utilization already looks normal on AI infrastructure.

The exploit literature therefore broadens the term beyond classic network daemons. A Java readObject() path, a model hub trust flag, or a model Lambda layer can all act as a remote code executor even when the surrounding application never exposes an explicit “run code” feature.

6. Mitigation, governance, and open problems

The mitigations described across these papers are layered rather than singular. For exploit prevention, the consistent recommendation is to remove unsafe execution surfaces: avoid pickle and analogous unsafe formats for untrusted data, prefer data-only formats such as safetensors, treat serialized models as untrusted executables, minimize use of Lambda and arbitrary Python code in production models, and add static model scanning for os.system, subprocess, suspicious __reduce__ implementations, and embedded custom code (Szabo et al., 9 Feb 2025, Siddiq et al., 20 Jan 2026). In Java, the application-level rule is to avoid deserializing untrusted data, use allow-lists or ObjectInputFilter when serialization cannot be removed, and recognize that gadget patching in libraries is only a partial defense (Sayar et al., 2022).

For executor containment, the papers converge on least privilege. CapExec uses declarative capability restriction at service launch time; the cloud execution engine identifies stronger per-execution isolation, cgroups, seccomp, user separation, and network restrictions as future work; the eBPF storage executor relies on verification plus restricted helpers, while also identifying bounded loops and higher-order functions as necessary to increase expressiveness without giving up verifiability (Jadidi et al., 2019, Hafiz et al., 2021, Kourtis et al., 2020). AWCP similarly externalizes policy into Admission Control, LeaseConfig, ExecutorConstraints, and snapshot policies such as auto, staged, and discard, while explicitly noting that file-level permissions, role-based authorization, and audit logs are not yet standardized (Nie et al., 24 Feb 2026).

For trust establishment, CAIF and USP point in complementary directions. CAIF binds secrets and channels to code hashes via device-resident symmetric primitives, which supports trustworthy remote attestation and delegated keys even when other software layers are compromised (Dyer et al., 2024). USP, by contrast, attempts to make identity establishment a prerequisite for application data processing, thereby reducing anonymous pre-auth attack surfaces (Anderson, 2023). This suggests that future remote execution infrastructures may need to combine code identity, artifact provenance, session identity, and resource isolation rather than relying on any one mechanism.

Several open problems remain explicit in the sources. The Remote monad is synchronous by default and inherits RMI limitations, although Async and Deferred adapters indicate directions for asynchrony and lazy batching (Jolly, 2017). AWCP is essentially one-to-one and lacks built-in CRDT-style concurrent editing or native discovery (Nie et al., 24 Feb 2026). UCX ifunc still assumes the ifunc library is present on the target filesystem and lacks a full security model (Peña et al., 2021). The cloud engine is optimized for small experiments rather than project-scale execution (Hafiz et al., 2021). The NVM eBPF executor is constrained by verifier limits and the lack of loops (Kourtis et al., 2020). And the model-hub studies make clear that ecosystem defaults, documentation, and user expectations still normalize remote code execution in contexts where many developers do not realize they are enabling it (Siddiq et al., 20 Jan 2026).

A plausible implication is that the technical center of gravity has moved from “how to execute code remotely” to “how to make remote execution explicit, typed, attestable, and governable.” Where that explicitness is absent, the same machinery reappears as an exploit surface.