Style Dictionaryにビルド汚染の脆弱性 CVE-2026-54639、5.4.4へ更新を
デザインの色や余白を一括管理する開発ツール『Style Dictionary』に、危険度8.8の脆弱性CVE-2026-54639。細工したデザイントークンを読み込ませると、アプリ共通の土台が書き換わり、ビルド汚染やサービス停止に連鎖する恐れがあります。対象は4.3.0〜5.4.3。修正版5.4.4への更新方法と、本当に注意すべき人を解説します。
堀川 慎
Backend Engineer / AWS / Django / Go
デザインの色や余白を一括管理する開発ツール『Style Dictionary』に、危険度8.8の脆弱性CVE-2026-54639。細工したデザイントークンを読み込ませると、アプリ共通の土台が書き換わり、ビルド汚染やサービス停止に連鎖する恐れがあります。対象は4.3.0〜5.4.3。修正版5.4.4への更新方法と、本当に注意すべき人を解説します。
アプリの色・余白・文字サイズといった「デザインの決まりごと」を一か所で管理し、CSSやアプリのコードへ自動変換する開発ツール「Style Dictionary」に、危険度8.8の脆弱性が見つかりました。番号はCVE-2026-54639です。細工したデザイントークン（色や余白の定義データ）を読み込ませると、JavaScriptの全オブジェクトが受け継ぐ大本の設計図が書き換わり、ビルドの汚染やサービス停止、場合によってはサーバー上でのコード実行にまで連鎖する恐れがあります。
Style DictionaryはもともとAmazonが公開し、現在は有志が引き継いで開発しているオープンソースで、デザインシステムを運用するフロントエンド開発の現場で定番として使われています。脆弱性は内部のconvertTokenDataという変換処理にあり、6月8日に公式アドバイザリ（GHSA-vj5c-m527-mpff）として公表されました。修正版は5.4.4です。
ただし、これはWebサイトのURLを叩くだけで誰でも踏める種類の穴ではありません。あくまで悪意あるトークンデータをビルド工程で処理させることが前提になります。だからこそ「誰が、どんな状況で危ないのか」を切り分けて理解することが大切です。この記事では、何が起きるのか、本当に注意すべきなのは誰か、いま何をすればよいのかを順に整理します。
Style Dictionaryと「プロトタイプ汚染」とは
Style Dictionaryは、デザインの基準値を「デザイントークン」という形でまとめて持っておき、それをCSS変数・Sass・iOSのSwift・AndroidのXMLなど、各環境向けのコードへ一括変換する道具です。たとえば「ブランドの青は#0066cc」「基準の余白は8px」といった値を一度だけ書いておけば、Web・iOS・Androidのすべてに同じ値が行き渡る、というのが売りです。アプリの画面上で動くのではなく、開発者の手元やCIサーバーのビルド工程で動くのが特徴です。
今回の弱点の種類はプロトタイプ汚染（CWE-1321）です。JavaScriptのオブジェクト（データのかたまり）は、共通の親から性質を受け継ぐ仕組みになっています。この「親」にあたる大本（おおもと）の設計図に勝手な値を書き込まれると、その後に作られるあらゆるオブジェクトが、汚された設計図を引き継いでしまうのがプロトタイプ汚染です。被害が一か所で完結せず、プログラム全体の前提が静かにずれていく点が厄介です。
きっかけになるのは、外から来た文字列が、そのままオブジェクトのキー（見出し）として使われる場面です。トークンの定義に __proto__ のような特別な意味を持つ名前を混ぜておくと、本来は値を書き込むだけのつもりの処理が、大本の設計図への書き込みにすり替わってしまいます。
誰が、何を狙うのか
この穴は、公開中のアプリに外から総当たりで攻め込む類いのものではありません。Style Dictionaryは画面の裏で動くのではなく、デザイントークンをコードへ変換する「ビルドの工程」で動く道具だからです。狙えるのは、そのビルドに細工したトークンデータを紛れ込ませられる立場の人——たとえば外部から取り込むトークンファイルや配布部品をすり替えられる者、多くの人がトークン定義を投稿できる仕組みに悪意ある一行を送り込める参加者です。
こうした相手は、トークンのキー名に __proto__ を仕込んだデータを用意し、Style Dictionaryにそれを読み込ませて変換させることで、JavaScriptの全オブジェクトが受け継ぐ大本の設計図を書き換えます。書き換わるのは特定の1件のトークンではなく、ビルドを動かしているNode.jsのプロセス全体が前提として参照している共通の土台です。一度ここに手を入れられると、影響はそのプロセスで動く処理すべてに及びます。
ビルドを回す開発チームにとっては、出力されるCSSやコードを信用できなくなること自体が損失です。汚された前提のままビルドが進めば、生成物に意図しない値が混ざったり、型の取り違えでビルドが落ちたり、同じプロセスで動く別の処理と噛み合ってサーバー上でのコード実行に発展する恐れもあると報告されています。しかもその生成物は、デザインシステムを通じてその先のすべてのアプリと利用者へ配られます。CVSSの8.8という数字以上に怖いのは、「自分たちのデザインの大本は、自分たちだけが決めている」という当たり前が崩れることです。
技術的に見ると：convertTokenDataのどこが穴だったか
問題があったのは、トークンの並びを扱いやすい形に変換する内部関数 convertTokenData() です。公式アドバイザリによると、output: 'object' を指定してトークンの配列をオブジェクトへまとめ直すとき、キーの文字列を検証せずにそのまま使っていました。そのため、次のように __proto__ を含むキーを持つトークンを渡すと、大本の設計図が汚染されます。
// 細工したトークンの例
[{ key: '{__proto__.polluted}', value: 'malicious' }]
// 変換後、すべてのオブジェクトで {}.polluted が "malicious" を返すようになる
深刻度はCVSS v3.1で8.8と評価されています。最高の9点台に届かないのは、攻撃元が「ローカル」、つまり悪意あるトークンをビルドに処理させる必要があり、外から無条件に踏めるわけではないことが反映されているためです。一方で、汚染が大本の設計図というプログラム共通の土台に及び（影響範囲が「変更あり」と評価）、機密性・完全性・可用性のすべてに高い影響が出ると見積もられたため、ローカル起点でも8.8という高い値になっています。この問題はバージョン4.3.0で混入し、報告を受けて5.4.4で修正されました。修正版では __proto__ を含むトークンキーは無視されます。
本当に注意すべきなのは誰か
ここが今回いちばん大事なところです。Style Dictionaryを使っていても、危険度はトークンがどこから来るかで大きく変わります。
| あなたの使い方 | 実際の危険度 | やること |
|---|---|---|
| 自分たちで書いた トークンだけを ビルドしている | 低い | 念のため5.4.4へ更新 |
| 外部・第三者から来る トークンを取り込んで ビルドする | 高い | 至急5.4.4へ更新 ＋入力の検証 |
| トークンの変換を サービスやプラグインとして 外部に提供している | 高い | 至急5.4.4へ更新 ＋入力の検証 |
つまり、社内の信頼できるメンバーだけがトークンを書き、それをそのままビルドしているなら、実際に踏まれる可能性は高くありません。一方で、トークンを外部から受け取って処理する場面がある人ほど危険です。具体的には、トークン変換をサービスとして提供しているプラットフォーム、外部のテーマやプラグインからトークンを読み込む仕組み、不特定多数の貢献者がトークン定義を投稿できるモノレポやOSSなどが該当します。CVSSが「ローカル・低権限が必要」と評価しているのは、この前提を反映したものです。とはいえ修正自体は簡単なので、状況にかかわらず更新しておくのが確実です。
対象バージョンと、いますぐやるべきこと
対応はシンプルで、Style Dictionaryを修正版以降へ更新することです。直接導入していなくても、ほかのツールが内部で依存していることがあるため、依存ツリー全体を確認してください。
| 項目 | 内容 |
|---|---|
| 部品（npm） | style-dictionary |
| 影響を受ける版 | 4.3.0 以上 5.4.4 未満 |
| 修正版（即更新） | 5.4.4 以降 |
| 問題の箇所 | convertTokenData （output: 'object' 指定時） |
すぐに更新できない事情がある場合は、ビルドに渡すトークンのキーに __proto__ などの危険な名前が混ざっていないかを、処理の前にチェックして弾く方法でも一時的に身を守れます。アドバイザリでも、トークンを処理する前にキーを走査して該当するものを拒否する回避策が示されています。根本的には、外から来る値をそのままオブジェクトのキーや読み込みパスに使わないのが、この種の問題への基本的な備えになります。
外部から取り込んだ部品（OSS）に脆弱性が潜む問題は、Style Dictionaryに限った話ではありません。本サイトでも、同じプロトタイプ汚染が見つかった多言語化ライブラリi18nextの脆弱性（CVE-2026-48713／48714）や、週間1億ダウンロードのaxiosにマルウェアが混入した事案を取り上げてきました。自分のアプリがどの部品のどのバージョンに依存しているかを把握しておくことが、修正が出たときに素早く動く前提になります。npmやPythonの依存であれば、本サイトのOSS脆弱性スキャナーに貼り付けるだけで、既知の脆弱性が含まれていないかを確認できます。
悪用状況と、いま見ておくべきこと
2026年6月時点で、CVE-2026-54639が実際の攻撃に使われたという報告はなく、米政府機関が攻撃に悪用されている脆弱性をまとめるCISAのKEVカタログにも登録されていません。攻撃に悪用されている脆弱性の最新状況は、本サイトのCISA KEV日本語ダッシュボードでまとめて確認できます。
プロトタイプ汚染は攻撃者にとって手慣れた手口で、汚染が成立する入口さえあれば自動化しやすいのが特徴です。Style Dictionaryはデザインシステムの土台として多くのプロジェクトに組み込まれているため、第三者由来のトークンを扱う構成では、悪用が始まったときの影響範囲が広くなります。修正版が出ている今のうちに依存を更新しておくのが、最も確実な防御です。
まとめ
Style Dictionaryに見つかったCVE-2026-54639は、トークンのキーを検証していなかったことで、JavaScriptの大本の設計図を書き換えられてしまうプロトタイプ汚染です。Webアプリを外から無条件に踏める種類のものではなく、悪意あるトークンをビルドで処理させることが前提になります。だからこそ、危険度は「トークンがどこから来るか」で変わります。
やるべきことは難しくありません。まずStyle Dictionaryを5.4.4以降へ更新する。すぐに上げられないなら、トークンのキーに __proto__ のような危険な名前が混ざっていないかを処理前にチェックする。そして、外部から受け取るトークンを扱う構成なら入力の検証を見直す。これで影響は避けられます。自分たちで書いたトークンだけを扱っているチームも、念のため一度バージョンを確かめておくと安心です。