I Use Figma Every Day
I open Figma before I open my email. I have built design systems in it, shipped client work through it, stored five years of professional output inside it. I install plugins from its community library. I share files with clients via invite links. I receive Figma notification emails and click them without hesitation because I know what they look like. Figma is as familiar to me as my own keyboard.
Last week I started looking at it like an attacker. I do not know exactly what triggered the shift — probably the combination of spending months writing detection rules for email threats and reading too many incident reports at midnight. But once I started asking the question, I could not stop. What does Figma look like if you are not a designer trying to collaborate, but an attacker trying to get inside an organization that uses it?
The answer is more uncomfortable than I expected. Not because Figma is uniquely insecure, but because the things that make it useful to me as a designer — easy sharing, instant publishing, open plugin ecosystem, trusted notification emails — are the same properties that make it useful to an attacker. The features are the attack surface.
Why this matters for designers specifically: Most security research on platform abuse focuses on the victim as a generic user. This field note is written from inside the tool. I know how designers actually use Figma — the workflows, the habits, the things we click without thinking. That insider perspective is the part I have not seen written anywhere else, and it is the part that changes how I think about the risk.
The Email Problem — Figma's Own Infrastructure as a Delivery Mechanism
Figma sends notification emails from no-reply@email.figma.com. Every designer who uses Figma has trained themselves to trust this sender — it means a colleague shared a file, a client left a comment, a project needs review. The domain is legitimate. SPF, DKIM, and DMARC all pass. No email security tool flags it. It goes straight to your inbox and you click it because that is what you do with Figma notification emails.
Two incidents documented in the Figma community forum confirm this infrastructure is being abused. In the first, a user reported receiving a mass campaign where people who had never created a Figma account were receiving "User has invited you to view a file" emails from no-reply@mail.figma.com. Figma's support team confirmed the emails were legitimate — they were real Figma file invites, sent at scale, using Figma's own invite system as a spam and phishing delivery mechanism. The attacker did not spoof anything. They used a real account to invite thousands of addresses to a file, and Figma's infrastructure dutifully sent each one an authenticated notification email.
In the second incident, a designer reported that a colleague's account was compromised. The attacker used the compromised account to send a Figma project link to every contact in the account's network. The link went to a real Figma project containing a secondary phishing link. The victim opened the project — it was from a colleague's account, it looked like a normal Figma share — and found the malicious link inside. No report button existed at the time.
Why this bypasses standard detection: An email from no-reply@email.figma.com with a Figma file invite passes every authentication check. The domain is real. The sender is real. The link goes to figma.com. The thumbnail preview is a real Figma file. There is no spoofing, no typosquat, no suspicious attachment. The only signal is context: who is sending it, to whom, and whether any prior relationship exists.
Sublime Security has two existing rules for Figma-related phishing. The first targets Figma deck or design links with NLU-detected credential theft language. The second targets Figma share notification emails containing "access document" text in the thumbnail, specifically targeting campaigns impersonating Microsoft or DocuSign. Both rules are well-built and catch real campaigns. Neither catches the account takeover variant — a clean-looking project invite from a compromised account, with no credential theft language and no fake document overlay, sent to someone who has a legitimate prior relationship with the account owner.
That is the gap. A new rule targeting first-contact Figma invites from accounts with no prior benign history would close it.
The Plugin Surface — What Runs Inside Your Files
Every time I install a Figma plugin, I am running third-party code inside my design environment. That code has access to the contents of any file I have open — component names, layer structure, text content, client names visible in designs, design tokens, anything on the canvas. This is by design. Plugins need file access to do useful things like export assets, generate style guides, or run accessibility checks.
What I did not think carefully about until recently is the network access question. A Figma plugin can declare "allowedDomains": ["*"] in its manifest — unrestricted access to any domain. Or it can leave the field undefined entirely, in which case it defaults to "Unknown network access" — which in practice also means unrestricted access. Figma's review process is focused on user experience quality, not security. Their own blog confirmed this during a 2024 security incident: they halted all plugin updates not because they were auditing security, but because they had found a specific vulnerability. The sandbox enforces boundaries but does not audit what data leaves through permitted channels.
The pattern I keep seeing documented across supply chain attacks — Glassworm in VS Code, malicious npm packages, poisoned GitHub Actions — applies here too. Publish a clean plugin. Build an install base. Push a malicious update. Figma's review applies to the initial submission; material updates are subject to re-review, but the mechanism for detecting a sleeper update that adds exfiltration functionality is the same sandbox that was not auditing security in the first place.
A designer at an enterprise company told me on the Figma forum that their organization had banned all third-party plugins for exactly this reason: "sensitive design data flows to unknown third-party servers." That is the correct instinct. Most designers — including me, until recently — install plugins without thinking about this at all.
What a malicious plugin can access: The contents of any open file, including client names, project details, and any text visible on the canvas. Clipboard contents. The file key (which can be used to make Figma REST API calls on behalf of the user if OAuth tokens are accessible). Network calls to any external server if unrestricted access is declared. The plugin runs in a sandbox, but the sandbox permits outbound network calls by design — that is how legitimate plugins connect to external services.
The protection that exists — admin-controlled plugin allowlists — is Enterprise-only. Every Figma user on a free, Starter, or Professional plan can install any published plugin without any organizational review. That is most designers.
What I Am Doing About It
Writing this down is part of what I am doing about it. The Framer field note changed how I think about portfolio links. This one is changing how I think about every Figma notification email I receive and every plugin I install.
For the email detection gap: I am building a complementary Figma rule targeting first-contact file invites from accounts with no prior benign history. The existing Sublime rules cover credential theft overlays and specific campaign patterns. The new rule would cover the account takeover variant — the clean-looking invite that looks exactly like a legitimate share because it is sent from a real Figma account that the attacker compromised. The signal is not the content of the email. It is the relationship between the sender and the recipient.
For the plugin surface: I have started reviewing the network access declarations of every plugin I use. Plugins with unrestricted access that do not require external connectivity for their stated purpose are being removed. I am not banning plugins — that would make Figma significantly less useful — but I am treating the plugin installation decision the way I now treat clicking an unknown link: with a moment of deliberate thought rather than automatic trust.
There is a broader observation here that I keep coming back to. The tools I know best are the ones I am most vulnerable to, because familiarity produces automatic trust. I have been in security long enough now to know that automatic trust is exactly what attackers engineer for. The Framer link looked right because I know what Framer links look like. The Figma invite looks right because I know what Figma invites look like. The plugin looks right because I installed it from the same community library where I found every other plugin I use.
Being a designer who pivoted into security means I carry both sets of knowledge at once. I know what these tools look like from the inside. I know what the workflows feel like, what the notifications say, what the URLs pattern to. That is not a vulnerability — it is an advantage, but only if I use it deliberately. The detection rules I write are written by someone who knows exactly what a legitimate Figma invite looks like and can therefore specify precisely what makes a suspicious one different.
This is Part 1 of a two-part series on Figma as an attack surface. Part 2 — The Plugin Ecosystem, MCP, and a CSS Export Hypothesis →
Community forum incidents sourced from forum.figma.com (collected August 2026 via Playwright scraper). CVE-2025-53967 (Framelink Figma MCP Server RCE) documented by Imperva Threat Research, October 2025. Plugin security incident referenced from Figma's own blog post "An Update on Plugin Security" (December 2024). Figma review process security posture confirmed from Figma Help Center plugin review guidelines. Existing Sublime Security Figma detection rules: link_figma_deck_cred_theft.yml and brand_impersonation_figma_doc_access_overlay.yml. A companion detection rule targeting first-contact Figma file invites from accounts with no prior benign history is in development. This field note represents independent research produced for educational purposes.