PHP脆弱性php2shellでAPIキー漏洩も？再発行の正しい順番

2026年10月21日の夜、ネットショップや業務システムが相次いで「緊急メンテナンス」に入りました。原因は、Webサイトの多くを動かしているプログラム言語「PHP」に見つかった、深刻な脆弱性です。

「うちはWordPressを最新にしているから大丈夫」と思われた方もいるかもしれません。ところが今回の穴はWordPressではなく、その下で動くPHP本体にあります。しかも、サイトの乗っ取りだけでなく、サーバーに置いているAPIキーやパスワードが抜かれるおそれもあります。

私は中小企業のWeb集客やAI導入を支援していますが、最近はWordPressにAIプラグインやメール送信、Google連携を組み込んでいるサイトがほとんどです。そのAPIキーを他のサービスでも使い回している場合、影響はWordPressだけでは終わりません。

今回は「php2shell」と呼ばれるこの脆弱性の中身をできるだけかみ砕いて説明し、APIキーをどう扱えばよいか、再発行の正しい順番まで具体的にまとめます。

WordPressの更新だけでは不十分です。PHPのバージョン確認と、APIキーの入れ替えまでやって初めて「対応済み」と言えます。

1. 10月21日、PHP本体に外から乗っ取れる穴が2つ見つかった

PHP開発チームは、PHP本体にある2件の重大な脆弱性を修正する緊急リリースを公開しました。識別番号はCVE-2026-109618とCVE-2026-109619で、まとめて「php2shell」と呼ばれています。深刻度は共通の評価基準CVSS v4.0で、どちらも9.2（緊急）です。

修正版が出る前に情報が漏れ始めたことで、騒ぎが一気に大きくなりました。当初は計画的に公開される予定でしたが、予告の段階からSNSなどで断片的な情報が広がり、攻撃者が先に動く危険が高まったためです。

国内外の公的機関も、修正できないならサイトを止めることまで含めて対応を求めました。国内ではIPAや国家サイバー統括室、海外では欧州のCERT-EUや英国NCSCが注意喚起を出しています。

2. WordPressではなく「土台」の穴なので、アプリ側の対策が効かない

今回の脆弱性は、WordPressやプラグインではなく、それらを動かすPHPのエンジン部分にあります。そのため、WordPress本体やプラグインをどれだけ最新にしていても、PHP本体が古いままなら穴は開いたままです。

ログイン不要で、細工したアクセスを送るだけで攻撃が成立しうる点も危険です。成功すると、サーバー上で攻撃者が好きな命令を実行できてしまいます。これを「リモートコード実行（RCE）」と呼びます。

影響範囲は、20年以上前のPHP 5系から最新の8.5系まで、ほぼすべてのバージョンに及びます。報道では世界のWebサイトの約7割がPHPを使っているとされており、影響の広さが騒ぎの大きさにつながりました。

サーバーの構成によって危険度は変わり、Apacheの「mod_php」構成が最も危険とされています。この構成では、WordPressのコードが1行も動く前に攻撃が完了しうるためです。一般的なPHP-FPM構成でも、条件がそろえば同じように攻撃が成立します。

「WordPressは最新だから安心」は今回は通用しません。確認すべきはPHPのバージョンです。

3. 乗っ取りだけでなく、APIキーやパスワードも抜かれる

APIキーが漏れる経路は、大きく分けて2つあります。ひとつはサーバーを乗っ取られた場合、もうひとつは乗っ取りまで至らなくてもメモリの中身を読まれる場合です。

経路1：乗っ取られると、設定ファイルとDBの中身が丸ごと読まれる

サーバーを乗っ取られると、wp-config.phpや.envなどの設定ファイルがそのまま読まれます。wp-config.phpにはデータベースのパスワードが書かれているため、そこからDBに入られると、プラグインがDBに保存しているAPIキーもすべて抜き取られます。

経路2：乗っ取りに至らなくても、メモリから秘密情報が漏れる

PHP-FPM構成でも、処理中のメモリからパスワードやAPIキー、ログイン情報が漏れることが実証されています。「うちはFPMだから比較的安全」とは言い切れないということです。

中小企業のWordPressサイトで狙われやすいのは、次のようなキーです。

WordPressに何かのAPIキーを登録しているなら、それは「盗まれる候補」に入っています。

4. 使い回しているキーは、他サービス分も含めて再発行が必要

同じAPIキーをWordPressと他のサービスで使い回している場合、WordPressのサーバーから漏れた時点で全サービスが危険になります。GASやZapier、Make、社内のスクリプトなどがPHPとまったく関係なくても、キー自体が同じなら意味がありません。

PHPサーバー上に一度でも置いたキーは、漏れた前提で扱うのが安全です。侵害されたかどうかを後から完全に確かめるのは難しく、「たぶん大丈夫」で済ませると、気づいたときには請求や情報流出が起きている可能性があります。

特に、危険な期間が長かったサイトは優先して再発行すべきです。情報流出が始まった10月21日夕方から、サーバー側に修正が適用されるまでが危険な時間帯です。PHP 8.1以前のまま放置されているサイトや、自分で管理しているVPSは、この期間が長くなりがちです。

キーを使い回しているなら、WordPressの問題は「全サービスの問題」です。まとめて入れ替えましょう。

5. 再発行は「先に停止」ではなく「差し替えてから無効化」の順で

