Client-side RCE

Client-side RCE is remote code execution that happens on the user’s device or workstation rather than on a server. In MCP contexts, it often appears when browser launch helpers, shell wrappers, or URL handlers interpret attacker-controlled input as a command or executable path.

Expanded Definition

Client-side RCE is not a server compromise; it is code execution that lands on the end user’s workstation, browser process, or local helper application when untrusted input is interpreted as a command, file path, or launch target. In MCP-heavy environments, that distinction matters because a seemingly harmless prompt, link, or tool response can cross from data handling into local execution. The control problem is less about remote infrastructure and more about whether client tooling sanitises arguments, constrains URI schemes, and refuses unsafe shell expansion. Definitions vary across vendors when browser automation, desktop wrappers, and agentic launchers are bundled together, so NHI teams should treat the client boundary as a separate attack surface rather than assuming server-side safeguards cover it. NIST guidance on least privilege and secure configuration aligns well with this model, especially NIST SP 800-53 Rev 5 Security and Privacy Controls. The most common misapplication is assuming a local launcher is safe because it only processes “trusted” URLs, which occurs when attacker-controlled parameters reach shell or OS handler logic without validation.

Examples and Use Cases

Implementing protection against client-side RCE rigorously often introduces friction, requiring organisations to balance smoother user workflows against stricter validation, restricted handlers, and more explicit allowlists.

• A browser helper opens a custom URI and passes the value directly to a shell wrapper, allowing command injection if the URI contains metacharacters. This is the pattern seen in investigations like Gemini CLI Breach — Silent Code Execution.
• An AI desktop client downloads a tool result and writes it into a path that is later executed as if it were a trusted binary, turning path confusion into local code execution.
• A plugin or browser extension exposes a local command bridge, then fails to distinguish benign user input from attacker-crafted payloads, similar to the supply-chain patterns described in Hard-Coded Secrets in VSCode Extensions.
• A developer copies a response from an MCP assistant into a local launcher that auto-expands environment variables or subshell syntax, producing execution on the workstation instead of a harmless text action.
• Local security tooling misclassifies a browser file association as inert, but the handler invokes executable code on open, echoing the exploitation dynamics in ASP.NET machine keys RCE attack.

Why It Matters in NHI Security

Client-side RCE is a direct threat to NHI governance because the workstation often holds the very secrets, session tokens, and signed-in tool access that attackers need to pivot into agentic workflows. Once the endpoint is compromised, attackers can steal credentials, hijack browser sessions, and impersonate service accounts that were never meant to execute locally. NHI Mgmt Group research shows that 79% of organisations have experienced secrets leaks, with 77% resulting in tangible damage, which underscores how quickly endpoint compromise can become identity compromise. The operational lesson is that local execution risk is inseparable from secret placement, because secrets stored in code, config files, or tooling caches become immediately reachable after RCE. That is why least privilege, local hardening, and handler restrictions should be treated as identity controls, not just endpoint hygiene, and mapped to frameworks like NIST SP 800-53 Rev 5 Security and Privacy Controls. Organisations typically encounter the blast radius only after a workstation is used as the first foothold into agent tokens, at which point client-side RCE becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does client-side obfuscation stop being useful for fraud prevention?
• How should security teams decide whether client-side obfuscation is enough?
• What do teams get wrong about protecting client-side security logic?
• What breaks when a GitHub token is embedded in client-side code?