本文へ
ハクソク

世界を動かす技術を、日本語で。

本日のPHPセキュリティリリースと、私たちのセキュリティ強化策

元記事: 原文(thephp.foundation)

概要

PHPプロジェクトが 重大な脆弱性 を修正した複数バージョンをリリース 問題の脆弱性は リモートコード実行 を許す可能性があり、即時アップデートが推奨 発見・修正の経緯や、 PHPセキュリティ体制の変化 について詳細を解説 AIや外部監査の活用、 組織的な対応強化 が進行中 今後の持続的な安全対策には コミュニティとスポンサーの支援 が不可欠

PHP 8.5.12、8.4.27、8.3.36、8.2.35：重大な脆弱性修正リリース

  • 2026年10月、 PHPプロジェクト は複数バージョンの緊急アップデートを公開
  • 2件の クリティカルな脆弱性 （CVE-2026-109618／CVE-2026-109619）を修正
  • 脆弱性により、 未認証の攻撃者がリモートでコード実行 可能となる恐れ
  • 公式アナウンスには 技術詳細・攻撃ベクター・アップデート手順 を掲載
  • PHPを利用している場合は 即時アップデート が必須

脆弱性の内容と影響

  • CVE-2026-109618（RCE via OOM corruption）
    • メモリ制限到達時、内部データが不完全な状態で残存し、後に 不正なメモリ操作 が発生
    • Apache＋mod_php環境では、 アプリケーションコード実行前にRCE が実証
    • PHP-FPM環境でもアプリケーション経由で RCEが確認
  • CVE-2026-109619（RCE via stale state）
    • 致命的エラー時、 前リクエストのメモリ領域へのポインタ が残存
    • 後続リクエストで 解放済みメモリの再利用 が発生し、RCEにつながる
  • 両脆弱性は メモリ管理・エラーハンドリング というPHPの中心機能に存在
  • 修正には 互換性・性能・拡張エコシステムへの影響 など難しいトレードオフが存在

発見と修正の経緯

  • 2024年、 Sovereign Tech Agency の資金援助で OSTIF・Quarkslabによる外部監査 を実施
  • 監査過程でPHP Foundation契約開発者が OOM問題の兆候 を発見
  • 修正案の選定では 後方互換性・DoSリスク・拡張対応の難しさ が障壁
  • 意思決定の停滞とリソース不足 が修正遅延の主因
  • 現在は 意思決定プロセスの見直し に着手し、合意形成を迅速化

PHPセキュリティ体制の強化

  • 2026年5月、 Ecosystem Security Team を設立し、体制を拡充
    • Volker Dusch （AI Security Engineer in Residence）によるコミュニケーション強化
    • Alexandre Daubois ・ Daniel Scherzer がセキュリティ対応・ハードニングを担当
  • AIツール（Anthropic Claude Mythos、OpenAI Daybreak Red等） を活用し、バグ検出・検証を効率化
  • Calif、OpenAI、Wiz 等の外部監査・研究者による指摘で、OOM問題の影響範囲が明確化
  • 財団の資金で 複数人がフルタイムで対応、迅速な修正を実現

情報漏洩と公開プロセス

  • リリース2日前に CVE情報がSNS等で流出、誤ったリリース時刻・CVSSスコアも拡散
  • 対応として 前倒しで事前アナウンス・リリース日変更 を実施
  • Calif が誤ってPoC動画を公開し、一部技術詳細が拡散
  • Chainguard が単独で修正版イメージを公開し、協調的な情報公開体制を損なう事態も発生
  • これらの出来事により PoCの開発・流通が加速

今後の展望と課題

  • PHPセキュリティ体制の進化 と迅速な対応力の向上を実証
  • 今後は 複雑な修正が必要な脆弱性の迅速解決 を優先課題に
  • AI活用により報告件数が急増、だが最終判断・パッチ作成は 熟練エンジニア が必須
  • 財団資金・エンジニア育成 が持続的安全確保のカギ

