PHPのセキュリティ問題とは？図解で分かるドローン遠隔運用への備え

調査基準日：2026年10月24日（日本時間）。脆弱性の情報は今後も更新される可能性があります。根拠資料は各節と末尾の「出典・参考資料」を開いて確認できます。

PHPとは？ログインや検索の裏側で使われる言語

PHP（ピーエイチピー）は、Webサイトの裏側で行う仕事を、コンピューターに指示するための言語です。たとえば「入力された会員情報を確かめる」「検索した言葉に合うブログを探す」「買い物かごの合計金額を計算する」といった手順を書けます。このように、コンピューターへの指示を書くための言葉を「プログラミング言語」と呼びます。

Webサイトを見ていると、ログインした人によって名前や購入履歴が変わったり、検索した言葉によって結果が変わったりします。こうした動きを作る方法の一つがPHPです。すべてのWebサイトがPHPを使っているわけではありません。

検索ボタンを押してから、結果が表示されるまで

PHPを使ったブログの検索を例にすると、画面の裏側では次のような処理が行われます。

1. 依頼を送る：スマートフォンで「ドローン」と入力して検索すると、サイトを運営する側のコンピューターに「ドローンに関するブログを探して」という依頼が届きます。この、依頼を受けて処理するコンピューターが「サーバー」です。
2. 該当する情報を探す：サーバー上でPHPのプログラムが動き、保存されたブログから該当するものを探します。ブログや会員情報などを整理して保存する仕組みを「データベース」と呼びます。
3. 結果を返す：見つかったブログの一覧を表示するためのデータを、スマートフォンに返します。ChromeやSafariなどの「ブラウザー」がそれを読み取り、検索結果を画面に表示します。

この使い方では、PHPが動くのはサイト運営側のサーバーです。閲覧する人がスマートフォンにPHPを入れたり、PHPの書き方を覚えたりする必要はありません。

PHPで書いた「手順」と、それを実行するソフトがある

ここまでのPHPは、仕事の手順を書くための言語の名前です。その手順を実行するには、サーバーにPHP用のソフトウェアも必要です。これを「PHPの処理系」と呼びます。「PHPを更新する」というときは、主にこのソフトウェアを新しい版に入れ替えることを指します。

下の図では、Webサーバーを依頼を受け取る受付、PHPによる処理を奥の作業場、データベースを書庫にたとえています。PHPで書いたプログラムは作業手順書、処理系はその手順を読み取って作業する仕組みに当たります。

今回のPHP2shellは、この「手順を実行するソフトウェア」で見つかった不具合です。そのため、サイト独自のプログラムに間違いがなくても、使っているPHPの版や設定によっては影響を受けます。後の説明に出てくる「ワーカー」は、処理系の中で依頼を引き受ける個々の作業プロセスのことで、作業場の担当者に当たります。

WordPressを最新にしても、PHPの更新は別に必要

WordPressは、ブログの投稿やWebサイトの管理に使うソフトウェアです。その多くの処理がPHPで書かれており、サーバーに入っているPHPの処理系が実行します。WordPress.orgは、WordPressを動かすサーバーにPHP 8.3以上を推奨しています。管理画面からWordPress本体やプラグインを更新しても、その下で動いているPHPの処理系は入れ替わりません。

PHPの更新担当は契約によって変わります。レンタルサーバーでは提供会社が修正を配布しても、利用者側でバージョンの切り替えや動作確認が必要な場合があります。自社運用なら、自社の管理担当者が適用します。IPAは、PHPがソフトウェア製品やネットワーク機器の内部で使われている場合もあり、利用者側からは把握できないことがあると注意しています。

出典・参考資料

1. The PHP Group「What is PHP and what can it do?」（更新日の記載なし） https://www.php.net/intro
2. The PHP Group「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日） https://www.php.net/archive/2026.php#2026-10-21-5
3. WordPress.org「Requirements」（更新日の記載なし） https://wordpress.org/about/requirements/
4. IPA（情報処理推進機構）「【事前準備のお願い】PHPのセキュリティリリース公開予定について」（公開2026年10月21日、最終更新2026年10月22日） https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html

PHP2shellは、内部データの扱いを誤る2つの欠陥

