PHPの更新は「サイトの裏側の受付」を直すこと

結論からいうと、今回のPHP更新は、見た目ではなく「サイトの裏側で依頼を処理する仕組み」を直すものです。運営者がまずすることは、管理会社に修正が適用済みか確認することです。

「脆弱性」とは、悪用されるおそれのある弱点のこと。難しい仕組みを全部覚える必要はありません。何がまずかったのかを、受付と作業台のたとえで見ていきましょう。

PHPを使うサイトでは、訪問者から届く依頼を裏側で処理します。次の図に登場する作業台は、その間だけ使う一時的な作業場所です。保存済みの記事や、写真を置くディスクの空き容量の話ではありません。

2026年10月21日、PHP公式は二つの重大な問題を修正した更新を告知しました。修正を含むPHPへの速やかな更新が勧められています。以下は同日時点の情報です。

ひとことで：ページの見た目ではなく、裏側の安全のために更新します。

一つ目は、準備が終わる前に止まってしまう

受付が作業を始める前に、「どこで何をするか」という管理票を準備していると考えてください。その途中で作業場所が足りなくなり、処理が中断します。

作業を止めること自体が、すべて危険なのではありません。困るのは、準備途中の情報を完成済みとして後片付けに使うことです。

これは一つ目の公式技術資料で説明されている問題です。

条件がそろって悪用されると、意図しない処理を動かされるおそれがあります。メモリ不足が起きたら必ず悪用されるわけではなく、エラー表示だけで「攻撃された」とは判断できません。

ひとことで：準備途中で止まったときの、後片付けに問題がありました。

二つ目は、片付けた場所への案内が残ってしまう

こちらは別の問題です。前の依頼が終わり、使っていた作業場所を返しました。ところが、「作業場所はここ」という案内メモだけが残ってしまいます。

この「案内メモ」は、場所を指す内部情報のたとえです。単に前の文章が残る、他の人の記事が混ざる、といった意味ではありません。もう返した場所を、まだ使えるかのように扱う点が問題です。

たとえば、返した場所が別の作業に使い直されていたら、古い案内を頼りに、違うものを誤って扱ってしまいます。「案内が残るだけ」とは言えない理由です。

大切なのは順番です。次の依頼のために案内を消し直す仕組みがあっても、それより早く古い案内を使う場面がありました。二つ目の公式技術資料が扱うのは、このずれです。

ひとことで：前の依頼の古い案内が、同じ担当の次の仕事に持ち越されました。

更新で直すのは「止まり方」と「古い案内」

二つの問題は、一つの事故が順番に進む物語ではありません。別々の弱点なので、「準備途中の片付け」と「次の依頼に残る案内」を分けて考えると整理できます。

PHPの公式修正内容をたとえにすると、一つは「準備途中でも安全に止まれるようにする」、もう一つは「使われる前に古い案内を消す」です。

警告を画面から見えなくするだけでは、古い案内の問題は直りません。逆に、エラーが出ていないことも、修正済みの証明にはなりません。見た目ではなく、修正の適用状況を確認しましょう。

ひとことで：警告の表示ではなく、二つの修正が入っているかが大切です。

運営者は、管理会社に修正の適用を確認する

裏側の仕組みは、契約先に確認するのが出発点です。たとえばWordPressの公式要件では、ホスト側にPHPを求めています。WordPressの更新と、PHPの修正確認は分けて考えましょう。

管理会社や保守担当に尋ねるなら、次の三つが確認の手がかりになります。

• このサイトではPHPを使っていますか？
• 10月21日に公表された二つの問題への修正は、適用済みですか？
• 未適用なら、いつ対応し、完了をどう確認できますか？

管理画面へのログインなしに悪用できるケースもあるため、確認は後回しにせず、未対応なら修正を含むPHPへの更新を相談しましょう。

個別のサイトが修正済みか、被害があったかは、この記事では判断していません。

ひとことで：仕組みを全部覚えるより、自分のサイトの修正状況を確かめましょう。