polyfill.io 攻撃まとめ【時系列＋対策】2024年のサプライチェーン攻撃から2026年の認証ダイアログ問題まで

2026年5月末から6月にかけて、無印良品（良品計画）・東芝・象印マホービンなど複数の日本企業のサイトで「polyfill.io がユーザー名とパスワードを要求する不審なダイアログ」が表示され、各社が相次いで注意喚起を出しました。原因は、2024年に大規模なサプライチェーン攻撃の舞台となった polyfill.io を、いまだサイトに残したままにしていたことです。

この記事では、事件の経緯を時系列で整理し、ユーザー・サイト運営者それぞれの対策までまとめます。

polyfill.io とは

polyfill.io は、古いブラウザでも最新の JavaScript 機能を使えるようにする「polyfill（補完コード）」を、CDN 経由で自動配信する人気サービスでした。`<script src="https://cdn.polyfill.io/...">` のように1行追加するだけで使えるため、世界中の多くのサイトが導入していました。

その「多くのサイトが信頼して読み込んでいる」という性質こそが、後にサプライチェーン攻撃の標的になった理由です。

時系列で見る経緯

① 2024年2月：ドメインとGitHubが買収される

中国企業とされる Funnull が、polyfill.io のドメインと GitHub アカウントを買収。これを受けて polyfill の原作者（Andrew Betts 氏）や Cloudflare・Fastly が「もう polyfill.io を使うべきではない」と警告しました。この時点では、まだ実害より「危険な兆候」の段階でした。

② 2024年6月25日：悪用が発覚（大規模サプライチェーン攻撃）

セキュリティ企業 Sansec が、`cdn.polyfill.io` から悪意あるコードが注入されていることを公表。判明した手口は巧妙でした。

• モバイル端末を狙い撃ち（PCや管理者には反応しにくい）

• 管理者の閲覧時やWeb解析ツール検知時は発動を回避して、気づかれにくくする

• 偽のGoogle Analyticsドメインを経由し、詐欺・ギャンブル・アダルトなどの不正サイトへリダイレクト

影響を受けたサイトは 10万件以上（一部報道では最大38万件規模）とされました。

③ 2024年6月〜：各社が緊急対応

• ドメイン登録元の Namecheap がドメインを一時停止

• Cloudflare・Fastly が安全なミラー（代替CDN）を提供

• Google が影響サイトの広告を一部ブロック

• 関連して CVE-2024-38526 が採番（※これは polyfill を同梱していた `pdoc` 等に対するCVEで、ドメイン乗っ取りそのものを指すものではありませんが、本件の識別子として広く使われています）

④ その後：北朝鮮の関与が指摘される

当初は中国系企業の関与とされていましたが、後の調査で北朝鮮の脅威アクターとの関連が指摘されました。リダイレクト先のギャンブル事業を通じた暗号資産のマネーロンダリングが目的だった、との分析もあります（※この帰属は調査ベースで、確定情報ではありません）。

⑤ 2026年5月21日：ドメインが再稼働の可能性

polyfill.io のドメインが Namecheap から GoDaddy へ移管され、元の登録日を保持したまま再びオンラインになった可能性が報告されました。

⑥ 2026年5月末〜6月：放置サイトで認証ダイアログが多発

2024年以降も polyfill.io を削除せず放置していたサイトで、ページを開くと「polyfill.io がユーザー名とパスワードを要求する」という不審なダイアログが表示される事象が続発。日本でも複数の企業・団体が公表しました。

• 注意喚起を出した主な企業：良品計画（無印良品）／東芝／リクルートマネジメントソリューションズ／象印マホービン、ほか医歯薬出版・FiNC Technologies・ほぼ日 など

• ダイアログ表示が確認されたサイト例：三井ショッピングパーク関連施設、オートバックス公式通販、音声合成ソフト VoiSona など（いずれもその後修正）

• 2026年6月4日には ITmedia などが報道

各社は「入力しないように」と呼びかけており、現時点で情報漏えいは確認されていませんが、入力すると認証情報を盗まれる危険があります。

「不審なダイアログ」の正体（仕組み）

2026年に話題の画面は、サイトが作った偽ログインフォームではなく、ブラウザ標準の HTTP BASIC認証（401）ダイアログです。流れは次の通りです。

1. サイトのHTMLに `polyfill.io` を読み込むコードが残ったままになっている

2. ページを開くとブラウザが polyfill.io へアクセスする

3. 移管・再稼働後の polyfill.io が 「ユーザー名とパスワードを要求する応答（401）」 を返す

4. その結果、閲覧者の画面にブラウザ純正の認証ダイアログが突然ポップアップする

正規サイト上に出るため本物のログイン要求に見えますが、サイト運営者が用意したものではありません。2024年の経緯を踏まえれば、放置された外部スクリプトはいつ悪意あるコードを再配信してもおかしくない状態であり、危険信号と捉えるべきです。

対策

ユーザー（閲覧者）側

• 突然「ユーザー名／パスワード」を求めるダイアログが出たら、何も入力せず閉じる。URL欄やダイアログに `polyfill.io` の表示がないか確認する

• もし入力してしまったら、そのサービスのパスワードを即変更。同じパスワードを使い回している他サービスもすべて変更し、可能なら二段階認証（2FA）を有効化する

• uBlock Origin などのブラウザ拡張で `polyfill.io` をブロックしておくと、放置サイトを開いても読み込みを防げる

サイト運営者側

• サイト・テンプレート・CMSのテーマ/プラグイン・依存パッケージを横断して `polyfill.io` を検索し、該当コードを即削除（`grep -r "polyfill.io"` 等で全体を点検）

• どうしても polyfill が必要なら、自前ホスティング、または Cloudflare（cdnjs）/Fastly の安全な代替へ移行。なお現代の主要ブラウザでは polyfill 自体が不要なケースも多く、そもそも撤去を検討する価値がある

• CSP（Content-Security-Policy） で読み込み元を制限し、SRI（Subresource Integrity） で外部スクリプトの改ざんを検知する仕組みを導入する

• 表示が確認された場合は、影響範囲を調査し、情報漏えいインシデントに準じて対応・利用者へ告知する

• この機会に、他の外部スクリプト依存（広告・解析・チャットツール等）も棚卸しする

まとめ：これは「サプライチェーン攻撃」の典型例

polyfill.io 事件の本質は、信頼して読み込んでいた外部サービスが、所有者交代によって一夜にして攻撃インフラに変わったことにあります。自分のサイトのコードは無事でも、読み込んでいる外部スクリプトが汚染されれば、利用者が被害を受けます。

2026年の認証ダイアログ騒動は、「2024年に危険と分かっていたものを削除せず放置すると、後から再び牙をむく」ことをはっきり示しました。外部スクリプトへの依存は最小限にし、CSP / SRI で守りを固め、不要になったものは確実に撤去する——それが最大の防御策です。

タグ案

#polyfillio #サプライチェーン攻撃 #Web セキュリティ #情報セキュリティ #CDN #フロントエンド #セキュリティ対策

本記事は公開情報（Sansec、Qualys、Akamai、Kaspersky 等のセキュリティ各社、ITmedia NEWS、各社公式告知、Zenn/Qiita の技術解説など、2026年6月時点）に基づき作成しています。北朝鮮関与などの帰属情報は調査ベースであり、確定情報ではありません。最新状況は各社の公式発表もあわせてご確認ください。