PHP2shellは、2つの脆弱性CVE-2026-109618とCVE-2026-109619の通称です。脆弱性とは、攻撃に悪用され得るソフトウェアなどの弱点のことです。深刻度は、共通の評価基準CVSS（v4.0）でいずれも10点満点中9.2とされています。

公表から追加情報までの経緯

表1　PHP2shellの公表から追加情報までの流れ

日付（各発表の掲載日）	出来事
10月20日	PHP公式が、2件の重大な脆弱性を修正するリリースを翌21日14時（協定世界時）に出すと事前告知
10月21日	IPAが更新の事前準備を呼びかけ。日本時間の同日23時、PHP公式が修正版4本と注意喚起を公開
10月22日	IPAとJPCERT/CCが注意喚起を公開
10月23日	PHP公式が、まれな設定の組み合わせで残る経路について追加情報を公開

修正版は、PHP 8.2.35、8.3.36、8.4.27、8.5.12です。8.2〜8.5の各系列では、これより前の版が影響を受けます。調査に関わったWizは、PHP 5.4までさかのぼるほぼすべての版が、少なくとも一方の脆弱性の影響を受けるとしています。

作業用のメモリを、片付けるとき・使い直すときに間違える

セキュリティホールとは、攻撃者に悪用されるおそれのあるソフトウェアの不具合や設定上の弱点です。今回のPHP2shellでは、処理の途中で使うデータの準備や後片付けに不具合がありました。

コンピューターは、計算中の数字や入力された情報を、一時的な作業場所に置きます。これが「メモリ」です。書類を広げる作業台のような場所です。依頼が終わったら片付け、同じ場所を次の依頼に使います。「片付ける」は、保存したブログや会員情報を消すことではなく、作業場所を再び使えるようにすることです。

1つ目：作りかけのデータを、完成したものとして片付けてしまう

通常は、処理に必要なデータを準備し、使い終わってから片付けます。ところが、準備の途中でメモリが足りなくなると、PHPはその依頼の処理を打ち切ります。

このとき、一部のデータが作りかけなのに、後片付けの処理が完成済みのデータとして扱ってしまうのが1つ目の欠陥です。作業場なら、まだ記入中の書類を完成した書類と勘違いして、その内容に従って片付けを進めてしまうようなものです。

2つ目：片付けた場所を指す、古いメモを使ってしまう

データの置き場所を記録した情報は、その場所を使い終わったら無効にする必要があります。ところが、作業場所を空けた後も、古い置き場所の情報が残る場合がありました。次の依頼の処理が、それを更新する前に使ってしまいます。

作業場なら、前の依頼で使った「書類は3番の机」というメモを、次の依頼でも信じてしまう状態です。同じ担当者が続けて依頼を処理する場合もあります。3番の机はすでに片付けられ、別の仕事に使われているかもしれません。コンピューターでも、以前のデータが今もそこにあると思い込んで、使ってはいけないメモリを扱ってしまいます。

なぜ「処理のミス」が、外部からの攻撃につながるのか

Webサイトは、外部から届いた検索やフォーム送信などの依頼を処理します。攻撃者も、その入口にデータを送れます。問題のあるPHPでは、細工した入力によって上のような不具合を起こし、メモリの内容を誤って扱わせる攻撃が成立する場合があります。

結果は処理の停止だけとは限りません。条件がそろうと、PHPが扱うデータや処理の流れが乱され、サイトの運営者が意図しないプログラムを、外部の攻撃者に実行されるおそれがあります。これを「リモートコード実行（RCE）」と呼びます。PHP公式は、今回の欠陥で実際にその状態を起こせることを確認しています。

PHP公式は、WebサーバーにPHPを組み込んで動かす方式（Apacheのmod_php）で、ログイン前に攻撃が成立した例を報告しています。PHP-FPMなど、別の動かし方も影響の確認が必要です。2つの欠陥は、それぞれ別の問題で、両方を順番に使わなければ攻撃できないという意味ではありません。

2つの脆弱性を技術的に比較する

表2　PHP2shellを構成する2つの脆弱性（PHP公式の説明にもとづく）

