TL;DR: There are two things called the Figma MCP server, and only one of them had a critical vulnerability. The community package
figma-developer-mcpfrom Framelink carried CVE-2025-53967, a CVSS 8.0 command injection that reached remote code execution through a fallbackcurlcall built as a shell string. It was fixed in 0.6.3 on 29 September 2025. If you installed vianpxwith a floating tag, you do not currently know which version you are running.
Two servers, one name#
Ask a designer or a frontend engineer whether they have "the Figma MCP server" installed and you will get a yes. Ask which one and the answer is usually a shrug, because both are described the same way in blog posts, starter configs, and screenshots.
Figma ships an official Dev Mode MCP server. Separately, Framelink publishes figma-developer-mcp, a widely adopted community package that predates and in many setups still sits alongside the official one. They are different codebases with different maintainers and different security histories. Only the second one carried CVE-2025-53967.
This is not a pedantic distinction. It decides whether the rest of this post applies to you, and the only reliable way to answer it is to open your client's MCP configuration and read the package name rather than the label somebody typed next to it.
Only the community package was affected. Most teams cannot say from memory which one they installed.
The bug was in the error path#
The vulnerability sat in the get_figma_data tool. Attacker-influenced input was interpolated into a child_process.exec call, which invokes a shell, so shell metacharacters in that input executed as commands with the privileges of the server process. Endor Labs traced it to a fallback in src/utils/fetch-with-retry.ts: when the ordinary Figma API request failed, the server retried by assembling a curl command as a string and handing it to the shell.
Two details make this worth dwelling on.
The first is that the main request path was fine. The injection lived in retry logic, which runs only when something else has already gone wrong. Error handling is chronically under-reviewed and under-tested, and it is where a surprising share of injection bugs survive to release.
The second is that exec was never necessary. The documented remediation is to use execFile, which passes arguments as an array and never involves a shell, so metacharacters have nothing to interpret them. The fix in 0.6.3 closed the specific hole; the general lesson is that a local MCP server shelling out at all deserves scrutiny.
Why local MCP servers make this worse than it sounds#
In a web service, a CVSS 8.0 like CVE-2025-53967 usually means an attacker somewhere on a network. A local MCP server changes the arithmetic in both directions.
It narrows reachability, because the server listens locally and an attacker generally needs to influence data your agent already fetches rather than connect directly. But it widens impact, because the process runs as you. It holds your shell, your filesystem, your SSH keys, and your other credentials. Remote code execution in a background process on a developer workstation is worth substantially more to an attacker than the same score on an isolated container.
This is the same reason the TrustFall class of MCP remote code execution issues mattered more than their scores suggested. The score describes the flaw. The runtime context describes what the flaw buys.
The distribution problem underneath#
Most MCP servers are launched with npx, which resolves and fetches the package at start time. That is convenient, and it means that unless you pinned an exact version, the code running on your machine today is whatever the registry served most recently.
For a vulnerability like this one that cuts in your favour: restart after 29 September 2025 and you likely picked up the fix without doing anything. It cuts the other way for everything else. A compromised release, a malicious maintainer, or a regression lands with the same silence. You did not choose the version, and you have no record of which one ran.
That is a software supply chain problem wearing developer-tooling clothes, and it is the same argument we made about MCP security more broadly: the install step is where the trust decision actually happens, and almost nobody treats it as one.
What to do#
Read your config and identify the package. Not the label, the package name. Teams regularly discover they are running both servers.
Pin exact versions. Replace floating npx invocations with a pinned version or a locally installed dependency, so upgrades are decisions rather than side effects of restarting your editor.
Contain local servers. Give an MCP server the narrowest filesystem and network access it can function with. CVE-2025-53967 executed with the server process's privileges, and containment is what determines whether that means reading one design cache or reading your ~/.ssh.
Assume error paths are unreviewed. If you are evaluating an MCP server yourself, read its retry, timeout, and fallback code first. That is where this one was, and it is where the next one will be.
FAQ#
Is the Figma MCP server safe?#
That depends on which one you installed, and most teams do not know. Figma ships an official Dev Mode MCP server. Separately, the community package figma-developer-mcp from Framelink carried CVE-2025-53967, a CVSS 8.0 command injection that allowed remote code execution. The two are commonly conflated because both are described as the Figma MCP server. Check your configuration for the package name before deciding whether the CVE applies to you.
What is CVE-2025-53967?#
CVE-2025-53967 is a command injection vulnerability in the Framelink figma-developer-mcp server, scored 8.0. Unsanitized input reached a child_process.exec call inside a retry path, so shell metacharacters in a parameter to the get_figma_data tool executed as system commands with the privileges of the server process. It was fixed in version 0.6.3, released 29 September 2025.
How did a design tool integration end up with remote code execution?#
Through a fallback. When a Figma API request failed, the server retried by constructing a curl command as a string and handing it to a shell. Building a shell command from untrusted input is the classic injection pattern, and it appeared in error-handling code rather than the main path, which is exactly where it escapes review. The main request path was never the problem.
How do I check whether I am affected?#
Look at the MCP server definition in your client configuration and read the actual package name rather than the display label. If it references figma-developer-mcp, check the version and upgrade to 0.6.3 or later. Because most MCP servers are launched through npx, you may be pulling a fresh copy on every start, which means your installed version is whatever the registry served most recently rather than something you pinned.
What should I do beyond upgrading?#
Pin versions rather than running npx with a floating tag, so a compromised or regressed release cannot land silently on the next launch. Run local MCP servers with the minimum filesystem and network access they need, since the CVE executed with the server process's privileges and containment limits what that is worth. Treat the community package and the vendor package as different supply chains, because they are.
Find out which package is actually running#
The gap between the MCP server people believe they installed and the one running on their laptop is where this whole class of issue lives. Workstation Lens inspects what is actually there — entrypoints, manifests and versions — across every developer machine, and flags deviations from what was approved. Fifteen-minute setup through the EDR you already run.
