2026年6月、無印良品・ディスクユニオン・東芝など複数の企業サイトで、「不審な認証画面」が表示される事象が相次いで公表されました。ログイン窓のような画面が突然現れ、ユーザー名やパスワードを入力すると、その情報が抜き取られてしまう――というものです。
注目すべきは、その原因が「各社が自分で書いたコード」ではなかった点です。引き金になったのは、サイトに昔から組み込まれていた外部ライブラリ「polyfill.io」――いわば、便利だからと挿しっぱなしにしていた外部の部品でした。
つまり今回の事象は、「自社サイトの管理を一生懸命やる」という発想だけでは防ぎきれなかった、という構造的な問題を示しています。本記事では、何が起きたのかを整理したうえで、認証の考え方そのものを一段ずらす視点をご紹介します。
何が起きたのか――「外部の部品」が裏切った
polyfill.io(ポリフィル・アイオー)は、古いウェブブラウザーでも新しい機能が動くように不足分を補う、オープンソースのJavaScriptライブラリ(ウェブサイトを動かすための部品)です。多くのサイトが、ユーザーの古い環境に対応するために組み込んでいました。
ところが2024年2月、このドメインが別の事業者に譲渡されます。同年6月にはセキュリティ企業Sansecが、polyfill.ioのCDN(配信網)が悪質なコードを配信し、スマホからのアクセスを不正なサイトへ誘導していると報告しました(2024年時点)。開発者自身も「polyfill.ioはもう不要なので、使っているならすぐ削除を」と呼びかけていたほどです。
それでも削除されずに残っていたサイトで、今回の「偽の認証画面」が表示されたとみられています。画面に入力された資格情報(ユーザー名やパスワード)を、そのまま盗み取る――というのが、この攻撃の狙いです。
なぜ「自社の管理を頑張る」だけでは止まらないのか
ここで一度、たとえ話で整理してみます。今回の事象は、「自宅の鍵を盗まれた話」ではありません。「玄関とは別に、いつの間にか他人が作った勝手口があり、そこから入られていた話」に近いのです。
polyfill.ioは、自社が直接書いた玄関の鍵ではなく、外から持ち込んで挿しっぱなしにしていた外部パーツでした。こうした「供給網(サプライチェーン)汚染」――部品を経由した攻撃――では、自社のパスワード管理をどれだけ強化しても、勝手口そのものは塞げません。
パスワードの桁数を増やす、定期的に変更させる、SMS認証(ショートメッセージで送る確認コード)を足す。こうした対策は「鍵を強くする競争」です。しかし鍵を強くしても、その鍵が「偽の鍵穴」に差し込まれてしまえば意味がありません。偽の認証画面とは、まさにこの偽の鍵穴です。
発想を変える――「鍵穴」をなくし、認証を「正規サイトの目印」にする
そこで考え方を一段ずらします。鍵を強くし続けるのではなく、「奪われる対象」そのものをなくす、という方向です。
パスワードやSMSのコードは、ユーザーが画面に「入力する」情報です。入力する情報は、偽の画面さえ用意すれば奪えます。一方で、「電話をかける」という行為は、偽サイト側が真似できません――偽サイトは、あなたの電話回線を持っていないからです。
ここに、今回のテーマと直結する大事なポイントがあります。電話発信による認証が普段から導入されていれば、その認証が入っていること自体が「正規サイトの目印」になるのです。
普段から電話でログインしているお客様は、ある日突然「パスワードを入力してください」「SMSのコードを入れてください」と求められたら、違和感を覚えます。「いつもの電話認証じゃないぞ」と。つまり、いつもの認証体験そのものが、ユーザー自身による偽サイトの見分け役になります。逆に、弱いパスワード認証やSMS認証しか使っていないサイトでは、偽画面が出ても「いつも通り」に見えてしまい、ユーザーは正規サイトと勘違いしてしまうのです。
参考までに、主な認証方式を比べると次のようになります。SMS認証はマルウェアによる突破例があり、米国のNIST(国立標準技術研究所)も非推奨としています。パスキー(パスワードレスの新しい認証)はフィッシング耐性が高い一方、初期登録のハードルが高いという課題があります。
「そもそも狙われない」状態をつくる
もう一つ、見落とされがちな効果があります。フィッシング(偽サイトへ誘導して情報を盗む手口)を仕掛ける不正者は、合理的に「割に合うかどうか」を計算しています。
偽サイトを作り、メールやSMSで誘導し、ユーザーをだます――この一連の手間をかけても、奪えるのが「電話発信でしか通らない認証」だとしたら、盗んだパスワードは使えません。費用対効果が合わなくなれば、不正者はわざわざそのサイトを狙わなくなります。
強い鍵を見せること自体が、泥棒に「ここは割に合わない」と思わせる。電話発信による認証が入っているという事実は、ユーザーへの安心材料であると同時に、不正者に対する「狙う価値のない入口」というメッセージにもなるのです。
Infront Securityがどう解決するか
Infront Securityの電話発信認証は、ここまで述べてきた発想を、そのまま実装したものです。
仕組みはシンプルです。ユーザーがログイン画面でワンタップすると、スマホから指定番号へ自動で1コール発信されます(通話料無料・約1秒)。発信者番号と端末情報をサーバー側で照合し、本人確認が完了します――企業からユーザーに電話をかけるのではなく、ユーザー自身が発信する方式です。2回目以降は、同じ端末なら端末認証だけで完了します。
この方式は、インターネット網ではなく通信キャリアが管理する電話網を経由します。偽サイトは電話回線を持てないため、フィッシングに対して高い耐性があります。実際、不正利用率はほぼ0%という実績があります。
しかも、ユーザーが発信するためSMSのような企業側の送信コストがかからず、操作は「電話をかける」だけ。18歳から80歳まで、説明不要で使える点も特長です。導入はAPI連携が前提で、今のシステムを壊さずに裏側で動かせます。最短8週間でのPoC(概念実証)も可能です。
まとめ
今回のpolyfill.io経由の偽認証画面は、「自社サイトの管理を頑張る」だけでは防ぎきれない、供給網由来のリスクを浮き彫りにしました。
鍵を強くし続ける競争から降りて、奪われる対象であるパスワードそのものをなくす。さらに、電話発信による認証を「正規サイトの目印」として定着させることで、ユーザーは偽サイトに気づきやすくなり、不正者は狙う動機を失います。
Infront Securityがこの考え方を自社サイトでどう実装できるか、業種別の試算やより詳しい技術解説をご用意しています。ご関心のある方は、ホワイトペーパーのダウンロード、またはお問い合わせよりお気軽にご連絡ください。