項目	CVE-2026-109618	CVE-2026-109619
公式の名称	RCE via OOM corruption（メモリ不足時の破損によるリモートコード実行）	RCE via stale global state（古い内部状態の残存によるリモートコード実行）
何が起きるか	メモリ不足で処理が途中で打ち切られ、作りかけの内部データを後始末の処理が正しいものとして扱う	前の要求のメモリを指す内部情報が解放後も残り、同じワーカーの次の要求が初期化前にそれを使う
公式に確認された成立例	mod_phpで、ログインなしの要求によるリモートコード実行を既定の設定で実証。PHP-FPMなども対象	致命的なエラー時の呼び出し履歴を残す機能（PHP 8.5）や、アップロード進捗の機能を通じた経路で確認（mod_php、PHP-FPM）
深刻度	CVSS v4.0　9.2	CVSS v4.0　9.2

名称の日本語は編集部の訳です。

多要素認証だけではPHPの欠陥を解消できない

推測されにくいパスワードを選び、ほかのサービスと使い回さなければ、パスワードを突破される危険を減らせます。ただし、すでに盗まれたパスワードは、文字列が複雑でも使われてしまいます。その場合の不正ログインを防ぐ対策が、多要素認証（パスワードに加えてスマートフォンでの確認などを求める仕組み）です。

PHP2shellでは、ログインの認証より前に攻撃が成立する場合があります。ログイン画面そのものもPHPの上で動くプログラムの一部で、mod_phpの実証では、攻撃はアプリケーションのコードが動き出す前に成立しています。そのため、強いパスワードや多要素認証を使っていても、この攻撃は防げません。多要素認証は引き続き必要な対策ですが、今回の欠陥を解消するのはPHPの更新です。

サーバーの権限が広いほど、盗難・改ざんの被害も広がる

JPCERT/CCは、PHP2shellが悪用された場合、PHPの実行プロセスの権限で任意のコードを実行される可能性があると説明しています。

影響の範囲は、PHPを動かすアカウントが読み書きできるファイル、サーバーに保存された認証情報、そのサーバーから接続できる先で決まります。情報の窃取、改ざん、サービスの停止が起こり得ますが、読み書きの権限や接続先が多いほど、被害が広がるおそれがあります。調査したWizは、プログラムの実行に至らなくても、ワーカーのメモリから他の要求のパスワードやAPIキーなどを読み出せる場合があると説明しています。

10月23日、一部の設定で攻撃を受けるおそれが残ると追加発表

修正版の公開から2日後の10月23日、PHP公式は追加の情報を出しました。アプリケーションが実行中にセッションの保存形式を特定の形式へ切り替え、なおかつアップロード進捗の機能を有効にしている、という珍しい組み合わせのときに限り、可能性の低いRCEの経路が残るという内容です。

PHP公式は、次の定期リリースまでアップロード進捗の機能を無効にする設定（session.upload_progress.enabled=0）を勧めています。実行中に保存形式を切り替えないアプリケーションは、有効のままで構わないとされています。この経路は次の定期リリースで扱われ、CVE-2026-115560として詳細が公表される予定です。10月21日の修正版は2件のCVEへの対策で、この追加の経路まで閉じるものではありません。

修正版の公開時点と、その後の攻撃観測

PHP財団によると、修正版の公開前日に脆弱性の存在が外部に漏れ、実証コード（PoC）が出回り始めました。PHPのセキュリティチームは、公開時点で、出回ったPoCのうち実際に機能するものは確認していないとしています。CVEの記録に米CISAが付けた評価も、10月21日時点では悪用「なし」です。

一方、セキュリティ企業のwatchTowrは、攻撃を観測するためのおとりのサーバー（ハニーポット）で、10月21日に両方の脆弱性の悪用を観測したと公表しています。IPAとJPCERT/CCの10月22日の注意喚起は悪用の有無に触れていません。

攻撃の観測は、個々の企業で被害が出たことまで示すものではありません。一方、被害の報告が見当たらなくても、自社のサーバーの安全は保証されません。修正の適用状況と侵害の有無を調べる必要があります。

提供元の修正情報と、実際の適用状況を確認する

「8.3.36以上なら大丈夫」と番号だけで判断できないことがあります。PHP公式は、Linuxのディストリビューションや長期サポートの提供会社には事前に修正を渡しており、それぞれの更新パッケージを確認するよう案内しています。こうしたパッケージでは、修正を取り込んだかどうかを提供元の情報で確かめます。

