🕸️

polyfill.io のBASIC認証ダイアログが出た — 消し忘れた参照が教えてくれること

に公開
Security
frontend
CDN
Polyfill
Supply Chain
tech

はじめに：買い物しようとしたら知らないドメインがパスワードを要求してきた

ある大型商業施設の情報を見ようと公式サイトを開いたら、いきなりこんなダイアログが出てきました。

ログイン
https://polyfill.io にはユーザー名とパスワードが必要です。
ユーザー名 ／ パスワード

URLバーにはその施設の正規ドメイン、画面には施設や運営グループのロゴ。なのに、ログインを要求してきているのは polyfill.io という、まったく別のドメインです。

polyfill.io という文字列に見覚えがある人は、ここでヒヤッとしたはずです。これは2024年にサプライチェーン攻撃でマルウェア配信の踏み台にされ、その後ドメインが停止された、いわく付きのドメインだからです。

本来どこにも繋がらないはずのドメインが、大手商業施設の公式サイト経由でパスワードを要求してくる。この記事では、特定の事業者を名指しすることはせず、一般化した事例として、

  • そもそも polyfill.io 事件とは何だったのか
  • なぜ「BASIC認証ダイアログ」が出るのか（技術的な仕組み）
  • これは危険なのか、何が問題なのか
  • 自分のサイトが同じ状態になっていないか確認する方法

を整理します。

polyfill.io 事件とは何だったのか

Polyfill とは

そもそも「Polyfill（ポリフィル）」とは、古いブラウザに新しいJavaScript/Web APIの機能を補う埋め草コードのことです。Promise や fetch などをサポートしていないブラウザでも、Polyfill を読み込めば動くようにする、という仕組みです。

polyfill.io は、アクセスしてきたブラウザの種類を判定して、そのブラウザに足りない機能だけを返してくれる便利なCDNサービスでした。もともとは大手メディア企業のエンジニアが作った、由緒正しいオープンソースのサービスです。多くのサイトが、こう書くだけで導入できました。

<script src="https://cdn.polyfill.io/v2/polyfill.min.js"></script>

手軽さゆえに、世界中の10万以上のサイトに埋め込まれていました。

2024年2月：ドメインが売却される

ここが運命の分かれ道でした。2024年2月、polyfill.io のドメインとGitHubアカウントが ある中国系の事業者に売却されます。

オリジナルの作者は「自分はこのドメインを所有したことはないし、今のサービスは自分とは無関係だ。Polyfill への参照はすべて削除すべきだ」と警告を出しました。便利なサービスの運営主体だけがこっそり入れ替わったわけです。利用者から見ればURLは何も変わっていません。これがサプライチェーン攻撃の怖いところです。

2024年6月：マルウェア配信が発覚

2024年6月25日、あるセキュリティ企業が、cdn.polyfill.io が悪意のあるコードを配信していることを発見します。確認されている挙動はおおむね次の通りです。

  • 配信されるJavaScriptに、利用者を詐欺サイト・賭博サイトへリダイレクトするコードが仕込まれていた
  • モバイル端末を狙い撃ちし、特定の条件でのみ発動
  • 管理者ユーザーを検知すると発動しない、実行を遅延させるなど、解析・検知を回避する高度な作り
  • HTTPヘッダーに応じてペイロードを動的に生成

<script> で読み込まれたJavaScriptは、そのページと同じ権限で動きます。つまり、埋め込んだサイト側からすれば、自分のページ内で攻撃者のコードが好き放題に実行できる状態でした。影響を受けたサイトには誰もが名前を知る大手サービスも含まれ、調査時点で10万以上のサイトが影響下にあったとされています。

2024年6月27日：ドメイン停止

事態を受けて、当時のレジストラが polyfill.io ドメインを停止（clientHold ステータスに設定）しました。これによりドメインはDNS上で名前解決されなくなり、即時の脅威は緩和されました。大手CDN事業者各社も、安全なミラー（cdnjs など）を提供し、リダイレクトする救済策を打ち出しています。

時期 できごと
〜2024年2月 原作者由来の正規CDNサービスとして稼働
2024年2月 ドメイン／GitHubが中国系の事業者に売却
2024年6月25日 セキュリティ企業がマルウェア配信を発見
2024年6月27日 レジストラがドメインを停止（clientHold）
2026年3月（報道） 一連の攻撃を北朝鮮系アクターに関連付ける続報

つまり polyfill.io は、**2024年6月末の時点で「本来どこにも繋がらないはずのドメイン」**になっていたわけです。

筆者の一次観測（2026年5月〜6月）

ここからは確定情報ではなく、WHOIS や Wayback Machine を見ながら追った観測です。鼻をほじりながら眺めていた、程度の精度だと思って読んでください。

  • 2026年5月5日ごろ、polyfill.io のレジストラが突如 別のレジストラに変わっているのを確認
  • その2日後ごろ、Wayback Machine 側に「access requires authorization」で取得拒否されたログが残っている（＝少なくともHTTPは疎通している様子）
  • その後5月30日ごろまで、何らかのサイト（真偽不明）が確認できた
  • 5月31日ごろから、polyfill.io が BASIC認証を要求している（＝冒頭のダイアログ）

停止されていたはずのドメインのレジストラが変わり、再びHTTPが応答を返している。この状態を「不気味」と感じたのが、この記事を書いた動機です。

なぜ「BASIC認証ダイアログ」が出るのか

ここが技術的に面白いところです。なぜ買い物サイトを開いただけで、別ドメインのログイン画面がポップアップするのでしょうか。

仕組み

そのサイトのHTMLには、いまだに次のようなpolyfill.io への参照が残っていると考えられます。

