日本の被害状況Japan incidents
お問い合わせContact

脆弱性の解説 · CVE-2026-109618 / 109619Vulnerability explainer · CVE-2026-109618 / 109619 PHPの穴
「php2shell」とはphp2shell:
what broke in PHP

2026年10月21日、PHP本体の重大な脆弱性2件が修正されました。条件がそろうと、ログインしていない攻撃者が、サーバー上で命令を実行できる恐れがあります。国内では一晩で約211の組織が、予防のためにサービスを止めました。何が起きたのか、どういうしくみなのか、何をすればよいのかを、動く図でやさしく説明します。

On 21 October 2026, PHP fixed two critical flaws in PHP itself. Under the right conditions, an attacker who never logs in can run commands on the server. Within a night, about 211 organisations in Japan took services offline as a precaution. This page explains what happened, how the flaws work and what to do, in plain words and with moving diagrams.

CVSS v4.0 9.2 · Critical 修正版：8.5.12 / 8.4.27 / 8.3.36 / 8.2.35Fixed: 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 8.1以前：公式の修正なし8.1 and older: no official fix

株式会社BekitoBekito Inc.約12分12 min read

この記事の要点Key points

  • 「php2shell」はPHP本体の脆弱性2件（CVE-2026-109618・CVE-2026-109619）の通称です。WordPressなどのアプリではなく、PHPそのものの問題なので、PHPでWebサイトを動かしている会社はすべて確認が必要です。
  • 攻撃者はログインせずに、細工したリクエストを送るだけでサーバー上で命令を実行できる恐れがあります。Apacheのmod_phpでは、アプリのコードが動く前に成立することが確認されています。
  • 修正版は 8.5.12・8.4.27・8.3.36・8.2.35（2026年10月21日）。PHP 8.1以前には公式の修正版が出ません。
  • 10月22日時点で、米CISAとIPAは悪用を確認していません。ただし攻撃の試みは観測されており、詳しい情報はすでに出回っています。「様子を見る」理由はありません。
  • すぐ更新できない場合の当面の対策もありますが、それだけでは安全になりません。
  • "php2shell" is the nickname for two flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619. The problem is in PHP, not in WordPress or any one application, so every company running websites on PHP needs to check.
  • An attacker may be able to run commands on the server without logging in, just by sending a crafted request. With Apache's mod_php, the attack has been shown to work before any application code runs.
  • Fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (21 October 2026). PHP 8.1 and older get no official fix.
  • As of 22 October, the US agency CISA and Japan's IPA had not confirmed attacks in the wild. Attack attempts have been seen, though, and the details are out. There is no reason to wait and see.
  • There are stopgap measures if you can't update right away, but they don't make you safe on their own.

01

あなたのPHPは大丈夫？Is your PHP affected?バージョンを入れると、すぐに判定しますType a version and get an answer straight away

サーバーで php -v を実行した結果か、レンタルサーバーの管理画面に出ているPHPのバージョンを入れてください。入力した内容はこのページの中だけで判定し、どこにも送りません。

Paste the output of php -v from your server, or the PHP version shown in your hosting control panel. The check runs inside this page; nothing you type is sent anywhere.

注意：UbuntuやDebian、RHELなどのパッケージは、修正が入っても番号が古いままのことがあります（例：Ubuntu 24.04 の 8.3.6-0ubuntu0.24.04.13 は修正済み）。その場合は、使っているディストリビューションのお知らせで確認してください。