製品に組み込まれたPHPは、利用者が直接入れ替えられないことがあります。たとえばSiemensは10月23日、産業用のネットワーク機器RUGGEDCOM APE1808（Palo Alto NetworksのPAN-OSを搭載）が影響を受けるとし、修正は同社サポートから入手するよう案内しています。こうした製品では、提供元が修正を取り込んで配るまで更新は完了しません。

PHP 8.1以前の系列には公式の修正版が出ておらず（7.4〜8.1向けには最小限のソースコードの修正だけを公開）、PHP 8.2も公式の修正は2026年12月31日で終わります。IPAは事前告知で、2024年にも別のPHPの脆弱性（CVE-2024-4577）を狙う攻撃を注意喚起したことに触れています。発生条件も攻撃の方法も、今回とは別の問題です。

出典・参考資料

1. The PHP Group「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日） https://www.php.net/archive/2026.php#2026-10-21-5
2. IPA（情報処理推進機構）「【事前準備のお願い】PHPのセキュリティリリース公開予定について」（公開2026年10月21日、最終更新2026年10月22日） https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html
3. IPA「PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)」（公開2026年10月22日） https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html
4. The PHP Group「Upcoming Critical PHP Security Release」（2026年10月20日） https://www.php.net/archive/2026.php#2026-10-20-1
5. JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」JPCERT-AT-2026-0033（公開・更新2026年10月22日） https://www.jpcert.or.jp/at/2026/at260033.html
6. The PHP Group「Informational advisory: Session upload progress」（2026年10月23日） https://www.php.net/archive/2026.php#2026-10-23-1
7. GitHub php/php-src Security Advisory「RCE via OOM corruption」GHSA-w8hw-w9fx-j79w（公開2026年10月21日） https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
8. GitHub php/php-src Security Advisory「RCE via stale global state」GHSA-6wmf-4rv5-p3rp（公開2026年10月21日） https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
9. The PHP Foundation「Today’s PHP Security Release, and How We’re Strengthening PHP Security」（2026年10月21日） https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
10. CVE Program「CVE-2026-109618」（公開2026年10月21日、更新2026年10月23日） https://www.cve.org/CVERecord?id=CVE-2026-109618
11. CVE Program「CVE-2026-109619」（公開2026年10月21日、更新2026年10月23日） https://www.cve.org/CVERecord?id=CVE-2026-109619
12. Wiz Research「PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet」（2026年10月21日） https://www.wiz.io/blog/php2shell-php-rce
13. watchTowr「PHP Remote Code Execution (“PHP2Shell” CVE-2026-109618 & CVE-2026-109619)」（公開2026年10月21日、更新2026年10月22日） https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/
14. Siemens ProductCERT「SSA-566512: PHP2Shell Vulnerabilities in Palo Alto Networks PAN-OS on RUGGEDCOM APE1808 Devices」（2026年10月23日） https://cert-portal.siemens.com/productcert/html/ssa-566512.html
15. The PHP Group「PHP 8.2.35 Released!」（2026年10月21日） https://www.php.net/archive/2026.php#2026-10-21-1
16. IPA「PHPの脆弱性（CVE-2024-4577）を狙う攻撃について」（公開2024年7月5日、最終更新2024年7月12日）※今回とは別の脆弱性 https://www.ipa.go.jp/security/security-alert/2024/alert_20240705.html
17. 英国NCSC（National Cyber Security Centre）「Critical security issue affecting PHP」（2026年10月21日） https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php

遠隔運用は端末・クラウド・通信・機体で成り立つ

ドックを使う遠隔運用では、操作端末から運航管理サービス、通信回線、ドックを経由して機体に指示を送ります。図は役割を説明するための構成例で、実際の接続方法や装置の数は製品によって異なります。

図の「通信・API」は、通信の経路と、システム同士が指示を受け渡す仕組みをまとめた表示です。APIはソフトウェア同士の窓口で、図のルーターのような機械そのものではありません。実際には、運航管理サービスやドックなどのソフトウェアが持つ機能です。経済産業省とNEDOの「無人航空機分野 サイバーセキュリティガイドライン」も、ドローン本体、地上制御局、ドローン運用クラウド、サービス運用クラウドを構成要素として、その間のデータの流れからリスクを整理しています。

