PHPの重大脆弱性、ドローンは大丈夫かー守るべきは機体だけではない
PHPの重大な脆弱性が公表されました。
ウェブサイトや業務システムの問題だから、ドローンには関係ない。そう考えたくなるニュースです。しかし、ドローンを遠隔で動かし、撮影データをクラウドで管理する運用では、機体の外側にあるシステムも見なければなりません。
問われるのは、ドローンにPHPが載っているかどうかだけではありません。
飛行を予約する画面、点検画像を共有するサービス、顧客向けの報告書サイト。そこに問題が起きたとき、データや運用をどこまで守れるか。今回のPHP問題は、ドローンの安全を「機体の性能」から考えるだけでは足りないことを示しています。
今回のPHP問題は、何が深刻なのか
PHP開発チームは2026年10月21日、認証なしで外部からコードを実行される可能性がある、二つの重大な脆弱性を修正したと発表しました。識別番号はCVE-2026-109618とCVE-2026-109619です。
公開された修正版はPHP 8.2.35、8.3.36、8.4.27、8.5.12。同チームは、ウェブリクエストを処理するPHP環境に広く注意を促し、更新を求めています。構成によって攻撃の成立条件は異なりますが、設定変更だけで完全に対処できる問題とはしていません。
外部からコードを実行されるとは、サーバー上で、本来の管理者が意図しない処理を動かされる可能性があるということです。その先に何が起きるかは、サーバーが持つ権限や、接続できるシステムによって変わります。
特に注意したいのは、「ログイン画面があるから大丈夫」とは言い切れない点です。PHP公式は、Apacheのmod_phpを使う構成では、アプリケーションの処理が始まる前に攻撃が成立する実証例があると説明しています。
業務アプリの認証が適切でも、その土台にあるソフトウェアの更新は別に必要です。
ドローンへの影響は、三つに分けて考える
今回の脆弱性が、すべてのドローンに直接影響するわけではありません。個別製品がPHPを使っているか、対象のバージョンか、外部から到達できるかを確認しなければ、影響の有無は判断できません。
そのうえで、ドローン運用では次の三つを分けて確認したいところです。
広報サイト・問い合わせサイト：情報の流出や改ざん、利用者への偽情報の掲載。
画像・点群・報告書の管理システム：機密データの流出、削除、点検結果の改ざん。
遠隔運航・機体管理システム：保有する権限次第で、設定や運航業務に影響する可能性。
これは今回確認されたドローン被害の一覧ではありません。システムの役割から考えられる、影響の整理です。
同じPHPの脆弱性でも、広報サイトが独立している場合と、運航システムへの接続権限を持つサーバーでは、被害の広がり方が違います。「PHPを使っている」という情報だけでも、「使っていない」という回答だけでも、運用全体の安全性は分かりません。
ウェブサーバーへの侵入が、すぐ機体の乗っ取りになるわけではない
ここは慎重に考える必要があります。
ウェブサーバーを侵害されたからといって、直ちに飛行中のドローンを操れるとは限りません。機体へ命令する経路が分離され、操作権限が限定され、機体側でも指示を確認する仕組みがあれば、影響を抑えられる可能性があります。
逆に、画像を共有するサーバーと運航管理が強い権限でつながっていれば、問題は広がりやすくなります。
例えば、点検画像の配信システムが、遠隔操作に必要な認証情報まで保持している。閲覧専用の担当者が使う画面と、機体設定を変更する機能が十分に分かれていない。こうした構成では、一つの侵入口が別の仕事に及ぶおそれがあります。
重要なのは、何でも一つの画面にまとめられることと、裏側の権限まで一体化することを混同しないことです。
使う人には分かりやすく、侵入された場合には被害を広げにくくする。遠隔運航システムには、その両立が求められます。NISTのOTセキュリティ指針も、物理的な設備を扱うシステムについて、安全性や可用性を踏まえたネットワーク分離、アクセス管理などを扱っています。
「暗号化しています」だけでは、答えにならない
ドローンのセキュリティ説明では、通信の暗号化がよく登場します。しかし、通信を盗み見られにくくすることと、正規の操作端末を乗っ取られた場合の対策は別です。
参考になるのが、ArduPilotの公式文書です。
同文書は、地上局ソフトウェアが機体の設定変更やミッションの送信など、強い操作権限を持つことを説明し、地上局を動かすコンピューター自体の保護や、接続先の確認を求めています。
また、MAVLink 2の署名機能は、命令の真正性を確認するためのものであり、通信内容を暗号化する機能ではないと明記しています。
これはArduPilotに今回のPHP脆弱性があるという話ではありません。機体と通信、操作端末、管理システムでは、それぞれ守る対象が違うという例です。
暗号化、認証、権限管理、ソフトウェア更新。どれか一つが備わっていることを、運用全体の安全性に読み替えてはいけません。
「国産」「国内クラウド」「ローカル運用」にも、更新は必要
国産機体を使う。データを国内に置く。外部クラウドに接続せず、施設内で運用する。それぞれに、調達やデータ管理上の意味があります。
ただし、開発元の国やサーバーの所在地が、ソフトウェアの脆弱性を消してくれるわけではありません。
ローカル運用も、外部から到達できる経路を減らす効果は期待できますが、保守用の接続、持ち込む端末、内部ネットワークまで含めて考える必要があります。
安全性の説明として聞きたいのは、所在地に加え、どのソフトウェアを使い、誰が脆弱性情報を確認し、いつ更新できるのかです。
CISAのドローン向けガイダンスも、機体だけでなく関連ソフトウェアを含めた保護と、脆弱性に対応する更新を挙げています。
導入先がメーカーや運用会社に聞きたいこと
今回のような情報が出たとき、利用者がすべての技術詳細を調べるのは現実的ではありません。だからこそ、提供会社から具体的な回答が得られることが重要です。
今回の脆弱性の影響を受ける構成があるか。
対象がある場合、修正の適用と確認はいつ完了するか。
データ管理側の侵害が、機体への操作権限に及ばない設計になっているか。
更新やサービス停止が必要な場合、飛行中の機体と現場業務をどう扱うか。
不正アクセスが疑われた場合、何を記録し、誰に連絡するか。
「対策済みです」という一言より、対象範囲と実施内容が分かる回答の方が役に立ちます。
なお、PHPをOSの配布元や保守ベンダー経由で導入している場合は、修正が既存パッケージへ取り込まれることもあります。見かけのバージョン番号だけで判断せず、提供元の修正情報を確認する必要があります。
飛行性能だけでは、事業を守れない
ドローンは空を飛ぶので、どうしても機体に目が向きます。耐風性、測位精度、障害物検知、通信距離。もちろん、どれも重要です。
しかし、点検画像を失えば、飛行に成功しても仕事は完了しません。報告書が改ざんされれば、機体が無事でも判断を誤るおそれがあります。管理システムが止まれば、飛ばせる機体が並んでいても運用は止まります。
PHPの重大脆弱性は、ドローンが危険だと示すニュースではありません。ドローン事業も、ウェブや業務システムのセキュリティから切り離されていないことを、改めて突きつけるニュースです。
機体を安全に飛ばすこと。その機体を使う仕事を、安全に続けられること。ドローンの導入が広がるほど、この二つを一緒に設計する必要があります。
※2026年10月21日23時台（日本時間）に確認した公開情報に基づきます。本稿は特定メーカーのドローンに今回の脆弱性が存在することや、実際の侵害を確認したものではありません。
図版は編集部がAIで制作した概念イラストであり、実際の被害や個別製品の構成を示すものではありません。
コメント