<script src="https://polyfill.io/v3/polyfill.min.js"></script>

ブラウザはページを描画する過程で、この <script> を読みに polyfill.io へHTTPリクエストを飛ばします。このとき、現在の polyfill.io のサーバーが次のようなレスポンスを返していると、

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="..."

ブラウザは「このリソースはBASIC認証が必要だ」と解釈し、ユーザー名／パスワードの入力ダイアログを表示します。これが冒頭のダイアログの正体です。<script> や <img> などのサブリソースであっても、401 + WWW-Authenticate: Basic が返ればブラウザは認証ダイアログを出します。

つまりこのダイアログは、

  1. サイト側に polyfill.io への参照がまだ残っている
  2. 今の polyfill.io が 401 BASIC認証を返している

という2つが噛み合って初めて出ます。「サイトが polyfill.io をまだ参照している」という事実を、ブラウザが図らずも可視化してくれているわけです。

これは危険なのか

論点を2つに分けて考えます。

論点1：このBASIC認証ダイアログ自体

ここに何かを入力してはいけません。 ダイアログには https://polyfill.io と書かれており、入力した認証情報は（そのサイトの運営企業ではなく）現在 polyfill.io を保持している誰かに送られます。今のドメインの管理者が誰なのかは不透明で、フィッシングに悪用される可能性があります。

ただし、401で止まっている限り、JavaScriptが実行されているわけではありません。「キャンセルを押して無視する」のが正しい対応で、これ自体で即座に何かに感染するものではありません。

論点2：そもそも参照が残っていること（こちらが本質）

より深刻なのはこちらです。今は401で止まっていますが、ドメインの管理者が変われば、いつでも200 OKで悪意あるJavaScriptを返せる状態だということです。

今:  polyfill.io → 401（ダイアログが出るだけ、JSは実行されない）
↓ 管理者の気が変わったら / 別の悪意ある第三者が取得したら
最悪: polyfill.io → 200 + 悪意あるJS（ページ内で任意コード実行）

サイト側に <script src="https://polyfill.io/..."> が残っている限り、ドメインの向こう側を誰が握るかに、自サイトの安全性を委ねている状態です。2024年の事件はまさにこの「向こう側が悪意を持った」ケースでした。レジストラが移管され、再びHTTPが応答を返し始めた今、参照を残しておく理由は何もありません。

ダイアログが出る／出ないにかかわらず、polyfill.io への参照は即削除すべき、というのが結論です。これは2024年から専門家が一貫して呼びかけていることでもあります。

自分のサイトが同じ状態になっていないか確認する

「うちは大丈夫」と思っていても、過去のテンプレートやサードパーティのウィジェット、古いライブラリ経由で紛れ込んでいることがあります。確認は数分で終わります。

1. ソース内を grep する

リポジトリ全体を検索します。

# polyfill.io への参照を全文検索
grep -rn "polyfill.io" . --include="*.html" --include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx" --include="*.vue" --include="*.php"

ヒットしたら、その <script> タグや読み込み処理を削除します。本当に古いブラウザ対応が必要なら、core-js など信頼できる代替を自分でバンドルするのが安全です。

2. ブラウザのDevToolsで実際の通信を見る

ソースに直接書いていなくても、タグマネージャや外部ウィジェット経由で読み込まれていることがあります。本番サイトを開いて確認します。

  1. DevTools を開く（F12）
  2. Network タブを開いてページをリロード
  3. フィルタに polyfill と入力

ここに polyfill.io へのリクエストが現れたら、参照が残っています。どの読み込み元（Initiator）から呼ばれているかも追えます。

3. CSP で「そもそも読み込ませない」防御を入れる

恒久対策として、Content Security Policy で許可するスクリプト配信元をホワイトリスト化しておくと、未知の polyfill.io 的なものをブラウザレベルでブロックできます。

Content-Security-Policy: script-src 'self' https://trusted-cdn.example.com;

加えて、外部CDNを使うなら SRI（Subresource Integrity） でハッシュを固定し、中身が差し替わったら読み込まない設定にしておくのが定石です。

<script
  src="https://trusted-cdn.example.com/lib.js"
  integrity="sha384-..."
  crossorigin="anonymous"></script>

ただしSRIは、polyfill.io のようにリクエストごとに中身が変わるサービスには原理的に付けられません。「SRIを付けられないCDN」は、それだけで信頼の前提が崩れやすいと考えてよいでしょう。

まとめ

  • polyfill.io は2024年に運営主体が入れ替わり、サプライチェーン攻撃でマルウェア配信に使われ、ドメインが停止された経緯を持つ
  • 大手商業施設の公式サイトを開いた際に出た「polyfill.io のBASIC認証ダイアログ」は、サイト側に参照が残ったままで、かつドメインが401を返しているために発生する
  • ダイアログに認証情報を入力してはいけない。が、本質的な問題は危険なドメインへの参照を消し忘れていること
  • 今は401でも、ドメインの向こう側を誰が握るかは不透明。200で悪意あるJSが返ってくる日が来てもおかしくない
  • 自サイトは grep とDevToolsで数分で確認できる。見つけたら即削除、恒久対策にCSP/SRIを

便利なものほど、たくさんのサイトに深く根を張ります。そして根を張ったぶんだけ、運営主体が入れ替わったときの被害は広がります。「便利なCDNを <script> 一行で読み込む」という行為は、そのドメインの未来の所有者すべてを信頼することだ、というのが polyfill.io 事件の教訓です。ある商業施設のサイトで出たあのダイアログは、その教訓がまだ生きていることを、利用者に向けて思い出させてくれたのでした。

参考記事・データ

Discussion