映像の配信と機体への指示は、通信経路が異なる場合がある

運航管理の画面が1つでも、映像と操作の指示には別々のサーバーや通信方式を使う場合があります。たとえばDJIが開発者向けに公開しているCloud APIの資料では、ドックを外部のクラウドとつなぐ場合、設定や指示のやり取りにはMQTTという通信方式を使い、映像の配信にはRTMPなど別の方式と配信用のサーバーを使う構成が説明されています。遠隔からのリアルタイム操縦も、ほかの機能とは別の命令群として整理されています。

これは外部のクラウドと連携する場合の一例で、ほかの製品にそのまま当てはまるわけではありません。侵害されたサーバーが映像の配信だけを担うのか、機体への指示も扱うのか、どの操作権限を持つのかによって、被害の範囲は変わります。

広報サイトと運航管理の接続・アカウントを分ける

広報サイトの侵害が機体の操作に及ぶかは、運航管理側への接続経路や権限があるかで変わります。サーバーと認証情報を分け、相互の接続を制限すれば、侵害が広がる経路を減らせます。同じサーバーで両方を動かしたり、パスワードや管理者アカウントを共用したりすると、広報サイトへの侵入が運航管理側に及ぶおそれがあります。

出典・参考資料

1. 経済産業省「無人航空機を対象としたサイバーセキュリティガイドラインを策定」（2022年3月31日） https://www.meti.go.jp/policy/mono_info_service/mono/robot/drone_cybersecurity.html
2. DJI Developer「Cloud API：Live Stream（Dock Feature Set）」（更新日の記載なし） https://developer.dji.com/doc/cloud-api-tutorial/en/feature-set/dock-feature-set/dock-livestream.html
3. DJI Developer「Cloud API：Tutorial Reading Guide」（更新日の記載なし） https://developer.dji.com/doc/cloud-api-tutorial/en/tutorial-map.html

運航管理サーバーへの侵入で起こり得る4つの被害

事務所から、離れたA工場の屋根をドローンで点検する場面を考えます。担当者はパソコンから飛行計画を送り、屋根の映像を見ています。ここで、運航管理に使うサーバーが侵入されたら、何が起きるでしょうか。

以下は仕組みを説明するための仮定の例で、実際の被害報告ではありません。PHP2shellを入口に被害が起きるには、関係するサーバーで影響を受けるPHPが使われ、攻撃が成立する条件が必要です。特定製品のPHP使用や被害の有無を示すものではありません。

例1：点検中に管理画面が使えず、次の指示を送れない

侵入されたサーバーが停止すると、そのサーバーを通じて送る飛行計画や操作指示が届かなくなるおそれがあります。映像の配信も同じサーバーに依存していれば、屋根の映像も確認できなくなります。復旧するまで次の点検を始められず、現地の担当者による確認が必要になるかもしれません。

画面が止まっただけで、機体が直ちに墜落するわけではありません。飛行計画の続行、帰還、待機、着陸のどれになるかは、どの通信が失われたか、機種、設定によって変わります。管理画面が止まっても、機体の中の飛行制御まで止まるとは限りません。

例2：飛行は正常でも、工場の映像や位置情報が盗まれる

点検は予定どおり進み、画面にも異常がありません。しかし、侵入されたサーバーに映像や飛行ログが保存され、攻撃者がそれを読める権限を得ていれば、工場の設備や撮影地点を知られるおそれがあります。保存先が別でも、そのデータにアクセスするための認証情報を盗まれれば、被害が及ぶ場合があります。

この例では機体を操縦する権限は必要ありません。映像を読む権限と、機体を飛ばす権限を分けても、映像の保管先へのアクセスは別に守る必要があります。

例3：点検する屋根の位置や、撮影の設定を書き換えられる

翌朝に使う飛行計画が保存されているとします。攻撃者が計画の変更権限まで得ると、A工場の屋根を撮る計画をB工場向けに変えたり、撮影設定を書き換えたりするおそれがあります。担当者が気づかず実行すれば、必要な屋根を撮れていない、予定外の場所を撮影した、といった結果になり得ます。

