きっかけ

2026年3月31日の午前中に、 Axios という JavaScript のライブラリが、サプライチェーン攻撃を受け、多方面に甚大な影響を与えました。

技術的に詳しい話や、対応方法などについては、 GMO Flatt Security 社のブログ が詳しいです。

わたしも、ちょうどこの時間帯に、 Laravel というシステムを触っており、時間がちょっとでも違っていたら、この攻撃に巻き込まれていたと思うので、経緯をまとめておこうと思います。

サプライチェーン攻撃とは

そもそも、サプライチェーン（供給網）とは、経営学の用語です。
生産体制の分業化が進んだ現代社会では、商品や製品が手元に届くまでに、材料調達 -> 製造 -> 卸 -> 販売と、さまざまな利害関係者が、チェーン（鎖）のようにつながっています。

現代プログラミングにおいても同様で、現状、すべてのプログラムを、ゼロから書くことは、ほぼありません。
ほとんどの場合、何らかのフレームワークや、ライブラリを利用し、さらに、それらのフレームワークやライブラリもまた、別のライブラリを組み合わせて作られています。

すると、単機能の根本的なライブラリに、悪意のあるウイルス（やマルウェア、バックドアなど）が仕込まれれば、それらがチェーンをたどって、多くのライブラリへ波及するわけです。

今回の事件は、 Axios という非同期通信するためのライブラリの作者のアカウントが乗っ取られたようです。
Axios は、多くのライブラリに利用されており、3月25日から31日までの1週間のダウンロード回数が 83,064,067 回という人気のライブラリでした。

Laravel をセットアップしたら、 Axios がインストールされる

しかし、プログラミングに詳しい方は、不思議に思われたかもしれません。
Laravel といえば PHP のフレームワークであり、 Axios は JavaScript のライブラリです。
プログラミング言語が違うのに、どうしてサプライチェーンに組み込まれているのでしょうか？

私自身も、最初は Axios を使っていないので、今回の攻撃とは無関係だと思っていました。

ところが、 X(旧Twitter) などの情報で、 Laravel のセットアップ中に、 Axios がインストールされることを知りました。

具体的には、Laravel のセットアップの中に、以下のようなコマンドが含まれるのです。（composer.json に含まれます）

{
    "scripts": {
        "setup": [
            "composer install",
            "@php -r \"file_exists('.env') || copy('.env.example', '.env');\"",
            "@php artisan key:generate",
            "@php artisan migrate --force",
            "npm install",
            "npm run build"
        ]
    }
}

Laravel は、画面表示（フロントエンド）に JavaScript ライブラリを利用しており、上記の中の npm install を実行します。
これにより、間接的に Axios がインストールされる仕組みになっていました。

今回の経緯

私自身は、ちょうど 3月31日のお昼ごろ、上記スクリプトの setup を実行しました。

先ほど紹介した GMO Flatt Security の記事 によれば、攻撃が仕込まれたのが 3月31日09:21であり、削除されたのが、同日12:15だったため、今思えば、かなり危うい時間帯での実行でした。

そこで、上記に書かれている npm コマンドで確認を取り、攻撃の痕跡も確認しました。
すると、v1.14.0 であり、問題となるディレクトリや実行ファイルなども入っていませんでした。

本当に、運が良かったです。

アップデートは正しいのか？

セキュリティの世界では、「できるだけ早く最新版にアップデートしましょう」というのが鉄則でした。
実際、 WordPress などの脆弱性対応を見ても、随時アップデートできる体制を整えることは不可欠です。
つい先日も、わずか3日間（3月10日から13日）で、3回のマイナーアップデートが実施されたばかりです。

ところが、今回のサプライチェーン攻撃は、 最新版にウイルスが仕込まれました 。 アップデートに即座に追随することが、必ずしも正解とは限らないケースです。

結局のところ、盲目的にすべての更新を信じるのではなく、「迅速なアップデート」と「慎重な検証」のバランスが大事です。 例えば、今回の npm であれば、公開から数日経ったパッケージのみを許可する min-release-age 設定を導入するなど、システム的な自衛手段を講じるのが現実的でしょう。

常にセキュリティ情報のアンテナを張り、異常が起きれば即座にロールバックします。
一見、泥臭く原始的なアプローチに思えますが、複雑に絡み合った現代のサプライチェーンにおいては、これが最も実効性の高い「最適解」と言えるのかもしれません。

将来的には、生成 AI が、こうしたインシデントの検知からリカバリーまでを、自動でやってくれるようになるはずです。
しかしその時、私たちは その AI 判断を、どこまで信じていいのか という、新たな問いに直面してしまうでしょう。

システムの根幹を支える「鎖（チェーン）」のどこかが、いつ切れるかは、誰にも分かりません。
この前提に立って、エンジニアだけでなく、経営に携わる方も、改めて、利用システムのアップデートポリシーなどを見直していただけたらと思います。