Figma MCP server confusion turns one package into an RCE risk

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Repello AI's blog post: Two Figma MCP servers share a name, but only the community package figma-developer-mcp carried a critical command injection that could lead to remote code execution.

Why it matters: IAM and NHI teams need to treat local MCP servers as privileged software supply chain components, because package confusion, floating installs, and process privileges can turn a small bug into workstation compromise.

By the numbers:

• The vulnerability was scored CVSS 8.0 and fixed in version 0.6.3 on 29 September 2025.

Context

The immediate problem is not just a vulnerability in an MCP server, but confusion over which server is actually installed. In local AI toolchains, package names, labels, and screenshots often diverge, so teams think they are reviewing one integration while another package is running in the background.

That matters because MCP servers sit close to developer privileges and often inherit broad access to files, credentials, and network resources. In this case, the security question is less about the Figma integration itself than about how software identity, install method, and runtime trust combine inside a workstation environment.

Key questions

Q: What is the failure mode when an MCP server uses shell commands in fallback logic?

A: The failure mode is that untrusted input can be treated as shell syntax instead of data, so a retry path becomes a command injection surface. If the process uses exec or another shell-based launcher, attacker-controlled characters may run with the privileges of the local server. That is why fallback code deserves the same review and testing as the main request path.

Q: Why do local MCP server bugs become more serious than similar web bugs?

A: Local MCP servers often execute with the developer's own privileges, so a successful exploit can reach files, tokens, SSH material, and other workstation-held secrets. The network reach may be narrower than a public service, but the blast radius is often larger because the process sits inside the user's trust boundary. That changes triage from service hardening to workstation containment.

Q: How can teams tell whether an MCP package is actually safe to use?

A: They cannot rely on labels alone. Teams need the exact package name, the installed version, and a record of how it was launched, because floating installs can change silently between restarts. Safety depends on provenance, pinning, and verification of the running artefact, not on the name shown in a UI or a blog post.

Q: Should organisations treat npx-installed MCP servers differently from pinned packages?

A: Yes. Floating npx installs are convenient but they weaken version control, reproducibility, and incident traceability. A pinned package gives you an explicit approval point and a stable artefact to assess, while a floating install can change whenever the registry changes. For governed environments, that difference is material to both risk and auditability.

Technical breakdown

How a fallback shell call became command injection

The vulnerability sat in the retry path, not the main request path. When the normal API request failed, the code built a curl command as a string and passed it to child_process.exec, which invokes a shell. That means attacker-influenced input could include shell metacharacters and be interpreted as commands instead of data. The safer pattern is execFile or an equivalent API that passes arguments as an array and never shells out. This is a classic example of why error-handling code deserves the same review discipline as the primary execution path. See the Web Application Attacks Guide.

Practical implication: Review retry and fallback code first when assessing an MCP server, because the dangerous execution path is often outside the happy path.

Why local MCP servers increase the blast radius

A local MCP server is not just another service endpoint. It runs with the privileges of the developer session, so successful code execution can inherit access to shell history, files, SSH material, tokens, and other local secrets. That changes the security impact from a remote web flaw to a workstation compromise problem. The attack surface may be smaller because the process is local, but the consequence is usually larger because the attacker gains the same trust boundary the developer uses every day. See the NHI Authentication Guide.

Practical implication: Treat local MCP servers as high-trust processes and constrain their filesystem and network reach to the minimum needed for function.

Why floating npx installs create supply-chain ambiguity

Most MCP servers are started with npx, which fetches a package at launch time. If the version is not pinned, the code on the machine is whatever the registry serves at that moment, and there may be no durable record of which build actually ran. That creates a software supply chain problem inside developer tooling: a fix can arrive silently, but so can a compromised release, a regression, or a package swap hidden behind the same label. The operational issue is version provenance, not just patch latency. See the MCP Security Guide.

Practical implication: Pin exact package versions and record what actually executed on developer machines so the runtime matches the approved build.

Threat narrative

Attacker objective: The attacker wants to execute arbitrary commands on a developer workstation and use that foothold to access local credentials and files.