実際にその計画で飛ぶには、変更後の計画が機体へ送られる必要があります。承認や機体側のチェックが設定されていれば、それを通過するか回避しなければ実行されません。保存された計画の変更だけで、すでに飛行中の機体が即座に進路を変えるとは限りません。

例4：離陸の権限まで奪われ、不正な指示が受け付けられる

サーバーからドックへ離陸を指示でき、そのための認証情報や権限まで奪われた場合は、予定外の離陸につながるおそれがあります。飛行中の操縦機能にアクセスできる構成なら、不正な操作指示が送られることも考えられます。

ただし、どちらも制御用の接続先に届き、必要な権限が認められ、人や機体のチェックを通過するか回避することが条件です。PHPの欠陥を悪用できたことと、ドローンを自由に操縦できることは同じではありません。会社紹介のWebサイトに侵入されても、ドローンの制御系へ接続できず、操作用の認証情報もなければ、この例のように指示を送ることはできません。

どの被害が起こり得るかを知るには、利用中のサーバーが持つデータ、接続先、操作権限を確かめる必要があります。

4つの被害が起きる条件と対策を表で確認する

表3　Web側の侵害で起こり得る4つの影響（一般的な考察）

影響	起きること	影響が生じる条件	被害を抑える備え
1　業務が止まる	管理画面に入れない、計画を送れない	運航管理のサーバーが侵害される、または停止する。更新や調査のために提供会社がサービスを止める場合も含む	提供会社の更新・復旧の手順、停止中の代替手段（現地での操作など）を決めておく
2　情報が漏れる	映像、飛行ログ、計画、施設の位置が見られる	侵害されたサーバーがそのデータを保存・中継している、またはデータを読める認証情報を持っている	サーバーの権限を最小にする、データの保存先を分ける、不要なデータを残さない
3　設定や計画が書き換えられる	飛行経路、撮影設定、飛行可能範囲（ジオフェンス）が変えられる	制御用のAPIキーやトークン、変更権限を持つアカウントに到達する	制御用の認証情報を広報サイトと共有しない。運航管理側でも必要な処理だけに利用を許し、失効・承認・記録の仕組みを用意する
4　飛行に影響する	計画外の離陸、経路からの逸脱	攻撃者が制御経路や権限を得て、不正な計画・指示が承認や機体側のチェックを通過する、またはそれらを回避する	機体側の飛行範囲の制限、離陸前のオペレーター確認、異常時の動作設定

飛行へ影響するかどうかは、制御経路への接続、操作権限、指示の確認方法によって変わります。人の承認と機体側の制限を組み合わせれば被害を抑えられますが、確認画面の情報自体が改ざんされる可能性もあるため、承認だけに頼らない設計が必要です。たとえばDJIは、ドックの新製品DJI Dock 4について、外部の通報システムからの知らせで出動の手順を始められる一方、機体を出す前にオペレーターの確認を必須にしていると説明しています。外部の通報を誰が確認し、どの操作で離陸を許可するのか。自社が使う製品と運用条件で確かめてください。

出典・参考資料

1. DJI Enterprise「6 Things to Know About DJI Dock 4, DJI’s First Battery-Swapping Dock」（2026年10月14日） https://enterprise-insights.dji.com/blog/dji-dock-4-battery-swapping-dock

更新担当と通信断への備えを決める8項目

遠隔運用を始める前に、次の8項目の担当者と手順を決めます。クラウド側を提供会社が管理する場合も、自社で確認する窓口を用意してください。

通信が切れたときの帰還・着陸は、飛行場所に合わせて選ぶ

DJIの飛行計画ファイルの仕様には、通信を失ったときに計画を続けるか、帰還・着陸・ホバリングのいずれかに切り替えるかを指定する項目があります。オープンソースの飛行制御ソフトArduPilotも、地上局との通信が切れたときの動作を着陸や帰還などから選ぶ方式で、通信が戻っても元の飛行モードには自動で戻らないと説明しています。

どれが安全かは、場所、電池の残り、帰り道の障害物、機種、飛行計画で変わります。市街地の上でその場に着陸させれば人や車の上に降りるおそれがあり、電池が少ないまま遠い離陸地点へ帰還させれば途中で電池が尽きるおそれがあります。飛行計画ごとに動作を選び、そのとき現場の誰が何をするかまで決めておきます。

