PHPの脆弱性、おおいたイベントは影響なし。完全な静的サイトにしている理由と、自分のWebサイトを見直すきっかけに
はじめに
若林諒です
今日は連載「おおいたイベントの作り方」の2回目を出す予定でしたが、予定を変えて、番外編を書くことにしました
きっかけは、いま世界中で対応に追われている PHP の重大な脆弱性です
PHP は、WordPress をはじめ、多くの Web サイトの裏側で動いているプログラミング言語です
先にお伝えすると
おおいたイベントは PHP を使っていないので、今回の脆弱性の影響は受けていません
この記事では、その理由と、このニュースをきっかけに考えてほしいことを書きます
PHP や WordPress を悪く言いたいのではなく、本当にやりたいことと、その実現方法が合っているかを、一度立ち止まって見直してほしい、というお話です
連載の2回目以降は、1回ずつ後ろにずらします（2回目は10月24日の土曜の夜に公開予定です）
連載の記事は、マガジン「おおいたイベントの作り方」（https://note.com/elixir_livebook/m/m7da88d840ec8）にまとめています
この記事の結論
2026年10月21日、PHP の開発チームが、ログインなしで外から任意のプログラムを動かされるおそれのある脆弱性2件を修正した版を公開した。すでに悪用も報告されている
おおいたイベントは、完成したページを配るだけの「静的サイト」で、PHP も、自分で管理するサーバーもないので、今回の影響は受けていない
ただし「絶対に安全」ではない。守るべき場所が、サーバーからアカウントや作る工程に移っただけ
WordPress が本当に必要か、やりたいことと手段が合っているかを見直してほしい
見直すのは技術だけでなく、運用の体制と、問題があったときの連絡の流れも
何が起きているのか
私がこのニュースを最初に読んだのは、10月21日でした
PHP の開発チームが「重大な脆弱性2件を直す版を、日本時間の21日23時に出す」と前もって知らせていたものです
本業のほうでも、その日は関係するところへの連絡など、いろいろと対応に追われました
21日のうちに多くのサイトがメンテナンスに入り、予定の23時より少し前に修正の情報が出て、各社が順に更新を進めています（きちんと対応できているところは、ですが）
修正版（PHP 8.5.12、8.4.27、8.3.36、8.2.35）で直されたのは、ログインなしで、外からサーバー上の任意のプログラムを動かされるおそれがある、重大な脆弱性2件（CVE-2026-109618、CVE-2026-109619）で、深刻度はどちらも CVSS v4.0 で 9.2 とされています
公式の告知では、Web のリクエストを処理するすべての PHP が対象で、「完全な回避策はなく、更新だけが安全な選択」と書かれています
見つけた企業の一つ Wiz は「PHP2Shell」と名付け、WordPress などの環境で、ログインなしに攻撃が成り立つことを実証したと報告しています
さらに Amazon は、公表の前の10月17日から攻撃を試みる通信を観測していて、修正版が出たあとは広く悪用されていると報告しています
WordPress のプラグインなどではなく、土台の PHP そのものの問題なので、PHP で動くサイトは、まず更新を確かめることがいちばん大事です
2026年10月22日時点の情報です。詳しくは PHP 公式の告知（https://www.php.net/archive/2026.php ）をご覧ください。自分のサイトが対象かどうかは、サーバーやレンタルサーバーの会社の案内を確かめてください
おおいたイベントが影響を受けない理由
「その場で作るサイト」と「作り置きを配るサイト」
Web サイトの仕組みには、大きく2種類あります
WordPress のようなサイトは、注文が入るたびに厨房で料理を作るお店に近いです
誰かがページを開くたびに、サーバーの上で PHP のプログラムが動き、データベースから記事を取り出して、ページを組み立てます
今回の脆弱性は、まさにこの外からのリクエストを受け取って動くプログラムの問題です
一方、おおいたイベントは、前もって作っておいたお弁当を、棚に並べて配るだけのお店です
ページは毎朝4時に全部作り直して、完成した HTML を Cloudflare Pages に置いています。ページを開いたときに起きるのは、できあがったファイルを返すことだけです
攻撃される「自分のサーバー」がない
1回目の記事にも書いたとおり、このサイトには
サーバーで動くプログラムがない
データベースがない（イベント情報は1件1ファイルで Git に置いている）
ログインも、会員登録も、コメント欄もない
申込は受け付けず、主催者の申込ページへ案内するだけ（個人情報を預からない）
という作りにしています
サイト内の検索も、Pagefind という仕組みで、閲覧している人のブラウザーの中で動いています
今回のように「サーバーの上のプログラムを乗っ取られる」種類の攻撃は、乗っ取る先のサーバーが私の側にないので、そもそも成り立ちません
それでも「絶対に安全」とは言わない
静的サイトは、守る場所が減るだけで、守らなくてよくなるわけではありません
たとえば、こんなところは今も守る必要があります
GitHub や Cloudflare、ドメインのアカウントが乗っ取られたら、サイトを書き換えられてしまう
サイトを作るときに使う部品（npm のパッケージなど）に問題があれば、作る工程に入り込まれる
SNS への投稿に使う鍵（アクセストークン）が漏れれば、公式アカウントで勝手に投稿される
実は同じころ、PHP とは別の件（証明書を発行する会社の一つで秘密鍵が漏れた問題）で Node.js にも修正版が出ていて、おおいたイベントでもバージョンを上げました
サイトを作るときに Node.js を使っているからです
やったことは、手元の Node.js と、Cloudflare の設定の変数を上げて、作り直すだけで、数分で終わりました
守るところが少なく、直す手順が決まっていると、こういうときに慌てずに済みます
静的サイトは「攻撃されない魔法」ではなく、「守る場所を、自分で守り切れる量まで減らす」方法だと考えています
生成AIと、セキュリティも相談しながら作った
このサイトのコードは、すべて生成AI（Claude Code）が書いています
なので、機能だけでなく、セキュリティも Claude と話し合いながら決めてきました
最初の企画書の段階で、情報源の利用規約、著作権、個人情報の扱いを確かめた
AI が読んだ Web ページの中に「この指示に従え」のような文が仕込まれていても、従わずにデータとして扱うと決めた
AI には Pull Request を出すところまでしか任せず、公開の判断は人がする
検索の数字を読む仕組みには、読むことしかできないアカウントを使う
SNS への投稿の鍵は GitHub の Secrets に入れ、AI にもログにも見えないようにする
ただ、何を守るか、どこまで任せるかを決めるのは人です
このあたりは、連載のこの先の回でも詳しく書きます
本当に WordPress が必要か、見直してみてほしい
WordPress が向いているサイトもたくさんある
WordPress は、画面から誰でも記事を更新できて、たくさんの会社のサイトを長く支えてきた良い道具です
社内の何人もが毎日記事を書く、会員向けのページがある、といったサイトには、とても合っています
その場合は、PHP や WordPress、プラグインをこまめに更新し続ける体制を持つことが大事です
「とりあえず WordPress」になっていないか
一方で、こんなサイトも多いのではないでしょうか
会社の紹介と連絡先が載っていて、更新は年に数回
作った制作会社との契約は終わっていて、誰が更新するのか決まっていない
管理画面のパスワードを知っている人が、もう社内にいない
このようなサイトでは、サーバーの上で毎回プログラムが動く便利さを、ほとんど使っていません
それなのに、PHP や WordPress、プラグインの更新という守る仕事だけは、ずっと続くことになります
本当にやりたいこと（会社を知ってもらう、問い合わせを受ける）と、その実現方法が合っているかを、一度考えてみてほしいです
更新が少ないなら静的サイトにする、問い合わせは信頼できるフォームのサービスに任せる、といった選び方もあります
大事なのは、選んだ理由を、自分たちで説明できることです
放っておかれたサイトが、被害を広げる
もう一つ考えてほしいのが、作ったまま、誰も見ていない Web サイトです
こうしたサイトが乗っ取られると、偽のページや不正なプログラムを配る場所にされたり、ほかのサイトを攻撃する足がかりにされたりして、サイトを見に来た人や、つながっている相手にまで被害が広がることがあります
なので、このニュースをきっかけに、自分たちのサイトが今も本当に必要か、安全か、価値を届けられているかを、改めて考えてみてほしいです
役目を終えたサイトは、きちんと閉じるのも、立派な対策の一つです
技術だけでなく、運用と連絡の体制も見直す
今回の脆弱性も、修正版はすでに出ています
それでも、21日の夜から各社が慌ただしく更新を進めたように、直す方法があっても、直す人と手順が決まっていなければ間に合いません
「誰が知って、誰が判断して、誰が更新するのか」を、改めて確かめてほしいです
PHP のバージョンを確かめる人は決まっているか
レンタルサーバーや制作会社から連絡が来たとき、社内の誰に届くか
サイトがおかしいと気づいた人が、どこに連絡すればいいか
改ざんされたとき、サイトを止める判断は誰がするか
おおいたイベントは私1人で運営していますが、それでも
掲載中のイベントの公式ページを週2回自動で見張り、気になるものは GitHub の Issue で知らせてもらう
訂正や掲載の停止の依頼は、サイトの受付フォームで受けて、速やかに対応するとサイトに書いている
と、「気づく仕組み」と「連絡を受ける窓口」は先に決めています
技術を見直すときは、運用と連絡の体制も一緒に、です
私がサーバーレスを選んできた理由
これまでのキャリアでも、私はできる限りサーバーレスで Web の仕組みを作ってきました
サーバーの面倒（OS やミドルウェアの更新、台数の調整など）を、クラウドの会社に任せる作り方です。理由は2つです
少ない人数で、運用と保守を続けられること
急にアクセスが増えても、仕組みのほうで受け止められること
画面の裏で動くプログラム（バックエンド）が必要なときも、まずサーバーレスで作れないかを考えます
ただ、サーバーレスだから安全、というわけではありません
サーバーの更新はクラウドの会社がやってくれますが、自分で書いたプログラム、設定、権限、アカウントを守るのは、変わらず自分たちの仕事です
それでも、自分たちが守らなければいけない範囲を、少ない人数で守り切れる大きさにするという意味で、サーバーレスや静的サイトは、とても良い選択肢だと考えています
よくある質問
Q. おおいたイベントで、何か対応はしましたか？
PHP を使っていないので、今回の脆弱性のための対応はしていません。守りの中心は、GitHub や Cloudflare などのアカウントと、サイトを作る工程です
Q. うちのサイトが WordPress です。すぐに静的サイトにしたほうがいいですか？
まずは、PHP と WordPress、プラグインを最新にすることが先です
静的サイトにするかどうかは、そのあとで「何のためのサイトか」「誰が更新するか」から、落ち着いて考えれば大丈夫です
まとめ
おおいたイベントは、完成したページを配るだけの静的サイトなので、影響は受けていない
静的サイトもサーバーレスも「絶対に安全」ではない。守る場所を、守り切れる量まで減らす方法
WordPress を責めるのではなく、やりたいことと手段が合っているかを見直す
古いサイトは「必要か・安全か・価値があるか」で見直し、運用と連絡の体制も一緒に
次回予告
連載に戻って、次回（10月24日 土曜の夜に公開予定）は、このサイトの運用の話です
毎朝7時に AI が県内23か所の公式ページを見て回り、新しいイベントを見つけて「更新案」を出してくれます
AI にどこまで任せて、どこから任せないかの線引きも含めて書きます
書いた人
若林 諒（わかばやし りょう）
大分在住のフルスタックエンジニア。2007年に大分の IT 企業に入社し、銀行や自治体のシステム開発から、画像認識 AI、生成AI の社内導入とガイドラインづくりまで経験してきました
大学での講義や社内外の勉強会・登壇は100回以上。JAWS-UG 大分などのコミュニティ運営、CLS別府の運営にも関わっています
2026年6月からは副業の個人事業主として、生成AIの導入支援や、技術顧問として開発・IT まわりの幅広いご相談に応えています
ご相談は、こちらのフォームからお気軽にどうぞ（Google のログインは不要です）
https://forms.gle/AiCE7qSi4uGTqZPb8
おおいたイベント: https://oita-events.com/
