Sponsored
WordPress の緊急パッチが降ってきた週末、自分のサイトでやった作業はゼロでした。
バージョン確認すらしていません。そもそも WordPress が無いので。
セキュリティ速報のほうを先に書いたのですが、書いている途中で「あ、これ自分は何もしなくていいんだ」と気づいて、少し変な気持ちになりました。
wp2shell（CVE-2026-63030 / CVE-2026-60137）とは。WordPress の事前認証 RCE で確認すること | Lazy Developer
2026年7月に公開された WordPress コアの事前認証 RCE、通称 wp2shell について、影響を受けるバージョン、更新手順、すぐ更新できない場合の緩和策、アクセスログでの侵害確認までを整理します。
4ヶ月前に Astro へ移していたおかげです。
ただ、移行した動機はセキュリティではありませんでした。そこも含めて書きます。
何が起きていたのか
ざっくり書くと、WordPress コアだけで未認証のリモートコード実行ができる脆弱性が見つかりました。通称 wp2shell。
REST API の batch エンドポイントに認証バイパスがあり、そこから SQL インジェクションにつなげると、ログインせずに管理者ユーザーを作れてしまう。プラグインは要りません。素の WordPress で成立します。
修正版が出たのが2026年7月17日で、数時間後には PoC が GitHub に並び、週末には実際の攻撃が観測されました。金曜に出たパッチが週末を挟むという、運用する側からするといちばん嫌なパターン。
詳しい影響範囲やログの見方は速報記事のほうに書いたので、ここでは省きます。
自分のサイトは何もしなくてよかった
このサイトは Astro の静的ビルドで、Cloudflare Pages から配信しています。
記事は Markdown ファイルで、ビルドすると HTML が出来上がる。あとはそれを置いているだけです。
PHP が動いていません。データベースもありません。管理画面もありません。/wp-json/batch/v1 を叩いても、そこには何も無い。
攻撃面がどうこう以前に、攻撃の対象になる仕組みが1つも存在しないという状態です。
こういうとき、静的サイトは強い。
でも、セキュリティのために移したわけではない
正直に書いておくと、移行の理由はもっと情けないものでした。
ある日突然サイトが開かなくなって、「このサイトで重大なエラーが発生しました」の画面が出たからです。
【雑記】WordPress から Astro へサイトを全面移行した話 | Lazy Developer
ある日突然 WordPress サイトが開けなくなり、原因調査から Astro への全面移行を決意。AI を活用して 2.5 時間で移行を完了した体験談です。WordPress のメモリ不足エラーの調査手順や、移行の具体的な流れを紹介します。
原因はメモリ不足とテーマの問題でした。何のリリースもしていないのに勝手に落ちた WordPress に嫌気がさして、その勢いのまま Astro へ全面移行した、というのが実際のところ。
つまり今回の「何もしなくてよかった」は、完全に結果論です。
セキュリティを考えて先手を打っていたわけではなく、別の理由で逃げた先がたまたま安全だっただけ。ここを「静的サイトに移したおかげで守れました」と書くと、話がきれいになりすぎるので。
WordPress 時代に気にしていたこと
WordPress を運用していた頃、REST API まわりはそれなりに気にしていました。
2025年に、ユーザ API のエンドポイントを閉じる話を書いています。
WordPress のユーザAPIのエンドポイントを閉じておく | Lazy Developer
この記事では WordPress のユーザAPIのエンドポイントを閉じておくべきというセキュリティ関連の備忘録を記載します。 概要 WordPress は何もしないでいると、APIにアクセスできてしまいます。 自身のサイトを WordPress で構築している場合、API アクセスはデフォルトで有効化されているという罠
/wp-json/wp/v2/users にアクセスするとユーザー一覧が丸見えになる、という話で、rest_endpoints フィルタで潰す対応を紹介したやつです。
今回の wp2shell も、入口は REST API でした。しかも侵害後の挙動として観測されているものの中には、まさにその /wp-json/wp/v2/users?context=edit へのアクセスが含まれています。
1年以上前に閉じておいた場所を、今また同じ方向から殴られている。
WordPress の攻撃面って、けっこう同じところに居続けるんだなと思いました。
静的サイトなら安全、という話ではない
ここで終わると気持ちのいい記事になるのですが、そうもいきません。
攻撃面は消えたのではなく、移動しただけです。
WordPress を捨てた代わりに、このサイトは npm の依存関係とビルドパイプラインを抱えることになりました。そして、その領域では実際に事故が起きています。
axios の npm サプライチェーン攻撃で起きたことと守り方 | Lazy Developer
2026年3月31日、週間1億DLを超える axios の npm パッケージが乗っ取られ、マルウェア入りバージョンが公開されました。何が起きたのか、影響確認の方法、そして lockfile と npm ci による防御策を整理します。
TanStack の npm サプライチェーン攻撃（2026年5月）でやるべき確認と対応 | Lazy Developer
2026年5月12日早朝、TanStack Router / Start 系の npm パッケージにマルウェア入りバージョンが公開されました。GitHub Actions の OIDC とキャッシュを悪用した攻撃の概要、影響確認、対応方針を整理します。
axios が乗っ取られたのが2026年3月末、TanStack が5月。半年足らずで、自分のサイトで速報を2本書いています。どちらも「自分が使っているかもしれない」側の事件でした。
Sponsored
サーバー上で動く PHP を心配しなくてよくなった代わりに、npm install した瞬間に何が走るかを心配することになった。運用の重さがゼロになったわけではありません。
違うのは、事故ったときに何を失うかです。WordPress が乗っ取られると、公開中のサイトそのものが攻撃者のものになります。ビルド環境が汚染された場合、まずやられるのは手元の認証情報で、そこから公開物に波及する。順番も対処も変わってきます。
どちらが軽いかは、正直、抱えているものによると思っています。ただ自分の場合は、24時間インターネットに晒されている PHP を持たなくて済むほうが、精神的にだいぶ楽です。
減ったものと、増えたもの
移行して減ったのは、プラグインの更新確認、テーマの互換性チェック、コア更新のたびの動作確認、そして今回のような緊急パッチ対応です。
公開の手順も変わりました。今は記事を Markdown で書いて PR を出し、main にマージすると Cloudflare Pages が勝手にビルドして公開してくれます。管理画面にログインする作業が、そもそも存在しない。
増えたのは、依存パッケージの更新確認と、Markdown で書くという手間。あとは、思いついたことをスマホからサッと投稿できなくなったこと。
この最後のやつは、人によっては致命的だと思います。エンジニアじゃない人が更新するサイトを Astro に移したら、たぶん更新が止まります。
そこはトレードオフ。自分は Markdown のほうが楽なので気にしていませんが、万人向けの選択ではないなと。
おわりに
移行しましょう、という記事ではありません。
WordPress にはプラグインの厚みも、非エンジニアでも扱える管理画面もあって、それが必要ならそのまま使えばいいと思います。
ただ、動的なものを持ち続けるなら、金曜の夜に critical のパッチが降ってくる前提で運用を組む必要はあります。自動更新を有効にしておくのはもちろん、それが本当に成功したかを確認する経路も用意しておく。今回のように週末を挟むパターンだと、月曜まで気づかない構えだと普通に間に合いません。
自分はその覚悟が続かなかったので、静的サイトに逃げました。
逃げた先で npm の心配をしているので、結局どこかで何かを心配することにはなるんですけどね。
