Style Dictionary: 5.4.4 Isn't Enough, Update to 5.5.1 (CVE-2026-54639)

Top/Articles/Style Dictionary: 5.4.4 Isn't Enough, Update to 5.5.1 (CVE-2026-54639)

NewsPublished June 24, 2026Last updated Aug. 18, 2026

Table of contents

Key takeaways

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.

[Correction, August 17, 2026] This article originally named 5.4.4 as the fix. That guard has since been shown to be bypassable. Update to 5.5.1 or later. See the next section.

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): convertTokenData did 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

Correction, August 17, 2026: 5.4.4 Does Not Fix This. Go to 5.5.1

The version this article originally pointed to as the fix, 5.4.4, is no longer sufficient. On August 7, 2026 a second advisory (GHSA-xmr7-549p-98w3) revealed that the guard added in 5.4.4 can be bypassed. Version 5.5.1, released the same day, is the first build we can call safe as of August 17, 2026. We regret the earlier guidance and are correcting it here.

The bypass is simple. The 5.4.4 guard rejected any token key containing the literal string __proto__. But JavaScript offers a second route to the same place: constructor.prototype. That string does not contain __proto__, so it walks straight past the check. The reporter is Zerotistic and the severity is CVSS 8.4. This second issue has not been assigned a CVE number yet.

5.5.1 changes the approach rather than adding another name to the blocklist. It builds the object with Object.create(null), so the container has no link to the shared prototype at all. With the route gone, no amount of creative naming reaches it.

Problem one: your tooling will not warn you

This is the part that bites in practice. The second advisory exists only inside the Style Dictionary repository. It has not been synced to the GitHub Advisory Database or to OSV — as of this writing those lookups return a 404 or no result.

So npm audit stays quiet. Dependabot stays quiet. Snyk stays quiet. Running 5.4.4 or 5.5.0 produces no alert from any of them. "The scanner is green" is not a valid answer for this one. Check the version number yourself.

Problem two: the official affected range says only 5.5.0

The second advisory lists the affected version as 5.5.0 alone. Read literally, that implies 5.4.4 is fine.

We pulled the published package sources and compared them. The relevant code in 5.4.4 and 5.5.0 is identical. 5.4.4 carries only the key?.includes('__proto__') string check (see 5.4.4); the switch to Object.create(null) first appears in 5.5.1 (see 5.5.1). The 5.5.0 release notes contain no change to this file.

This comparison is ours, not a statement from the maintainers — they have not said 5.4.4 is affected. The links above let you verify it yourself. We are treating 5.4.4 as potentially bypassable and recommending 5.5.1.

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.5.1 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.5.1 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.5.1 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

Revision History

•August 17, 2026: Correction. The 5.4.4 guard this article recommended can be bypassed, so the update target is now 5.5.1 or later. Added that the second advisory is not synced to vulnerability databases and therefore invisible to automated scanners, and that while the official affected range lists only 5.5.0, a source comparison shows 5.4.4 carries the same implementation. Title and description updated.
•June 24, 2026: Published