1. Entry occurs when a user or agent invokes the affected MCP server through the community package rather than the official Figma server, exposing the vulnerable retry path.
2. Credential or command abuse follows when attacker-controlled input reaches the curl shell string and shell metacharacters are interpreted as commands.
3. Escalation happens because the code executes with the privileges of the local server process, giving the attacker access to the developer workstation context.
4. Impact is remote code execution on the local machine, with potential exposure of files, keys, and other workstation-held credentials.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Package identity is now a security control, not a documentation detail. When two software components share the same product label, teams cannot rely on screenshots, blog posts, or memory to determine exposure. The control point is the actual package name and version recorded in the client configuration. For MCP deployments, inventory accuracy is part of the trust boundary, not an administrative nicety.

Local MCP servers behave like privileged desktop infrastructure. They are often treated as lightweight tooling, but they execute in a context that can reach the developer's files, tokens, and shell. That makes containment and provenance far more important than the nominal CVSS score. In practice, the risk is not only the bug itself but the privilege attached to the process that hosts it.

Fallback logic is the most underrated attack surface in AI toolchains. The bug lived in retry code, which is exactly where teams least expect to find command injection. That pattern aligns with broader agentic application risks because orchestration layers and error handlers increasingly decide what gets executed, when, and with which credentials. Practitioners should scrutinise the code paths that run when something goes wrong, not just the main workflow.

Floating package resolution is a governance failure, not just a deployment convenience. Launching MCP servers through npx without a pinned version means the runtime can change without an explicit approval step. That weakens software provenance and complicates incident response because the team may not know which build was actually active. The practical conclusion is simple: if the package can change silently, so can the risk.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Software provenance is becoming an identity problem for developer tooling. The issue is not only whether a package is vulnerable, but whether the environment can prove which package actually ran, when, and under what privileges. That is why version pinning, install attestation, and endpoint inventory matter together, especially when local tools can execute commands and touch sensitive files.

The next governance step is to separate convenience from trust. Teams need policies for approved package names, pinned versions, and minimum process privileges so that a change in one of those dimensions is a deliberate event, not a side effect of restarting an editor or refresh cycle.

For practitioners

• Verify the exact MCP package name Open the client configuration and confirm whether the installed server is the official Figma Dev Mode server or figma-developer-mcp. Do not trust the display label, since the two are commonly conflated in screenshots and writeups.
• Pin the running version Replace floating npx launches with an exact package version or a locally installed dependency so the server binary does not change silently on restart. Record the approved version in configuration management and compare it to what actually runs on endpoints.
• Restrict local process privileges Run the MCP server with the narrowest filesystem and network access it needs, because command execution inherits the server process privileges. Limit what the process can read and where it can connect, especially on developer workstations.
• Review fallback and retry paths first Inspect retry, timeout, and fallback code for shell invocation, string concatenation, and other unsafe command construction before you approve an MCP server for use. The bug in this case lived in the error path, not the main logic.

Key takeaways

• The core risk is not just command injection, but confusion over which MCP server is actually in use and whether it is pinned.
• The reported issue was CVSS 8.0 and was fixed in 0.6.3, but the wider lesson is that local process privilege can turn a tooling bug into workstation compromise.
• Teams should verify package identity, pin versions, and constrain local server access because those controls directly reduce the blast radius of MCP failures.

Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · Web Application Attacks Guide · LiteLLM PyPI package breach

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Command injection: Command injection occurs when attacker-controlled data is inserted into a shell command and changes what the process executes. In AI tooling, that often happens through wrappers, plugins, or installation flows that turn paths or prompts into shell strings. The impact is privilege abuse through the process’s inherited authority.
• Software provenance: Software provenance is the evidence that shows where an artifact came from, who created it, and whether it was altered before use. For security teams, it means signed releases, controlled build paths, and verification steps that reduce the chance of trusted software carrying hidden malicious changes.
• Process containment: Process containment limits what a running service can read, write, or reach on the network. For local MCP servers, it is a key control because successful code execution should not automatically expose the entire workstation, its keys, or its file system.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners translate identity control principles into repeatable operational decisions across modern toolchains.