暗号化・VPN・多要素認証・WAFが守る範囲と、守れない範囲

通信の暗号化は途中の盗み見を、多要素認証は盗まれたパスワードによるログインを防ぐ対策です。サーバー上のPHPの欠陥は、これらを導入しても残ります。

表4　よく挙がる対策が守る範囲

用途と構成に合う対策を組み合わせます。ただし、これらは欠陥のあるソフトウェアを更新する代わりにはなりません。

出典・参考資料

1. The PHP Group「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日） https://www.php.net/archive/2026.php#2026-10-21-5
2. Wiz Research「PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet」（2026年10月21日） https://www.wiz.io/blog/php2shell-php-rce
3. The PHP Group「PHP 8.2.35 Released!」（2026年10月21日） https://www.php.net/archive/2026.php#2026-10-21-1
4. DJI Developer「Cloud API：template.kml 说明（DJI WPML）」中国語版（更新日の記載なし） https://developer.dji.com/doc/cloud-api-tutorial/cn/api-reference/dji-wpml/template-kml.html
5. ArduPilot Dev Team「GCS Failsafe（Copter documentation）」（更新日の記載なし） https://ardupilot.org/copter/docs/gcs-failsafe.html

導入前の打ち合わせで提供会社に聞く7つの質問

機体やドックを選ぶときは、更新の担当範囲、通信断時の動作、サポート期限も提供会社に確認してください。打ち合わせでは、次の7つを聞いておきましょう。

無料ダウンロード：提供会社に聞いておきたい10の質問

「何を聞けばよいかは分かったけれど、打ち合わせで漏れなく確認したい」。そんなときに使える、書き込み式の「ドローン遠隔運用の確認シート」を用意しました。

このブログで紹介した確認項目を、本人確認や映像データの扱いも含めて10の質問にまとめています。更新する人、操作できる人、通信が切れたときの動作を、提供会社と一緒に確かめてください。

印刷して使うPDF版

接続の見取り図、10の質問と回答欄、自社の運用・連絡先メモをまとめたA4・3ページ。打ち合わせへの持参や社内共有に使えます。

PDFを無料ダウンロード

回答を入力するExcel版

回答の状態、根拠となる資料、追加で確認すること、担当者・期限を記録できます。「10の質問」「自社の運用」の2シート構成です。

Excelを無料ダウンロード

どちらも無料・登録不要です。PDFがブラウザーで開いた場合は、表示画面の保存ボタンからダウンロードできます。機体の動作や対応手順は、使用する機種・設定・飛行場所に合わせて確認してください。

導入前に更新担当を決め、利用中のサービスは対応状況を聞く

遠隔運用では、機体やカメラに加えて、運航管理サーバーの保守も必要です。導入前に、自社と提供会社のどちらがソフトウェアを更新するのか、完了を誰が確認するのかを決めておきます。

あわせて、誰に閲覧・計画変更・離陸の権限を与えるか、通信が切れたら機体をどう動かし、誰が現場で対応するかを決めます。すでにサービスを利用している場合は、提供会社にPHP2shellの影響の有無と修正の適用状況を尋ねてください。

よくある質問

出典・参考資料

調査基準日：2026年10月24日（日本時間）。日付は各資料の掲載日・更新日です（記載がないものはその旨を記載）。

