The Hacker Newsによれば、WordPress.orgのプラグイン配布ルートに新たな自動審査の仕組みが組み込まれ、更新API経由でハイリスクなコードやバックドアをブロックする体制が整えられたという。ベースとなっているのは「Protect The Shire」セキュリティプログラムで、悪意あるリリースをクールダウン期間中に止めることが狙いだ。筆者のように長らくWordPress案件を回してきた人間にとっては、「やっとここまできたか」という感想の方が大きい。何年も前から、プラグイン作者の善意と公開スピードに依存した運用は綱渡りだった。更新のたびにクライアントへメールで確認を取る、という運用フローを敷いていた個人開発者も多いはずだ。今回の自動審査は、その前段でWordPress.org側がフィルタをかけてくれることを意味する。とはいえ、フィルタの精度が完璧でない限り、最終的に"配信前に目で確認する"工程は残る。
現場の実情：脆弱性は"想定内"の領域に入っている
皮肉なことに、この発表とほぼ同時期に、Wordfenceが具体的な被害事例を公表している。WooCommerce Wholesale Lead Captureプラグインに任意のファイルアップロードの脆弱性が確認され、認証されていない攻撃者がPHPバックドアを仕掛けられる状態だったという。最終的にリモートコードの実行、サイトの完全掌握に至るシナリオで、まさに"配布元を信じるな"の実例だ。攻撃の手口自体は古典的で、ファイルのアップロード処理に拡張子のチェックが抜けていれば一気にRCEまで通る。WordPress本体はこの種の脆弱性を過去にも何度も踏んでおり、プラグイン単位での対策には限界がある。
今回の脆弱性は、認証なしで攻撃が成立するという特にたちが悪いタイプだ。アクセスログをこまめに取っていないサイトでは、侵入されたこと自体に気づかないままバックドアが常駐し、別の攻撃の踏み台にされることもありうる。改竄検知の仕組みを定期実行しているサイトは少ないが、最低限、ファイルの改竄チェックだけでも回しておきたい。
つまり「配布前に止める」仕組みの必要性が、すでに実弾として飛んできているわけだ。個人開発のWordPress案件では、長らく「更新はクライアント都合で止まる」「古いプラグインが残る」という構造を抱えてきた。予算の都合で止めているケースもあれば、互換性を理由に止めているケースもある。この構造こそがまさに攻撃者の入り口になる。だからこそ、公式側で更新APIに審査を噛ませる今回の動きは、運用フローの上流にフィルターが一段増えたと見るのが自然だろう。
個人開発者が今日やるべきこと
まず、稼働中の案件で「WooCommerce Wholesale Lead Capture」を入れていないか確認してほしい。入れているなら即刻の無効化が原則で、代替プラグインへの移行は修正版が出てからでも遅くはない。EC案件では代替選定に時間がかかることもあるが、感染してからでは遅い。
次に、管理画面のプラグイン一覧から、しばらく更新が来ていないものを洗い出す。自動審査が効くのは「これから配布される更新」に限定されるため、すでにバックドアを撒かれた後では意味がない。ファイルの更新日時や不審なPHPの混入は、SSHでログインできる案件なら find wp-content/plugins -name "*.php" の出力を雑にgrepしておくのが現実的だろう。力技だが、ログを追えないクライアント案件ではこの一行で済む場面が多い。
バックアップの運用も改めて確認しておきたい。公式の審査が完璧に機能する保証はどこにもないので、感染後の切り戻し手段は常にスタンバイさせておくのが筋だ。とりわけ、データベースのバックアップは復元演習まで含めておきたい。本番DBでリストアを試したことがないなら、今日ひとつ触っておく価値はある。
WAFの設定も見直しの余地がある。Wordfenceのようなプラグイン型WAFを既に動かしているなら、ルールの自動更新が有効か、保護モードがオンになっているかを再確認しておきたい。DockerでWordPressを動かしている案件であれば、コンテナイメージのスキャンも併せて確認しておきたい。公式のwordpressイメージをそのまま使っているケースは多いが、プラグインをコンテナ内にインストールしている場合、イメージ更新時にプラグインもまとめて再評価される運用に変えるだけで、リスクの可視性は上がる。
運用でカバーするか、コードで解決するか
結局のところ、今回の自動審査は「善意の作者」が大多数を占める前提の上に成り立つ。テーマや独自プラグインを自作している個人開発者にとっては、公式の審査ではなく「自分の中での自動レビュー」が本番になる。LaravelであればCIにPintやPHPStanを組み込むように、WordPressでもPHPCSやPlugin Checkをローカルで回す癖をつけておきたい。
「Protect The Shire」というネーミングからして、公式チームの空気も相当殺伐としているはずだ。プラグインの自動審査が回り始めた今こそ、受注案件の納品チェックリストに「配布前に自分の目で見る工程」を明記しておきたい。実装レベルでいえば、自動テストを回すスクリプトと、PHPの構文エラーや危険な関数を検知するリントを回すスクリプトの二段構えが現実的だ。CIに組み込めれば言うことはないが、導入に二の足を踏む現場では、ローカルでのチェックリスト運用でも効果は十分にある。
もうひとつ、現実的な落とし所として「自動審査は保険」と割り切る考え方も必要だ。公式側で何をやっていても、自分のコードと運用に穴があればそこから崩れる。Laravel案件と並行してWordPress案件を回していると、片方の流儀がもう片方に流用できない局面にたびたび出くわす。PHPCSのルールセットを案件ごとに用意するか、汎用的なものに寄せるかは、保守工数との相談になる。クライアントに"安全のための工数"として認めてもらう材料にもなる。理想論ではなく、明日書くコードの話として。