古いキーを先に止めると、そのキーを使っている全サービスが一斉に止まってしまいます。AI連携が動かない、問い合わせメールが届かない、自動レポートが失敗する、といった業務への影響が出ます。

不正利用の形跡がなければ、次の5つの手順で入れ替えます。

一番大事なのは、最初の棚卸しです。ここで設定箇所を見落とすと、旧キーを無効化した瞬間にそのサービスだけが止まり、原因究明に時間を取られます。

PHPが未修正のサーバーに新しいキーを入れると、また抜かれます。手順3を飛ばさないでください。あわせて、wp-config.phpの認証用ソルト（AUTH_KEYなど）を再生成すると、全ユーザーが強制ログアウトされ、盗まれたログイン情報も無効にできます。

止めるのは最後です。新しいキーを全部に行き渡らせてから、古いキーを消しましょう。

6. レンタルサーバ利用者がまず確認すべきはPHPのバージョン

共用レンタルサーバの場合、PHP本体の更新は基本的にサーバ会社が行います。まずは契約先のサーバ会社のお知らせを確認し、修正版の適用状況を把握するのが最優先です。

管理画面でPHPのバージョンを選べる場合は、8.1以前を使っていないかを必ず確認してください。PHP 8.1以前は公式サポートが終わっているため、修正版が提供されていません。

8.2も年末にサポートが終わる予定のため、互換性に問題がなければ8.3以上へ切り替えるのが無難です。切り替え前に、テーマやプラグインが新しいPHPに対応しているかを確認しておきましょう。

VPSや自社サーバの場合は、修正版へ更新したあと、PHP-FPMやApacheを必ず再起動してください。再起動しないと、古いPHPのまま動き続けます。

まずはサーバ会社のお知らせと、管理画面のPHPバージョン。この2つを見るだけで、やるべきことがはっきりします。

7. 今後は用途ごとにキーを分け、被害を1本で止める

再発行のついでに、APIキーは用途ごとに別々に発行しておくのがおすすめです。「WordPress用」「GAS用」「Zapier用」のように分けておけば、次に何か起きても、漏れた1本だけを止めれば済みます。OpenAIやGoogle Cloudなど、多くのサービスは複数のキーを発行できます。

あわせて、キーに名前を付け、利用上限額やIP制限、権限の絞り込みを設定しておくと被害を小さくできます。特にAI系のAPIは、上限額を設定しておくだけで、万一のときの請求額に歯止めがかかります。

今回の脆弱性はAIによって発見されたと報じられており、今後は脆弱性の発見から攻撃までの時間がさらに短くなると見られています。「パッチが出たら数週間かけて当てる」運用から、「すぐ当てられる体制」と「漏れても被害を小さくする設計」への切り替えが必要です。

よくある質問

WordPressを最新版にすれば対策は終わりですか？

いいえ。今回の脆弱性はPHP本体にあるため、WordPressの更新では直りません。サーバーのPHPが修正版（8.5.12／8.4.27／8.3.36／8.2.35）になっているかを確認してください。

共用レンタルサーバでも、自分で何かする必要がありますか？

PHP本体の更新はサーバ会社が行うのが一般的ですが、PHP 8.1以前を選択している場合は、自分で8.2以上（できれば8.3以上）に切り替える必要があります。また、APIキーの再発行はサーバ会社では代行できないため、利用者側の作業です。

APIキーは全部すぐに止めたほうがいいですか？

不正利用の形跡がある場合はすぐに止めてください。形跡がない場合は、新しいキーを発行して全箇所を差し替えてから古いキーを無効化するほうが、業務を止めずに安全に入れ替えられます。

WordPressに登録していないAPIキーも再発行が必要ですか？

PHPが動くサーバーに一度も置いたことがないキーであれば、今回の件での再発行は必須ではありません。ただし、同じキーをWordPressにも登録している場合は、他のサービスで使っている分も含めて再発行が必要です。

まとめ

今回の件は、サイトの「表側」だけでなく、裏で連携しているサービスまで含めて管理する必要があることを示しました。まずはPHPのバージョン確認と、APIキーの設定箇所の棚卸しから始めてください。

PHPの確認、キーの棚卸し、差し替え。この3つを今日中に済ませれば、慌てる必要はありません。

参考リンク

• IPA：【事前準備のお願い】PHPのセキュリティリリース公開予定について
• Impress Watch：国内大手サービスで緊急メンテやサービス停止 PHP脆弱性で対策
• マイナビニュース：IPA、PHPのセキュリティリリース公開を事前告知
• The PHP Foundation：Today's PHP Security Release, and How We're Strengthening PHP
• CERT-EU：Critical Vulnerabilities in PHP
• Flatt Security Blog：PHPの重大な脆弱性「php2shell」
• piyolog：PHPの2件の深刻な脆弱性

※本記事は2026年10月22日時点の公開情報をもとにしています。修正版のバージョン番号、IPAの注意喚起、国内サービスの一時停止は報道・公式発表で確認した内容です。脆弱性の技術的な仕組み、影響範囲、AIによる発見の経緯は、上記の技術ブログ・公式発表などをまとめた資料に基づきます。「世界のWebサイトの約7割がPHPを使用」は報道で引用されている数字で、調査対象や算出方法によって変わります。今後の続報で内容が更新される可能性があります。