Style Dictionary flaw CVE-2026-54639: a crafted token can poison your build — update to 5.4.4
Style Dictionary, the popular tool that turns design tokens (colors, spacing) into code, has a high-severity flaw, CVE-2026-54639 (8.8). A crafted token can pollute the shared object prototype during a build, cascading to a poisoned build, outages, or worse. Versions 4.3.0 to 5.4.3 are affected. Update to 5.4.4 — and here's who actually needs to worry.

Makoto Horikawa
Backend Engineer / AWS / Django
Style Dictionary, the popular tool that turns design tokens (colors, spacing) into code, has a high-severity flaw, CVE-2026-54639 (8.8). A crafted token can pollute the shared object prototype during a build, cascading to a poisoned build, outages, or worse. Versions 4.3.0 to 5.4.3 are affected. Update to 5.4.4 — and here's who actually needs to worry.
A high-severity flaw has been found in Style Dictionary, the developer tool that keeps an app's design decisions—colors, spacing, font sizes—in one place and converts them into CSS and platform code. It is tracked as CVE-2026-54639 and rated 8.8 out of 10. If a crafted design token (a color or spacing definition) is processed, the master prototype that every JavaScript object inherits from gets rewritten, which can cascade into a poisoned build, a service outage, or in the worst case code execution on the server.
Style Dictionary was originally released by Amazon and is now maintained by the community, and it is a staple in front-end teams that run a design system. The flaw lives in an internal conversion routine called convertTokenData, and it was disclosed on June 8 as an official advisory (GHSA-vj5c-m527-mpff). The fixed version is 5.4.4.
That said, this is not a hole anyone can hit just by sending a request to a live website. It requires getting malicious token data processed during a build. That is exactly why it matters to sort out who is actually at risk and in what situation. This article walks through what can happen, who really needs to worry, and what to do right now.
✓ What is confirmed so far
- ✓Affected: Style Dictionary 4.3.0 up to (but not including) 5.4.4. The cause is prototype pollution (CWE-1321):
convertTokenDatadid not validate token keys - ✓Severity 8.8 out of 10 (NVD, CVSS v3.1). Exploitation needs malicious tokens to be processed; it cannot be triggered unconditionally over the network
- ✓Fixed in 5.4.4 (via PR #1702). Reported by @Dremig, fixed by maintainer @jorenbroekema
- ✓As of June 2026 there are no reports of real-world exploitation, and it is not in the U.S. government's KEV list of actively exploited flaws
What Style Dictionary and "prototype pollution" are
Style Dictionary keeps design baseline values as "design tokens" and converts them in one pass into outputs for each environment—CSS variables, Sass, Swift for iOS, XML for Android, and so on. Write "brand blue is #0066cc" or "base spacing is 8px" once, and the same value reaches Web, iOS and Android. Crucially, it does not run inside the app's screen; it runs in the build step on a developer's machine or a CI server.
The flaw is a type called prototype pollution (CWE-1321). JavaScript objects inherit their traits from a shared parent. If an attacker writes arbitrary values into that parent—the master blueprint—then every object created afterward inherits the tainted blueprint. The damage does not stay in one place; the program's underlying assumptions quietly drift.
The trigger is a situation where an outside string is used directly as an object's key. Slip a specially meaningful name like __proto__ into a token definition, and a routine that meant only to store a value instead writes into the master blueprint.
Who would do this, and what they want
This hole is not the kind you brute-force from outside against a live app. Style Dictionary does not run behind the screen; it runs in the build step that turns design tokens into code. The people who can exploit it are those positioned to slip crafted token data into that build—someone who can swap out token files or distributed packages pulled in from outside, or a contributor who can submit one malicious line to a system where many people post token definitions.
Such a person prepares data with __proto__ planted in a token's key, and by getting Style Dictionary to read and convert it, rewrites the master blueprint that every JavaScript object inherits. What changes is not one particular token but the shared foundation that the entire Node.js process running the build relies on. Once that is touched, the effect reaches every routine running in that process.
For the team running the build, the loss is being unable to trust the CSS and code that come out. If the build proceeds on a tainted foundation, unintended values can end up in the output, a type mix-up can crash the build, or—combined with another routine in the same process—it can escalate to code execution on the server, as reported. And that output is then distributed, through the design system, to every downstream app and user. More than the 8.8 CVSS number suggests, the real harm is that the given that "our design's source of truth is decided only by us" falls apart.
The technical view: where convertTokenData went wrong
The problem sat in convertTokenData(), an internal function that reshapes a list of tokens into an easier-to-handle form. According to the official advisory, when you pass output: 'object' to fold a token array into an object, it used the key strings without validating them. So a token whose key contains __proto__, like the one below, pollutes the master blueprint.
// a crafted token
[{ key: '{__proto__.polluted}', value: 'malicious' }]
// afterward, {}.polluted returns "malicious" on every object
The severity is rated CVSS v3.1 8.8. It does not reach the top 9-point band because the attack vector is "local"—that is, malicious tokens have to be processed by a build; you cannot trigger it unconditionally from outside. At the same time, because the pollution lands on the master blueprint shared across the whole program (scope rated "changed") and is estimated to hit confidentiality, integrity and availability all heavily, even a local starting point yields a high 8.8. The bug was introduced in version 4.3.0 and, after the report, fixed in 5.4.4. The fix makes token keys containing __proto__ be ignored.
Who really needs to worry
This is the most important part. Even if you use Style Dictionary, your real exposure depends heavily on where your tokens come from.
| How you use it | Real risk | What to do |
|---|---|---|
| You build only tokens written by your own team | Low | Update to 5.4.4 to be safe |
| You ingest and build tokens from outside / third parties | High | Update now + validate input |
| You offer token conversion as a service or plugin to others | High | Update now + validate input |
In short, if only trusted members write the tokens and you build them as-is, the chance of being hit is low. The more you take tokens in from outside, the higher the risk: platforms that offer token conversion as a service, setups that load tokens from external themes or plugins, and monorepos or open-source projects where untrusted contributors can submit token definitions. The CVSS rating of "local, low privilege required" reflects exactly that precondition. Either way, the fix itself is easy, so updating regardless of your situation is the sure move.
Affected versions and what to do now
The response is simple: update Style Dictionary to the fixed version or later. Even if you did not install it directly, other tools may depend on it internally, so check your whole dependency tree.
| Item | Detail |
|---|---|
| Package (npm) | style-dictionary |
| Affected versions | 4.3.0 up to < 5.4.4 |
| Fixed version | 5.4.4 or later |
| Location | convertTokenData (with output: 'object') |
If you cannot update right away, you can protect yourself temporarily by checking the tokens you feed the build for dangerous key names like __proto__ and rejecting them before processing. The advisory itself offers a workaround that scans token keys before processing and refuses matches. Fundamentally, the basic defense against this class of bug is to never use outside values directly as object keys or load paths.
A vulnerability hiding in an open-source component you pulled in is not unique to Style Dictionary. We have covered the same prototype pollution in the i18next localization library (CVE-2026-48713 / 48714), and the case where malware was slipped into axios, a package with 100 million weekly downloads. Knowing which component and version your app depends on is what lets you move fast when a fix lands. For npm or Python dependencies, our OSS vulnerability scanner lets you paste and check for known flaws.
Exploitation status and what to watch
As of June 2026, there are no reports of CVE-2026-54639 being used in real attacks, and it is not listed in CISA's KEV catalog, the U.S. government's list of vulnerabilities known to be exploited. You can track the latest on actively exploited flaws in our CISA KEV dashboard.
Prototype pollution is a familiar technique for attackers, and it automates easily wherever there is an entry point for the pollution to take hold. Because Style Dictionary is built into many projects as the foundation of a design system, setups that handle third-party tokens face a wide blast radius once exploitation begins. With a fix already available, updating your dependency now is the surest defense.
Summary
CVE-2026-54639 in Style Dictionary is a prototype pollution flaw: because token keys were not validated, an attacker can rewrite JavaScript's master blueprint. It is not the kind of flaw you can hit unconditionally from outside a web app; it requires malicious tokens to be processed during a build. That is why the risk depends on where your tokens come from.
What to do is not hard. First, update Style Dictionary to 5.4.4 or later. If you cannot bump it right away, check the tokens you process for dangerous key names like __proto__ before use. And if your setup handles tokens received from outside, revisit how you validate that input. That is enough to avoid exposure. Even teams that only handle their own tokens should check their version once, just in case.
Sources
- ▸ Style Dictionary - Official security advisory GHSA-vj5c-m527-mpff (Prototype Pollution in convertTokenData)
- ▸ NVD - CVE-2026-54639
- ▸ Style Dictionary - Fix PR #1702 (repro test and patch)
- ▸ Style Dictionary official site
- ▸ MITRE - CWE-1321: Prototype Pollution
- ▸ CISA - Known Exploited Vulnerabilities Catalog