Note: packages from Ubuntu, Debian, RHEL and other distributions often keep the old version number after a fix (for example, Ubuntu 24.04's 8.3.6-0ubuntu0.24.04.13 is fixed). In that case, check your distribution's security notice.

02

何が起きたのかWhat happened見つかってから修正されるまでFrom discovery to fix

脆弱性は、修正版が出る前に番号（CVE）だけが漏れ、予定より1日早く公開されることになりました。国内では修正版が出る前から、予防のためにサービスを止める会社が相次ぎました。

The vulnerability IDs leaked before the fix was ready, and the release was pulled forward by a day. In Japan, companies started taking services offline as a precaution even before the fix came out.

9.2深刻度（CVSS v4.0、PHPのチーム）。米NISTの評価（v3.1）では9.8severity (CVSS v4.0, PHP team). The US NIST rates it 9.8 on CVSS v3.1
5.4〜少なくともPHP 5.4以降の、ほぼすべての版に影響affects nearly every version from at least PHP 5.4 on
約~211予防のためサービスを止めた国内の組織（10月22日1時時点、piyolog集計）organisations in Japan that paused services (22 Oct, 01:00 JST, piyolog count)
0国内で確認された、この脆弱性による侵入（10月22日時点）confirmed break-ins in Japan through these flaws (as of 22 Oct)

  1. 外部の監査で、最初の兆しが見つかるAn outside audit finds the first signs

    Quarkslabによる監査で、メモリ不足の処理に問題の兆しが見つかりました。ただ、攻撃につながる道筋が見つからず、修正は止まったままでした。PHP Foundationは後に、これを「構造的な失敗」と認めています。

    An audit by Quarkslab found early signs of the out-of-memory problem. No attack path was found and the fix stalled. The PHP Foundation later called this "a structural failure".

  2. 複数の研究者が、同じ根っこの攻撃を報告Several researchers report attacks with the same root

    8月11日にCalifとOpenAI、24日にWiz、9月18日にOpenAIが追加の攻撃経路を報告しました。Wizは、調査にAIのモデルを使ったと公表しています。AIで脆弱性を探す時代になり、古い問題が一気に掘り起こされています。

    Calif and OpenAI reported on 11 August, Wiz on the 24th, and OpenAI reported more attack paths on 18 September. Wiz says it used AI models in its research. With AI now hunting for bugs, old problems are being dug up fast.

  3. CVE番号が漏れ、公開が1日早まるThe CVE IDs leak and the release is moved up a day

    日本時間の21日0時ごろ、CVE番号だけがネット上に出回りました（技術的な中身は出ていません）。PHPのチームは、22日の予定だった修正版の公開を21日に早めると予告しました。

    Around 15:00 UTC, the CVE IDs (but no technical details) started circulating online. The PHP team announced it would move the release from the 22nd to the 21st.

  4. 修正版の公開、国内で予防停止が相次ぐFixes released; Japanese services go offline as a precaution

    日本時間の22時半〜23時ごろ、8.5.12・8.4.27・8.3.36・8.2.35が公開されました。IPAは同日、公開前から「事前準備のお願い」を出しています。報道によると、コドモン、BASE、Cygames、ニコニコ、pixiv、静岡銀行、阪急電鉄などが一時的にサービスを止め、レンタルサーバー各社も緊急メンテナンスを行いました。

    8.5.12, 8.4.27, 8.3.36 and 8.2.35 came out around 13:30–14:00 UTC. Japan's IPA had already asked organisations to get ready that day. According to news reports, CoDMON, BASE, Cygames, Niconico, pixiv, Shizuoka Bank and Hankyu Railway paused services, and hosting companies ran emergency maintenance.

  5. JVNに掲載。悪用は「試み」の段階Listed in JVN; exploitation still at the "attempt" stage

    日本の脆弱性情報サイトJVNに JVNVU#99905564 として掲載されました。CISAは公開時点で悪用を確認しておらず、「悪用が確認された脆弱性」の一覧にも入っていません。一方、セキュリティ企業のwatchTowrは攻撃の試みを観測しています。

    Japan's vulnerability database JVN listed it as JVNVU#99905564. CISA had seen no exploitation at the time of release, and the flaws are not on its Known Exploited Vulnerabilities list. The security firm watchTowr, however, reports seeing attack attempts.

03

しくみ①：途中で投げ出された書類How it works 1: the half-filled formCVE-2026-109618 · out-of-memory corruption

PHPは、Webサイトへのリクエストを「ワーカー」と呼ばれる作業員が1件ずつ処理します。作業員は、届いたフォームの中身をメモリに書き込みながら準備を進めます。

PHP handles each request to a website with a "worker". The worker writes the contents of the incoming form into memory as it gets ready.

ところが途中でメモリが足りなくなると、PHPは作業を投げ出して、いきなり後片付けへ飛びます（C言語のlongjmpという緊急ジャンプ）。後片付け係は、書きかけの箱を「完成品」だと思って読んでしまいます。攻撃者は、わざとメモリが足りなくなるような形のフォームを送り、書きかけの箱に自分の中身が入るよう仕向けます。

But if memory runs out halfway, PHP abandons the job and jumps straight to cleanup (an emergency jump in C called longjmp). The cleanup code then reads the half-written boxes as if they were finished. An attacker sends a form shaped to run memory out on purpose, so that their own bytes end up in those half-written boxes.

細工したフォームが届くと？What a crafted form does
攻撃者が細工したフォームを送る。PHPの作業員はフォームの中身をメモリの箱に書き込んでいく途中でメモリ不足になり、作業を投げ出して後片付けへ飛ぶ。後片付け係は書きかけの箱を完成品として読み、攻撃者が仕込んだ中身によって命令が実行される。修正版では途中で投げ出さず、安全な地点まで進んでから止まる。 攻撃者Attacker PHPの作業員（ワーカー）PHP worker フォームの中身を書き込み中writing the form into memory メモリ不足！Out of memory! 攻撃者の命令が動くattacker's command runs 後片付け係Cleanup request shutdown 緊急ジャンプlongjmp 書きかけを「完成品」として読むreads half-written data as finished 修正版：投げ出さず、安全な地点まで進んでから止めるFixed: no jump; stop only at a safe point
  1. 攻撃者が、形を細工した大きなフォームを送る（ログイン不要）The attacker sends an oddly shaped, large form (no login needed)
  2. 作業員が、中身をメモリの箱に書き込み始めるThe worker starts writing it into memory
  3. 途中でメモリ不足。作業を投げ出して後片付けへ飛ぶMemory runs out. The worker jumps straight to cleanup
  4. 後片付け係が、書きかけの箱を完成品として読むCleanup reads the half-written box as if finished
  5. 箱の中身は攻撃者が仕込んだもの。命令が実行されるThe attacker planted those bytes. Their command runs
  6. 修正版：緊急ジャンプをやめ、安全な地点で止まるThe fix: no emergency jump; stop at a safe point

エンジニア向け：メモリ不足のエラーが longjmp() を起こしたとき、リクエスト用のメモリの一部が「参照はできるが初期化されていない」状態で残り、リクエスト終了処理がその値を読んだり、それに従って分岐したりします。失敗した確保と、壊れるメモリは無関係でもかまいません。長さの宣言がない、パートごとのヘッダー数に上限がない、空のファイル欄、入れ子のフィールド名などのmultipartアップロードで、PHPの見かけの上限内のままメモリを使い切らせることができます。mod_phpはリクエスト開始に失敗しても終了処理を走らせるため、アプリのコードが動く前に成立します。修正では、メモリ不足で longjmp() をせず、次の安全な地点で止める「ソフトなメモリ不足」と、より高い上限での即時終了（_exit()）に変わりました。

For engineers: when an out-of-memory error triggers longjmp(), some request memory is left reachable but uninitialised, and request shutdown then reads it or branches on it. The failed allocation doesn't have to be related to the corrupted memory. Multipart uploads with no declared length, unlimited headers per part, empty file fields or nested field names can exhaust memory while staying inside PHP's apparent limits. mod_php runs shutdown even when request startup fails, so the attack lands before any application code runs. The fix removes the longjmp() on out-of-memory: PHP now records a "soft" OOM and stops at the next safe point, with a hard _exit() at a higher threshold.

04

しくみ②：はがし忘れた付せんHow it works 2: the sticky note nobody removedCVE-2026-109619 · stale global state

PHPの作業員は、速さのために同じ人が何件ものリクエストを続けて担当します。作業中は「メモ：棚3を使用中」のような付せん（内部の参照）を貼り、終わったらはがすのが決まりです。

For speed, the same PHP worker handles request after request. While it works, it keeps sticky notes such as "using shelf 3" (internal references), and the rule is to remove them when it's done.

ところが、致命的なエラーやタイムアウトで作業が中断されると、付せんをはがす手順が飛ばされることがあります。棚3は空けられたのに、付せんだけが残る。次に、攻撃者のリクエストが空いた棚3に自分の中身を置くと、作業員は古い付せんをたどって、それを使ってしまいます。

But when a fatal error or timeout interrupts the work, the step that removes the notes can be skipped. Shelf 3 is emptied, yet the note stays. When the attacker's next request puts its own data on shelf 3, the worker follows the old note and uses it.

古い付せんをたどると？Following a stale note
使い回されるPHPの作業員が、リクエストAのために棚3を使い、付せんにメモする。致命的エラーで後片付けが飛ばされ、棚3は空になるが付せんは残る。攻撃者のリクエストBが棚3に中身を置き、作業員は古い付せんをたどって攻撃者の中身を使ってしまう。修正版では、エラーが起きても付せんを必ず片付ける。 リクエストArequest A 使い回される作業員Reused PHP worker メモ：棚3note: shelf 3 致命的エラーfatal error 攻撃者の中身を使ってしまうuses the attacker's data メモリの棚Memory shelves 12345 次のリクエストnext request 修正版：エラーでも付せんを必ずはがすFixed: notes are always cleared
  1. リクエストAが棚3を使い、作業員が付せんにメモするRequest A uses shelf 3; the worker writes a note
  2. 致命的エラー。棚3は空くが、付せんをはがす手順が飛ばされるA fatal error. Shelf 3 is freed, but removing the note is skipped
  3. 攻撃者の次のリクエストが、空いた棚3に自分の中身を置くThe attacker's next request puts its data on shelf 3
  4. 作業員が古い付せんをたどり、攻撃者の中身を使ってしまうThe worker follows the old note and uses the attacker's data
  5. 修正版：エラーが起きても、付せんは必ずはがすThe fix: notes are cleared even after an error

エンジニア向け：使い回されるワーカーは、エラー・セッション・オブジェクト・拡張機能などのグローバルな状態を持ち、それが1件のリクエストが持つメモリを指しています。本来はメモリを解放する前に初期化されますが、致命的エラー（メモリ不足やタイムアウト）でその初期化が飛ばされたり、後の終了処理で出た診断メッセージが状態を書き戻したりします。成立には、(1) 状態を残す処理、(2) 初期化を飛ばす中断、(3) 同じワーカーで通常の初期化より前に状態を使う処理、の3つが必要です。確認されている「使う側」は、既定で有効なセッションのアップロード進捗（アプリが session_start() を呼ばなくても届く）、ディレクトリ単位の無効・非推奨な設定から出る警告（@ や display_errors=0 で隠しても出る）、PHP 8.5で既定有効の fatal_error_backtraces です。ワーカーが多いと成功率は下がりますが、ゼロにはなりません。メモリの中身が漏れて、パスワードやトークン、APIキーが読まれる恐れもあります。

For engineers: reused workers keep global state (error, session, object and extension data) that points into memory owned by a single request. That state should be reset before the memory is freed, but a fatal error (out of memory, timeout) can skip the reset, and diagnostics raised during later shutdown can repopulate it. Exploitation needs (1) an operation that leaves the state behind, (2) an interruption that skips the reset and (3) a consumer on the same worker that uses the state before normal initialisation. Confirmed consumers are session upload progress, which is on by default and reachable even if the application never calls session_start(); warnings from invalid or deprecated per-directory settings, which fire even when hidden with @ or display_errors=0; and, on PHP 8.5, fatal_error_backtraces, which is on by default. More workers lower the success rate but don't remove the risk. The bug can also leak memory contents, including passwords, tokens and API keys.

まとめIn shortどちらも「途中で中断されたあとの片付けが甘い」という、PHPの奥深くにある古い問題です。アプリをどれだけ丁寧に作っていても、PHPを更新しない限り防げません。Both come down to the same old problem deep inside PHP: sloppy cleanup after an interruption. However carefully your application is written, only updating PHP closes them.

05

影響を受ける環境Which setups are affectedPHPとWebサーバーのつなぎ方（SAPI）による違いIt depends on how PHP is attached to the web server (the SAPI)

PHPの開発元は、Webのリクエストを処理しているすべてのPHPが対象だとしています。危険度は、PHPとWebサーバーのつなぎ方によって変わります。

The PHP project says every PHP installation that serves web requests is affected. How dangerous it is depends on how PHP is attached to the web server.

つなぎ方Setup危険度RiskわかっていることWhat is known
Apache + mod_php最も高いHighest既定の設定のまま、ログインなしで命令実行まで確認済み。アプリのコードが動く前に成立する。Unauthenticated code execution confirmed with default settings, before any application code runs.
PHP-FPM高いHighリクエスト開始の失敗ではワーカーが終わるため①の一部の経路は防がれるが、通常のFPMプールでもセッションのアップロード進捗を使った②の命令実行が確認された。アプリの処理経由での①も確認されている。A failed startup kills the worker, which blocks one path for flaw 1, but flaw 2 was shown to run code through session upload progress on a normal FPM pool, and flaw 1 was confirmed through application code paths.
php-cgi対象AffectedPHPの開発元が対象として名前を挙げている。Named as affected by the PHP project.
LiteSpeed (LSAPI)対象Affected影響を受ける可能性が高い（未検証）。国内のレンタルサーバーで多く使われています。Likely affected (not tested). Widely used by Japanese shared hosting.
FrankenPHP対象Affected既定の設定で知られた経路はないが「影響しないとは言えない」とされる。No known path with default settings, but "not immune".
コマンドラインだけ（cron等）Command line only (cron etc.)低いLow外からのリクエストを受けないので直接の攻撃は受けにくいが、同じPHPがWebでも動いていないか確認を。Doesn't take outside requests, so it's hard to attack directly. Check the same PHP isn't also serving the web.

出典：PHP「Security advisory」（2026年10月21日）、GitHub GHSA-w8hw-w9fx-j79w・GHSA-6wmf-4rv5-p3rp

Sources: PHP security advisory (21 Oct 2026); GitHub advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp

研究者は、WordPress・Drupal・Joomlaの最新版で攻撃が成立することを示しました。「うちは独自開発だから」「WordPressは最新にしている」は理由になりません。問題はPHPの側にあります。

Researchers showed working attacks on the latest WordPress, Drupal and Joomla. "We built our own system" or "our WordPress is up to date" doesn't help. The problem is in PHP.

レンタルサーバー・クラウドを使っている場合If you use shared hosting or the cloud

国内のレンタルサーバー各社は、21日から22日にかけて緊急メンテナンスでPHPを更新しています。ただし古いPHPの扱いは事業者によって違います。管理画面でサイトが使うPHPを確認し、8.2以降の修正版を選んでください。さくらのクラウドは、データベースアプライアンスのphpMyAdminなどの画面を予防のため止めています。いずれも契約先のお知らせが最も確かな情報です。

Japanese hosting companies ran emergency maintenance on 21–22 October to update PHP, but how they handle old PHP versions differs. Check which PHP your site uses in the control panel and pick a fixed release of 8.2 or later. Sakura Cloud has switched off the phpMyAdmin and similar web screens of its database appliance as a precaution. Your provider's own notices are the most reliable source.

06

いますぐやることWhat to do now

  1. 使っているPHPを、すべて洗い出すFind every PHP you run今日today

    会社のWebサイトだけでなく、キャンペーンサイト、問い合わせフォーム、社内システム、PHPが組み込まれた製品（ルーターやNASの管理画面など）も。どのPHPがどのつなぎ方で動いているかは phpinfo() の「Server API」で分かります。

    Not just the main website: campaign sites, contact forms, internal systems and products with PHP built in (router or NAS admin screens, for example). phpinfo() shows the version and, under "Server API", how PHP is attached.

    php -v
    php -i | grep -i 'server api'

  2. 修正版に更新し、ワーカーを再起動するUpdate, then restart every worker今日today

    8.5.12・8.4.27・8.3.36・8.2.35以降へ。更新したあと、PHP-FPMやApacheを再起動して、古いプロセスが残っていないことを確かめます。Linuxのパッケージは番号が変わらないことがあるので、ディストリビューションのお知らせで「CVE-2026-109618/109619 修正済み」と書かれた版かを確認してください。

    To 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later. Then restart PHP-FPM or Apache and make sure no old process is left. Distribution packages may keep the old version number, so check the distribution's notice says CVE-2026-109618/109619 are fixed in your package.

  3. サポート切れのPHPを移行するMove off end-of-life PHP今週this week

    PHP 8.1以前には公式の修正版が出ません。開発元は7.4・8.0・8.1向けに最小限のソースコードの修正を公開していますが、自分でビルドできる人向けです。8.4か8.5へ移るか、修正を出している保守ベンダーの版を使ってください。移れないサイトは、一時的に止めることも検討してください。8.2も2026年12月31日でサポートが終わります。

    PHP 8.1 and older get no official fix. The PHP team published minimal source patches for 7.4, 8.0 and 8.1, but they're for people who build PHP themselves. Move to 8.4 or 8.5, or use a vendor build with the fix backported. Consider taking sites offline if they can't move. PHP 8.2 also reaches end of life on 31 December 2026.

  4. すぐ更新できないときの、当面の対策Stopgaps if you can't update yet

    開発元は「これで安全になるわけではない」と明言しています。更新までの時間かせぎです。

    The PHP project is explicit that these "do not make an installation safe". They only buy time until you update.

    • ①：memory_limit=-1 を php_admin_value で固定（アプリから上書きさせない）。メモリはコンテナやcgroupで制限する。OSの RLIMIT_AS・RLIMIT_DATA は使わない（かえって問題を起こす）
    • ①：post_max_size を小さく（アップロードなしなら8M、ありなら32M）。upload_max_filesize はそれより小さく
    • ①：Webサーバーやプロキシで、リクエストの大きさと形を制限する（長さの宣言がないものも）
    • ②：session.upload_progress.enabled=0 を php.ini やプール設定で入れ、すべてのワーカーを再起動（ini_set() や .user.ini では遅すぎて効かない）
    • ②：PHP 8.5では fatal_error_backtraces=0 も
    • ②：無効・非推奨のディレクトリ単位の設定を消す。外から起こせる致命的エラーやタイムアウトを直す。余裕があれば pm.max_requests=1
    • WAF（Webアプリケーションファイアウォール）は時間かせぎにはなりますが、頼り切らないこと
    • Flaw 1: set memory_limit=-1 with php_admin_value so applications can't override it, and cap memory with a container or cgroup limit instead. Don't use the OS limits RLIMIT_AS or RLIMIT_DATA; they can cause the very failure you're avoiding
    • Flaw 1: lower post_max_size (8M with no uploads, 32M with), keeping upload_max_filesize below it
    • Flaw 1: limit request size and structure at the web server or proxy, including requests with no usable length
    • Flaw 2: set session.upload_progress.enabled=0 in php.ini or the pool config and restart every worker (ini_set() or .user.ini is too late to help)
    • Flaw 2: on PHP 8.5, also set fatal_error_backtraces=0
    • Flaw 2: remove invalid or deprecated per-directory settings and fix fatal errors or timeouts an attacker can trigger. pm.max_requests=1 helps if you can afford it
    • A web application firewall buys time, but don't rely on it
    session.upload_progress.enabled = 0   ; php.ini

  5. 攻撃の痕跡を探すLook for signs of attack今週this week

    • PHPのプロセス（php-fpm、php-cgi、httpd、apache2）が、シェルや curl・wget などを起動していないか
    • 「Allowed memory size … exhausted … Unknown on line 0」のエラーが、異常に大きなPOSTと同じ時刻に出ていないか
    • Apacheのログにセグメンテーション違反（segfault）が出ていないか、ワーカーが不自然に入れ替わっていないか
    • 異常に長い・形のおかしい PHPSESSID のCookieが届いていないか
    • PHP processes (php-fpm, php-cgi, httpd, apache2) starting shells or tools such as curl or wget
    • "Allowed memory size … exhausted … Unknown on line 0" errors at the same time as unusually large POST requests
    • Segfaults in the Apache logs, or workers being replaced for no clear reason
    • Unusually long or malformed PHPSESSID cookies

    疑わしい形跡があれば、メモリから読まれた可能性を考えて、そのサーバーにあるパスワード・APIキー・トークンを入れ替えてください。被害が疑われるときは、JPCERT/CC や IPAの相談窓口へ。

    If anything looks suspicious, assume memory may have been read and rotate the passwords, API keys and tokens on that server. If you suspect a breach, contact JPCERT/CC or IPA's help desk.

07

PHPのサポート期限PHP support dates2026年10月22日時点・php.netよりAs of 22 Oct 2026, from php.net

PHPの各版は、約2年の「通常のサポート」のあと、約2年の「セキュリティ修正だけの期間」を経て終わります。終わった版には、今回のような重大な穴が見つかっても修正が出ません。赤い線が今日です。

Each PHP branch gets about two years of active support, then about two years of security fixes only, and then nothing. Once a branch ends, even a critical hole like this one won't be fixed. The red line is today.

版Branch状態Statusセキュリティ修正の期限Security fixes untilphp2shellの修正版php2shell fix
8.5通常のサポートActive2029年12月31日31 Dec 20298.5.12
8.4通常のサポートActive2028年12月31日31 Dec 20288.4.27
8.3修正のみSecurity only2027年12月31日31 Dec 20278.3.36
8.2まもなく終了Ending soon2026年12月31日31 Dec 20268.2.35
8.1 / 8.0 / 7.4終了End of life2025年12月31日 / 2023年11月26日 / 2022年11月28日31 Dec 2025 / 26 Nov 2023 / 28 Nov 2022なし（ソース修正のみ）none (source patch only)
7.3 以前終了End of life2021年12月6日以前6 Dec 2021 or earlierなしnone

Bekitoのサーバーは？What about Bekito's servers?

2026年10月22日に確認Checked 22 October 2026

Bekitoのサービスを動かすサーバーには、PHPが入っていません。そのため、php2shellの影響はありません。

The servers that run Bekito's services have no PHP installed, so php2shell does not affect them.

古いPHPが外から見えていないか、調べますWe can check whether old PHP is visible from outside

Bekitoの「外から見える入口チェック」は、攻撃者と同じ外側から、古いサーバーソフトや出しっぱなしの管理画面を見つけて、直す順番をお伝えします（攻撃的な通信は行いません）。

Bekito's external entry-point check looks at your company from the outside, the way an attacker would, finds outdated server software and exposed admin screens, and tells you what to fix first. No attack traffic.

入口チェックを見るSee the entry-point check

よくある質問Frequently asked questions

php2shellとは何ですか？What is php2shell?

2026年10月21日に修正された、PHP本体の重大な脆弱性2件（CVE-2026-109618とCVE-2026-109619）の通称です。条件がそろうと、ログインしていない攻撃者がサーバー上で命令を実行できる恐れがあります。深刻度はCVSS v4.0で9.2（PHPのセキュリティチーム）、米NISTのCVSS v3.1では9.8です。公開前に出回った「10.0」は誤りです。

The nickname for two critical flaws in PHP itself, CVE-2026-109618 and CVE-2026-109619, fixed on 21 October 2026. Under the right conditions an attacker who never logs in can run commands on the server. Severity is 9.2 on CVSS v4.0 (PHP security team) and 9.8 on CVSS v3.1 (US NIST). The "10.0" that circulated before release was wrong.

どのバージョンを使えば安全ですか？Which versions are safe?

PHP 8.5.12、8.4.27、8.3.36、8.2.35、またはそれ以降です。8.1以前には公式の修正版が出ないため、8.4か8.5への移行を勧めます。8.2は2026年12月31日でセキュリティ修正も終わります。

PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later. PHP 8.1 and older get no official fix, so we recommend moving to 8.4 or 8.5. PHP 8.2 stops getting security fixes on 31 December 2026.

WordPressを使っていなければ関係ありませんか？If we don't use WordPress, are we safe?

関係あります。問題はPHP本体にあるため、WordPress・Drupal・Joomla・独自開発のシステムなど、PHPでWebのリクエストを処理しているものはすべて対象です。特にApacheのmod_phpでは、アプリのコードが動く前に攻撃が成立することが確認されています。

No. The flaw is in PHP itself, so anything that handles web requests with PHP is affected: WordPress, Drupal, Joomla or a custom system. With Apache's mod_php, the attack has been shown to work before any application code runs.

すでに攻撃されていますか？Is it being exploited?

2026年10月22日時点で、CISA（米国）とIPAは悪用を確認していないとしています。一方、watchTowrは攻撃の試みを観測したと報告しています。CISAの「悪用が確認された脆弱性」の一覧には入っていません。国内で止まったサービスは、いずれも予防のための停止として公表されています。

As of 22 October 2026, CISA (US) and IPA (Japan) say they have not confirmed exploitation, while watchTowr reports seeing attack attempts. The flaws are not on CISA's Known Exploited Vulnerabilities list. The Japanese services that went offline all described it as a precaution.

レンタルサーバーを使っている場合はどうすればよいですか？What should we do on shared hosting?

多くの事業者が緊急メンテナンスでPHPを更新しています。契約先のお知らせを確認し、管理画面でサイトが使うPHPのバージョンを8.2以降の修正版にしてください。古いPHPを選んだままのサイトは、事業者の修正が届かないことがあります。

Most providers have updated PHP in emergency maintenance. Read your provider's notice and set your site to a fixed release of PHP 8.2 or later in the control panel. Sites left on an old PHP version may not get the provider's fix.

「php2shell」と「wp2shell」は同じですか？Are php2shell and wp2shell the same?

違います。wp2shell（2026年7月）はWordPressの脆弱性で、WordPress 7.0.2で直りました。php2shell（2026年10月）はPHP本体の脆弱性で、PHPを更新しないと直りません。

No. wp2shell (July 2026) is a WordPress flaw fixed in WordPress 7.0.2. php2shell (October 2026) is a flaw in PHP itself and is only fixed by updating PHP.

BekitoのサーバーはPHPを使っていますか？Does Bekito use PHP?

使っていません。Bekitoのサービスを動かすサーバーにはPHPが入っていないことを、2026年10月22日に確認しました。

No. We confirmed on 22 October 2026 that none of the servers running Bekito's services has PHP installed.

用語集Glossary

脆弱性Vulnerability
ソフトウェアの弱点。攻撃者に悪用されると、情報を盗まれたり、勝手に操作されたりします。
A weakness in software that an attacker can use to steal data or take control.
CVE
脆弱性ごとに付く世界共通の番号。「CVE-2026-109618」のように書きます。
A worldwide ID number for each vulnerability, such as CVE-2026-109618.
CVSS
脆弱性の深刻度を0〜10で表す指標。9.0以上は「緊急（Critical）」です。
A 0–10 severity score for vulnerabilities. 9.0 and above is "Critical".
リモートコード実行（RCE）Remote code execution (RCE)
離れた場所から、相手のサーバーで好きな命令を動かせること。最も深刻な種類の脆弱性です。
Running any command you like on someone else's server from a distance. The most serious kind of flaw.
ワーカーWorker
リクエストを1件ずつ処理するPHPのプロセス。速さのため、同じワーカーが何件も続けて担当します。
A PHP process that handles one request at a time. For speed, the same worker handles many requests in a row.
SAPI
PHPとWebサーバーのつなぎ方。mod_php（Apacheの中で動く）、PHP-FPM（別のプロセスで動く）、php-cgi などがあります。
How PHP is attached to the web server: mod_php (inside Apache), PHP-FPM (separate worker processes), php-cgi and others.
メモリ不足（OOM）Out of memory (OOM)
処理に必要なメモリを確保できなくなること。PHPでは設定された上限（memory_limit）を超えたときに起きます。
Running out of the memory a job needs. In PHP it happens when a request exceeds memory_limit.
解放後使用（use-after-free）Use-after-free
すでに手放したメモリを、まだ使える物として使ってしまう不具合。他人が置いた中身を使うことになり、乗っ取りにつながります。
Using memory after it has been given back. Someone else's data ends up being used, which can lead to a takeover.
サポート切れ（EOL）End of life (EOL)
開発元が修正を出さなくなった版。新しい脆弱性が見つかっても直りません。
A version the developers no longer fix. New vulnerabilities in it stay open.
JVN
JPCERT/CCとIPAが運営する、日本の脆弱性情報サイト。今回は JVNVU#99905564 です。
Japan's vulnerability database, run by JPCERT/CC and IPA. This one is JVNVU#99905564.
KEV
米CISAの「悪用が確認された脆弱性」の一覧。ここに入ると、実際に攻撃されている証拠があるという意味です。
CISA's Known Exploited Vulnerabilities list. Being on it means there is evidence of real attacks.
WAF
Webアプリケーションファイアウォール。怪しいリクエストを手前で止める仕組み。時間かせぎにはなりますが、更新の代わりにはなりません。
Web application firewall: blocks suspicious requests in front of the site. It buys time but doesn't replace updating.

出典Sources

  1. PHP: Security advisory — CVE-2026-109618, CVE-2026-109619（2026年10月21日）・事前予告（10月20日）
  2. GitHub GHSA-w8hw-w9fx-j79w: RCE via OOM corruption・GHSA-6wmf-4rv5-p3rp: RCE via stale global state（2026年10月21日）
  3. The PHP Foundation: Today's PHP security release and how we're strengthening PHP security（2026年10月21日）
  4. IPA「【事前準備のお願い】PHPのセキュリティリリース公開予定について」（2026年10月21日）
  5. JVNVU#99905564「PHPにおける複数の任意のコードが実行可能な脆弱性」（2026年10月22日）
  6. CISA: Critical Vulnerabilities in PHP Require Immediate Patching（2026年10月21日）
  7. watchTowr: PHP Remote Code Execution (php2shell)（2026年10月21日）
  8. Wiz: php2shell（2026年10月21日）
  9. piyolog：PHPの脆弱性の公開を受けて相次ぐサービスの一時停止（2026年10月21〜22日）
  10. ITmedia NEWS：PHPの脆弱性でサービス一時停止相次ぐ（2026年10月22日）
  11. さくらのクラウド：データベースアプライアンスの一部機能の提供停止について（2026年10月21日）
  12. Ubuntu USN-8948-1: PHP vulnerabilities（2026年10月21日）
  13. PHP: Supported Versions・Unsupported Branches（2026年10月22日閲覧）
  14. WordPress GHSA-7hp8-65ch-5whp (CVE-2026-87902)・WordPress 7.1.2（2026年9月22日）
  15. BleepingComputer: Hackers start exploiting critical WordPress flaw（2026年9月23日）
  16. PHP 8 ChangeLog（8.5.11ほか、2026年9月24日）

このページの内容は2026年10月22日18時時点のものです。悪用の状況や各社の対応は、その後の発表で変わることがあります。

This page reflects information as of 18:00 JST on 22 October 2026. The exploitation status and providers' responses may change with later announcements.