1. [1]PHP公式サイト（The PHP Group）トップページ（更新日の記載なし） https://www.php.net/
2. [2]The PHP Group「Security advisory: Critical remote code execution vulnerabilities, update now」（2026年10月21日） https://www.php.net/archive/2026.php#2026-10-21-5
3. [3]WordPress.org「Requirements」（更新日の記載なし） https://wordpress.org/about/requirements/
4. [4]IPA（情報処理推進機構）「【事前準備のお願い】PHPのセキュリティリリース公開予定について」（公開2026年10月21日、最終更新2026年10月22日） https://www.ipa.go.jp/security/security-alert/2026/pre-alert20261021.html
5. [5]IPA「PHPの脆弱性対策について(CVE-2026-109618、CVE-2026-109619：PHP2shell)」（公開2026年10月22日） https://www.ipa.go.jp/security/security-alert/2026/alert20261022.html
6. [6]The PHP Group「Upcoming Critical PHP Security Release」（2026年10月20日） https://www.php.net/archive/2026.php#2026-10-20-1
7. [7]JPCERT/CC「PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起」JPCERT-AT-2026-0033（公開・更新2026年10月22日） https://www.jpcert.or.jp/at/2026/at260033.html
8. [8]The PHP Group「Informational advisory: Session upload progress」（2026年10月23日） https://www.php.net/archive/2026.php#2026-10-23-1
9. [9]GitHub php/php-src Security Advisory「RCE via OOM corruption」GHSA-w8hw-w9fx-j79w（公開2026年10月21日） https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
10. [10]GitHub php/php-src Security Advisory「RCE via stale global state」GHSA-6wmf-4rv5-p3rp（公開2026年10月21日） https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
11. [11]The PHP Foundation「Today’s PHP Security Release, and How We’re Strengthening PHP Security」（2026年10月21日） https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
12. [12]CVE Program「CVE-2026-109618」（公開2026年10月21日、更新2026年10月23日） https://www.cve.org/CVERecord?id=CVE-2026-109618
13. [13]CVE Program「CVE-2026-109619」（公開2026年10月21日、更新2026年10月23日） https://www.cve.org/CVERecord?id=CVE-2026-109619
14. [14]Wiz Research「PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet」（2026年10月21日） https://www.wiz.io/blog/php2shell-php-rce
15. [15]watchTowr「PHP Remote Code Execution (“PHP2Shell” CVE-2026-109618 & CVE-2026-109619)」（公開2026年10月21日、更新2026年10月22日） https://watchtowr.com/intelligence/php-remote-code-execution-php2shell/
16. [16]Siemens ProductCERT「SSA-566512: PHP2Shell Vulnerabilities in Palo Alto Networks PAN-OS on RUGGEDCOM APE1808 Devices」（2026年10月23日） https://cert-portal.siemens.com/productcert/html/ssa-566512.html
17. [17]The PHP Group「PHP 8.2.35 Released!」（2026年10月21日） https://www.php.net/archive/2026.php#2026-10-21-1
18. [18]IPA「PHPの脆弱性（CVE-2024-4577）を狙う攻撃について」（公開2024年7月5日、最終更新2024年7月12日）※今回とは別の脆弱性 https://www.ipa.go.jp/security/security-alert/2024/alert_20240705.html
19. [19]英国NCSC（National Cyber Security Centre）「Critical security issue affecting PHP」（2026年10月21日） https://www.ncsc.gov.uk/news/critical-security-issue-affecting-php
20. [20]経済産業省「無人航空機を対象としたサイバーセキュリティガイドラインを策定」（2022年3月31日） https://www.meti.go.jp/policy/mono_info_service/mono/robot/drone_cybersecurity.html
21. [21]DJI Developer「Cloud API：Live Stream（Dock Feature Set）」（更新日の記載なし） https://developer.dji.com/doc/cloud-api-tutorial/en/feature-set/dock-feature-set/dock-livestream.html
22. [22]DJI Developer「Cloud API：Tutorial Reading Guide」（更新日の記載なし） https://developer.dji.com/doc/cloud-api-tutorial/en/tutorial-map.html
23. [23]DJI Enterprise「6 Things to Know About DJI Dock 4, DJI’s First Battery-Swapping Dock」（2026年10月14日） https://enterprise-insights.dji.com/blog/dji-dock-4-battery-swapping-dock
24. [24]DJI Developer「Cloud API：template.kml 说明（DJI WPML）」中国語版（更新日の記載なし） https://developer.dji.com/doc/cloud-api-tutorial/cn/api-reference/dji-wpml/template-kml.html
25. [25]ArduPilot Dev Team「GCS Failsafe（Copter documentation）」（更新日の記載なし） https://ardupilot.org/copter/docs/gcs-failsafe.html

※このブログは、2026年10月24日時点の公開情報にもとづく解説です。特定の製品やサービスが安全であること、または影響を受けることを示すものではありません。自社のシステムへの対応は、サーバーや製品の提供元の情報にもとづいて判断してください。