処方箋受付フォームが「裏口」になる日
――PHP重大脆弱性「php2shell」、薬局の死角はレセコンの外にある

Webの裏側で広く使われているプログラミング言語「PHP」に、外部から任意のコードを実行される恐れのある重大な脆弱性が2件見つかった。修正版は10月21日23時（日本時間）に公開される予定だが、詳細は修正前に流出し、悪用できると主張するコードも出回り始めている。薬局には無縁の話に聞こえるかもしれない。しかし、ホームページ、処方箋の事前受付フォーム、一般用医薬品の通販サイトの多くはPHPで動いている。レセコンや電子薬歴の外側にある「周縁システム」こそ、今回の最大の死角である。

添付文書改訂の時刻だけが予告された

事態を薬の世界に置き換えると分かりやすい。重大な副作用があるという噂だけが先に流れ、添付文書の改訂版がいつ出るかの時刻だけが予告されている。そのような状態だ。

PHPの開発チームは10月20日（協定世界時）、深刻度を示すCVSS 4.0の基本値がいずれも9.2（緊急）となる脆弱性2件を修正するセキュリティリリースを予告した。詳細、影響を受けるバージョン、修正版は公開と同時に示すとしており、情報が公になったり悪用が確認されたりした場合は前倒しもあり得るという。

公式発表はここまでだ。以下は、セキュリティ企業や公的機関の見立てである点に注意したい。脆弱性は研究者の間で「php2shell」と呼ばれ、メモリ破壊系の不具合を突いて外部からサーバー上で任意のコードを実行（RCE）できるものとみられている。欧州連合のCERT-EUなどは、PHP 5以降の幅広いバージョンが影響を受け得るとしている。研究者の投稿では、Apacheのmod_phpやPHP-FPMといった一般的な動作方式、WordPress、Laravel、Symfonyといった代表的なオープンソースソフトウェアの上で攻撃が再現したという。

厄介なのは、本来は修正まで伏せられるはずだった情報が先に漏れたことだ。海外のセキュリティ企業Sansecは、修正版の公開から短時間のうちに大規模な攻撃が始まる可能性を指摘している。修正版の公開は、防御側にとっての「治療開始」であると同時に、攻撃側にとっての「号砲」でもある。修正内容を解析すれば、攻撃の手がかりが得られるからだ。なお、GMO Flatt Securityは当初、PHPの設定変更（Session Upload Progress機能の無効化）を緩和策として挙げていたが、その後の調査で、それだけでは攻撃を防げない見込みだと修正した。対症療法では根治しない。根治療法は修正版の適用しかない、というのが現時点の結論である。

薬局のどこにPHPがあるのか

「うちのレセコンはPHPではない」という反応は、おそらく正しい。問題はそこではない。薬局がこの数年で増やしてきた外部との接点を思い浮かべてほしい。

特に注目したいのが処方箋受付フォームだ。研究者の間では、今回の攻撃がファイルを送信する仕組み（アップロード処理）に関わる経路を使う可能性が指摘されている。現時点では仮説の段階だが、処方箋画像を受け付けるフォームは、まさにその仕組みの上に成り立っている。患者の利便性のために開けた窓口が、攻撃者にとっての裏口になりかねない。

しかも、そのサーバーには処方箋画像そのものが残っていることがある。処方箋には氏名、生年月日、処方内容、医療機関名が記載されている。病歴に直結する情報であり、個人情報保護法上の要配慮個人情報に当たる。サーバーが乗っ取られれば、保存された画像の流出はもちろん、通知メールの送信に使うアカウント情報や、外部サービスと連携するための認証キーなどを足がかりに、被害が別のシステムへ広がる恐れもある。

「医療情報システムではない」は通用するか

ここで、薬局の管理責任の線引きを確認しておきたい。

2023年4月施行の改正薬機法施行規則により、薬局の管理者が遵守すべき事項として、サイバーセキュリティの確保に必要な措置を講じることが加わった。厚生労働省の「医療機関・薬局におけるサイバーセキュリティ対策チェックリスト」（令和8年度版）は、薬機法に基づく立入検査で確認される。チェックリストには、サーバー、端末、ネットワーク機器の台帳管理、セキュリティパッチの適用、アクセスログの管理、インシデント発生時の連絡体制図、サイバー攻撃を想定したBCPなどが並び、令和8年度中にすべての項目を「はい」にすることが求められている。厚労省は2026年7月、薬局のランサムウェア被害リスクを把握するための調査もG-MISで始めた。

チェックリストが主に想定しているのは、レセコンや電子薬歴といった「医療情報システム」である。では、処方箋画像を受け付けるホームページのフォームは対象外だろうか。筆者は、医療情報を受け取り、保存している以上、境界の内側にあると考えるのが自然だとみる。少なくとも、漏えいが起きた際に「あれはホームページだから」という説明が患者や行政に通じるとは考えにくい。

もう1つ、見落とされやすい点がある。チェックリストのマニュアルは、製品を購入しただけで運用や保守の契約がない場合、そのシステムのセキュリティアップデートの責任は医療機関等が負うと明記している。開業時に制作会社にホームページを作ってもらい、その後は保守契約なしでレンタルサーバーに置いたまま、という薬局は少なくない。この場合、PHPを更新する責任は、制作会社でもレンタルサーバー事業者でもなく、薬局自身にある可能性が高い。

サポートが終わった版は「経過措置の切れた薬」

修正版が公開されても、すべての薬局が救われるわけではない。開発元のサポートが終了した古いバージョンには、原則として修正版が提供されない。経過措置の切れた薬を使い続けているようなもので、副作用の情報が出ても改訂は届かない。

レンタルサーバーでは、管理画面でPHPのバージョンを選べることが多い。数年前に設定したまま、古いバージョンで動いているサイトは珍しくない。古いバージョンで動くテーマやプラグインに合わせて、あえて据え置いているケースもある。今回を機に、自店のサイトがどのバージョンで動いているかを確認し、サポート対象外であれば移行の計画を立てる必要がある。

一方で、冷静さも欠かせない。現時点で、実際の攻撃による被害は公的機関などから報告されていない。また、影響範囲に関する情報の多くは非公式な見立てであり、公式発表で変わる可能性がある。根拠の薄い情報に振り回され、患者向けの案内まで含めてすべてを止めるのは得策ではない。ホームページを一時停止すれば、営業時間や休日の案内が患者に届かなくなる。停止する場合は、Googleビジネスプロフィールや店頭掲示など、代わりの告知手段を同時に用意したい。止めるか、更新して動かし続けるか。この判断を、リスクと患者への影響を比べて下せる体制があるかどうかが問われている。

守るべき「城」の範囲を描き直す

オンライン服薬指導、処方箋の事前送信、LINEなどを使った受付、通販。薬局DXは患者の利便性を大きく高めた。同時に、攻撃者が狙える入口は、薬局の奥にあるレセコンから、インターネットに面した周縁へと広がった。城門をいくら固めても、勝手口が開いていれば意味がない。

php2shellは、特定の不具合への対応を迫るだけでなく、薬局が「守るべきシステム」の範囲をどこまで把握しているかを試している。台帳に載っていない仕組みは、更新されることも、監視されることもない。今回の対応を、周縁システムを含めた台帳を作り直す機会にしたい。