I Install Plugins Without Thinking
I have installed more Figma plugins than I can count. Color palette generators, icon libraries, content fillers, accessibility checkers, export tools, handoff utilities. I install them from the Figma community library the same way I used to install apps from the App Store — I see something useful, I click install, and I get back to work. I do not read the permissions screen. I do not think about what the plugin is doing with my files. That has never felt like something I needed to think about.
I started thinking about it last week. Not because something went wrong — nothing did. But I have been spending months learning how attacks work, and at some point I looked up from my detection rules and realized I had been running untrusted third-party code inside my most sensitive design files for years without a second thought. The files with client names. The files with unreleased product designs. The files where I store everything.
What I found when I actually looked at how Figma's plugin system works is not what I expected. Not because Figma is doing something wrong — they are not. But because the design of the system, optimized for openness and ease of use, creates exactly the kind of gaps that supply chain attackers have been exploiting in every other developer ecosystem for years.
This field note is Part 2 of a series on Figma as an attack surface. Part 1 covered how Figma's email notification infrastructure is being abused to deliver phishing at scale. This piece covers what happens inside the tool itself — the plugin ecosystem, the AI agent integration, and a hypothesis about CSS export that I have not seen documented anywhere else.
What a Plugin Can Actually Do
When you install a Figma plugin, you are running code that has access to everything in your open file. Every layer, every component name, every piece of text on the canvas. Client names visible in your designs. Unreleased product concepts. Internal project names. Design tokens that encode your brand system. All of it is readable by the plugin while it runs.
That part is expected — plugins need file access to do useful things. What surprised me is the network access question. A plugin can declare in its configuration that it needs access to any domain on the internet. Or it can leave the network access field undefined entirely, which defaults to "Unknown network access" — meaning unrestricted. Either way, the plugin can make outbound network calls while it has access to your file contents.
Figma reviews plugins before publishing them to the community. But their own blog confirmed during a 2024 security incident that the review process is focused on user experience quality, not security. They use a sandbox to enforce boundaries — but the sandbox permits outbound network calls by design, because legitimate plugins need to connect to external services. The review cannot catch a plugin that sends your file data somewhere it should not, because the capability to do that is not a bug. It is a feature.
The sleeper pattern: Across every supply chain attack I have studied — Glassworm in VS Code extensions, malicious npm packages, poisoned GitHub Actions — the same playbook appears. Publish something clean and useful. Build an install base. Then push a malicious update. Figma says that material updates to plugins are subject to re-review. But the mechanism for catching a subtle update that adds data exfiltration to a previously clean plugin is the same review process that was not auditing for security in the first place. The question is not whether Figma's review team is paying attention. It is whether the review process is designed to catch this class of attack.
I went through my installed plugins this week. Several of them declare unrestricted network access for functionality that, as far as I can tell, does not require any external connectivity at all. I cannot verify what they are doing with that access. That bothered me more than I expected it to.
The protection against this — an admin-controlled plugin allowlist that restricts which plugins members can install — exists in Figma. It is an Enterprise-only feature. Most designers, including me, are not on Enterprise plans. We can install anything published to the community library, and the only check is whether Figma's review team liked the user experience.
When Your AI Coding Agent Opens a Figma File
In 2025, a new category of tool appeared in the design workflow: Figma MCP servers. MCP stands for Model Context Protocol — it is a way to connect AI coding agents like Cursor to external services, so the AI can read your Figma designs and translate them directly into code. The most popular one, with over 600,000 downloads, is the Framelink Figma MCP server.
In September 2025, a security researcher at Imperva found a vulnerability in that server that allowed remote code execution. The technical details are not complicated: the server passed a filename parameter — the Figma file key — directly into a shell command without cleaning it first. An attacker who could control what file key the agent received could inject arbitrary commands that would run on the developer's machine. The vulnerability was assigned CVE-2025-53967 and fixed in version 0.6.3.
The interesting part is not the vulnerability itself — that kind of input validation mistake happens constantly in software. The interesting part is the attack chain it enables. A malicious Figma community template, shared publicly and installed by a developer using an AI coding agent, could contain a crafted file key in its metadata. When the agent processes the file, the malicious input triggers the shell injection. The developer receives what looks like a normal design file. Their machine runs attacker-controlled code.
Why this connects to email: The delivery mechanism for a poisoned Figma template can be email. "Here is the design file for the project we discussed" — a Figma share link, from what looks like a legitimate sender, going to a developer who uses an AI coding agent in their workflow. The email is the delivery vector. The Figma file is the payload. The MCP server is the exploit. Three separate trust boundaries, each one bypassed by the previous step.
The CVE is fixed. But the pattern it represents — AI agents as an amplification layer for attacks delivered through design tools — is not fixed. It is a new attack surface category that barely existed two years ago and is now part of standard developer workflows.
A Hypothesis About CSS Export — Something I Have Not Seen Documented
This last section is different from the first three. The plugin issues and the MCP vulnerability are documented facts. This is something I noticed and have not seen written about anywhere — which means either I am onto something original, or I am missing something obvious. I am sharing it as a hypothesis, not a finding.
Figma has a Dev Mode — a panel where developers inspect designs and copy CSS properties to use in their code. When a developer clicks on a component, Figma generates CSS from the visual properties of that layer: the font, the colors, the spacing, the sizing. The developer copies that CSS and pastes it into their codebase.
This is completely normal. It is one of the most common designer-developer handoff workflows in the industry. I have used it hundreds of times.
Here is what I started wondering: what if someone built a Figma community template — a free, polished UI kit, the kind that gets thousands of installs — and carefully crafted the layer properties so that the CSS Figma generates from them contains malicious patterns? Not in the visual design, which would look perfectly normal. In the underlying property values that become CSS when a developer clicks inspect.
The CSS injection signals I documented in my CSS field note — position:fixed, :has(), @font-face with unicode-range, image-set(var( — these are all valid CSS properties that Figma works with. A skilled attacker who understood both Figma's property system and CSS injection techniques could potentially engineer a component whose "normal-looking" design properties produce dangerous CSS when exported through Dev Mode.
The developer pastes the exported CSS into an email template, a webmail client stylesheet, or a web component without reviewing it for security signals — because nobody reviews CSS exported from a design tool for injection patterns. That is not part of any developer's mental model when they are copying spacing values from Figma.
I have not tested this. This is a hypothesis based on understanding both systems — Figma's CSS export behavior and CSS injection attack patterns — well enough to see how they could intersect. I am flagging it as a research direction, not a confirmed vulnerability. If someone has already documented this, I would like to know. If nobody has, it is worth investigating properly before publishing a more detailed claim.
What I know for certain is that the mental model most designers and developers have about Figma-exported CSS — "this is just styling data, it is safe to paste" — is exactly the kind of assumed trust that attackers engineer for. I am not ready to say it is exploitable. I am ready to say it is worth looking at more carefully than anyone currently is.
This is Part 2 of a two-part series on Figma as an attack surface. ← Part 1 — Email Infrastructure Abuse and Invite Phishing
Plugin security behavior sourced from Figma Help Center plugin review guidelines and Figma Blog "An Update on Plugin Security" (December 2024). CVE-2025-53967 documented by Imperva Threat Research (October 2025) and GitHub Advisory GHSA-gxw4-4fc5-9gr5. Prompt injection via Figma design content documented in GLips/Figma-Context-MCP GitHub issue #303 (March 2026). Enterprise plugin controls sourced from Figma Help Center. CSS export contamination hypothesis represents the author's original analytical observation — not a confirmed vulnerability. CSS injection signals reference: yanaivanov.com/writing/css_field_note.html. This field note represents independent research produced for educational purposes.