支援のお願い

  • PHPは 政府・金融・EC・メディア等、社会インフラの中核 を担う
  • しかし、 セキュリティ対応は少数の財団開発者とボランティアに依存
  • 企業・ホスティング・クラウド・公共機関 によるスポンサー支援が不可欠
  • thephp.foundation/sponsor での支援を呼びかけ
  • 公的投資の好例として Sovereign Tech Agency による監査資金援助を紹介

感謝

  • PHPセキュリティチーム・財団契約者・リリースマネージャ・LTSベンダー への謝意
  • Calif、Wiz、OpenAI Codex Security、OSTIF、Quarkslab 等の研究・責任ある情報公開に感謝
  • Alpha-Omega、OpenAI、Anthropic によるツール・資金提供
  • Sovereign Tech Agency による2024年監査資金援助
  • すべてのスポンサーの支援に感謝

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

漏洩と20:00 UTC頃の事前発表の結果、問題を報告していたセキュリティ企業の一つであるCalifが、誤って動画を公開しちゃったんだよね。これが一番驚いた部分だわ。Califは漏洩を見て、それを禁則が破られたと解釈して、急いで自社の[アニメダンス]マーケティング動画を公開したってこと？もっと良い対応を期待してたんだけど。

└

これって、アニメのダンス女の子の動画じゃないよね？

└

マーケティングやPR会社が実際にどう調整しているか、彼らが何を言おうと関係なく、まさにこれだよね。

└

誤って？これって、誰かがつまずいてマウスの上に倒れ込んで、画面録画を偶然オンにして、いくつかのエクスプロイトを実行して、アニメの女の子のアセットとサウンドトラックを手に入れて、それらをPremiereに放り込んで、変なエフェクトを追加して、動画をレンダリングして、Twitterに公開したみたいに読めるね。「痛い。何にぶつかったんだ？ああ、やっちゃった、エンバゴを破っちゃった！」すごいミスだね。

ステップ1：禁則が解除されるときに、dockerイメージが利用可能であることを確認すること。もう2時間経ったけど、まだ利用できないよ。

└

今日は、こういう場合にはゼロからイメージを作ることが基本だって学んだ。Claude Codeの提案のおかげで、準備万端だったよ。

└

そうだね、今はその対応に全力を注いでるよ。結構面白い！

└

もう二度とDocker Hubは使わない。

└

PHPファウンデーションが管理すべきだと思う。Dockerの「公式イメージ」アプローチは、脆弱性のパッチに対応するには明らかにうまく機能していない。

└

彼らの気持ちがわかるな。オープンソースプロジェクトだと、実際にかなり難しいんだよね。ソースコードが公開されてるから、コミットやプッシュができないし、そうすると情報漏洩になっちゃう。ビルドパイプラインもおそらく公開されてるから、別のソースコードからビルドすることもできないし…。プライベートリポジトリを作ることはできるけど、今度はプライベートなビルドシステムを構築しなきゃいけない。プライベートリポジトリには同じようなビルドリソースがもらえないから、結局、a) 必要最低限のビルドに簡素化するか b) お金を払うかになるよね。十分な資金がない限り、たぶん a) を選ぶことになる。そうすると、二つのシステムを維持しなきゃいけなくて、しかもそれぞれに違いがある。さらに、プライベートシステムからパブリックシステムにビルドアーティファクトを移す方法も必要で、通常は特定の時点で行うことになる。何か失敗や遅延があると（例えば、プライベートリポジトリでのビルドがパワー不足だったり、あまり使わないからエラーが出たり）、発表した時間を守らなかったことで人々が不満を持つことになる。もしかしたら、イメージアタステーションみたいなものを使ってるかもしれないし、これまた厄介な問題だね。

└

数週間や数ヶ月のエンバゴの後に漏れないことを期待するのは、信じられないほどナイーブだと思う。セキュリティ修正の事前通知を受けるのは大きな特権で、組織はそういう情報をもらったらすぐに動くべきだと思う。更新するのに数日以上は与えられるべきじゃない、他の世界が待てるわけじゃないからね。

└

それってDockerで動いてるんじゃないの？PHPの基盤は責任を持てないよ。

Hacker Newsで議論の続きを見る

同じ出典の記事