PHP脆弱性「PHP2Shell」から考える、中小企業の業務システムの守り方|ノーコードという選択肢
2026年10月下旬、PHPに「PHP2Shell」と呼ばれる深刻な脆弱性が見つかり、国内でも多くのWebサービスが一時停止する事態になりました。
皆様の会社のサイトやシステムは問題なかったでしょうか。
こうした脆弱性は今回限りの話ではありません。
この記事では、次に同じことが起きたときに慌てずに済むよう、中小企業が業務システムをどう持っておくといいのかを考えていきます。
2026年10月のPHP脆弱性で何が起きたか
脆弱性「PHP2Shell」の概要
PHPは、Webサイトや業務システムを動かすために世界中で使われているプログラミング言語です。
2026年10月21日、このPHPそのものに見つかった深刻な脆弱性2件について開発元から修正版が公開されました。
この2件を組み合わせた攻撃は「PHP2Shell」と呼ばれています。
本脆弱性が悪用された場合、PHPの実行プロセスの権限で任意のコードを実行される可能性があります。
出典:JPCERT/CC「PHPにおける複数の脆弱性(CVE-2026-109618、CVE-2026-109619)に関する注意喚起」
噛み砕いて言えば、外部の人間がサーバー上で勝手にプログラムを動かせてしまう可能性があったのです。
しかもログインせずに攻撃できるとされ、深刻度も10点中9.2(CVSS v4.0)と最上位の「緊急」に分類されています。
国内でもサービス停止が相次いだ影響
開発元が修正版の公開時刻を前日に予告していたため、国内でも多くのサービスが公開の前後に一時停止しました。
ネットショップの作成サービスや動画・イラスト投稿サイト、保育施設向けのサービス、スマートフォン向けゲーム、レンタルサーバーの一部サービス、一部の自治体サイトなど、業種を問わず止まっています(参考:Impress Watch「国内大手サービスで緊急メンテやサービス停止 PHP脆弱性で対策」)。
それだけPHPは広く使われています。
セキュリティの専門機関であるIPAやJPCERT/CCも、相次いで注意喚起を出しました。
これらの停止の多くは攻撃を受けたからではなく、受ける前に手を打つための措置です。
IPAは10月27日時点で国内の被害事例を把握していないとしています。
ただ、海外のセキュリティ企業は公開当日から悪用を観測しており、米国の政府機関も「実際に悪用が確認された脆弱性」として登録しています。
すぐ再開できたサービスもあれば、報道によると10月27日時点でまだ再開できていないサイトも少なくありません。
古いバージョンほど対応が難しい理由
今回の修正版が出たのは、サポートが続いているPHP 8.2〜8.5だけです。
いずれも同じ系統の中の小さな更新なので、サポート中のバージョンを使っていれば修正版を適用して動作を確かめれば再開できます。
一方で、IPAの注意喚起で紹介されているセキュリティ企業の見解によると、影響はPHP 5.4以降の幅広いバージョンに及びます。
PHP 8.1以前はすでにサポートが終わっていて、正式な修正版はありません。
開発元は7.4〜8.1向けに最小限の修正をソースコードの形で公開していますが、正式な修正版ではなく、適用には自分でビルドするかOSやレンタルサーバーなどの配布元が提供するのを待つ必要があります。
7.3以前には修正そのものがありません。
つまり古いバージョンのままだと今回の対応は修正の適用ではなく、バージョンアップになります。
PHPは、バージョンを上げるとそれまでの書き方では動かなくなることが多い言語です。
プログラムを書き換え、動作を確かめ直すまで再開できません。
IPAも、サポートが終わったバージョンを使っている場合は、サポート中のPHPへの更新か対策済みの製品・サービスへの移行を検討するよう呼びかけています。
作ったまま何年も更新していないシステムほど、こういうときに打てる手が限られてしまうわけです。
自社でサーバーを保守することの負担
今回の件で特に慌ただしかったのは、自社でサーバーを管理している会社だったと思います。
脆弱性が出るたびに必要になる対応
自社でサーバーを管理している場合、脆弱性が公表されたら次のような対応をすべて自分たちで進めることになります。
- どんな脆弱性で、どのバージョンが対象なのかをIPAや開発元の発表から確かめる
- 自社のサーバーで動いているPHPのバージョンを調べ、どのサイトやシステムが該当するのかを洗い出す
- 修正版を適用し、サイトやシステムが今までどおり動くかを確かめる
- すぐに更新できない場合は、サービスを一時停止するかどうかを判断する
しかも、更新したら終わりではありません。
JPCERT/CCは今回、次のように呼びかけています。
本脆弱性の影響を受ける製品を利用している場合は、開発者が提供する情報などを参考に、速やかに対策の適用および侵害有無の調査を実施してください。
出典:JPCERT/CC「PHPにおける複数の脆弱性(CVE-2026-109618、CVE-2026-109619)に関する注意喚起」
つまり、更新が済むまでのあいだに攻撃を受けていなかったか、ログなどをさかのぼって調べる必要があります。
攻撃の痕跡が見つからなかったとしても攻撃を受けていないとは言い切れない、とも説明しています。
さらに、今回修正版が出たPHP 8.2もセキュリティサポートは2026年12月31日で終わります。
8.2を使っていて今回の修正で乗り切ったシステムも、2か月後にはバージョンアップを考えなければなりません。
専任の担当者がいない会社にとって、これを通常の業務と並行して進めるのはかなりの負担です。
Webサイトの保守はシステム会社に任せるのが基本
こうした対応を毎回自社だけでこなすのは現実的ではありません。
Webサイトやサーバーの保守は、専門の会社に任せるのが基本です。
先ほど挙げたサービスの多くは専門の会社が運営しているものですが、それでも一時停止しています。
ただ、利用者の側で修正版を適用する必要はなく、脆弱性の公表に気づいて停止を判断し、修正を適用して動作を確かめたうえで再開するところまで運営会社が行っています。
任せておけば止まらないというわけではありませんが、止まったときに対応してくれる人がいることに任せる意味があります。
一方で、自分たちで作ってそのまま置いてあるシステムの場合は、脆弱性が出たことに誰も気づかなかったり、気づいても直せる人がいなかったりすることがあります。
もっとも、任せた先が保守を続けているとは限りません。
IPAも、長く更新されていないシステムは、担当者の不在や保守契約の終了などで対策が難しくなっている場合があると指摘しています。
大事なのは作って終わりではなく、公開後の保守まで理解して対応してくれる会社を選ぶことです。
どの会社に頼むにしても今回の件で何をしてくれたのか、保守の契約にどこまで含まれているのかを一度確認しておいてください。
業務システムこそ、ちゃんとした管理が必要
ここまではWebサイトを中心に見てきましたが、同じことは社内で使う業務システムにも当てはまります。
むしろ、扱う情報の重さを考えると業務システムのほうがより慎重な管理が必要です。
顧客情報・社内情報を扱うシステムのリスク
会社のWebサイトに載っているのは、もともと外に向けて公開している情報が中心です。
一方で、業務システムには顧客の名前や連絡先、取引の履歴、見積もりや売上の数字、社員の情報など、外に出てはいけない情報が集まっています。
こうしたシステムが攻撃を受けて情報が漏れてしまうと、影響はWebサイトの比ではありません。
取引先やお客様への連絡、原因の調査に加え、場合によっては個人情報保護委員会への報告も必要になります。
AIで自作できる時代だからこそ考えたい保守の問題
最近は生成AIを使えば、プログラミングの経験が少なくても社内向けのちょっとしたシステムを作れるようになりました。
必要なものをすぐに形にできるのは、人手の限られた中小企業にとって助けになります。
ただ、作れても守り続けられるかは別です。
システムは使い続けるかぎり、今回のような脆弱性への対応がついて回ります。
使っている技術に問題が見つかったときには、それに気づき、影響を調べ、直して、攻撃を受けていないか確かめる必要があり、AIで作ったシステムでもこうした対応は自社で行うことになります。
また、作った当時は新しいバージョンでも、更新を続けなければ数年でサポートが切れます。
そうなると今回のように修正を適用するだけでは済まず、プログラムの書き換えが必要になります。
その書き換えを誰が担うのかも、決めておかなければなりません。
さらに、作った人が異動や退職でいなくなると、中身を分かる人が社内に残らないこともあります。
作る前に、そこまで続けられるかどうかを考えておくことが大切です。
中小企業の現実解は、使うシステムを減らすこと
とはいえ、中小企業が大企業と同じように、専任の担当者を置いてシステムを管理するのは簡単ではありません。
限られた人数でも無理なく守るために、まず考えたいのが「使うシステムの数を減らす」ことです。
システムが増えるほどリスクと手間も増える
顧客管理、案件管理、日報と業務ごとに別々のツールを入れていくと、気づけば社内のシステムがいくつにも増えていることがあります。
ひとつひとつは便利でも、システムが増えればその分見ておくことも増えます。
それぞれに脆弱性の情報が出ていないか、更新が必要ではないか、どこにどんなデータが入っているのかをシステムごとに把握しておかなければなりません。
今回のような事態が起きたとき、すべてのシステムについて影響を調べるだけでも手間がかかります。
専任の担当者がいれば対応できるかもしれませんが、ほかの業務と兼務しながらシステムを見ている中小企業では、ここまで手が回らないのが正直なところだと思います。
1つの基盤で複数の業務を管理するという考え方
そこで理想になるのが、複数の業務を1つの仕組みの上でまとめて管理する形です。
顧客管理も案件管理も日報も同じ基盤で扱えれば、見る相手は1つで済みます。
データも1か所にまとまるので、どこに何があるのか分からないという状態も防げます。
ただ、業務に合わせたシステムを一から開発すると費用も時間もかかります。
プログラミングをせずに業務アプリを作れる「ノーコード」のプラットフォームなら、そこを省けます。
ノーコードプラットフォームという選択肢
ノーコードは、中小企業が業務システムを持つうえで有力な選択肢です。
ただし、どのツールでも同じというわけではありません。
ノーコードでできること
ノーコードプラットフォームを使うと、プログラミングをしなくても画面上の操作で業務に合わせたアプリを作れます。
顧客管理や案件管理、日報、在庫管理など、これまで別々のツールやExcelで管理していた業務を、1つの基盤の上にまとめていけます。
業務のやり方が変わったときも項目や画面を自社で手直しできるので、そのたびに開発会社へ依頼する必要がありません。
また、サーバーやプログラムの保守はサービスの提供元が担うため、今回のような脆弱性への対応を自社で抱え込まずに済みます。
プラグイン前提のツールで注意したい点
一方で、ノーコードツールの中には、標準の機能だけでは足りない部分を「プラグイン」と呼ばれる追加機能で補う仕組みのものが少なくありません。
必要な機能を後から足せるのは便利ですが、注意したい点もあります。
プラグインは、ツール本体とは別の会社や個人が提供していることも多く、本体と同じ基準で安全性が保たれているとは限りません。
提供元によって、脆弱性が見つかったときの対応の早さや更新が続くかどうかが異なる場合があります。
プラグインを増やすほど見る相手も増えていきます。
ノーコードツールを選ぶときは標準の機能でどこまでできるのか、追加機能の安全性を誰が担保しているのかも確認しておくと安心です。
プラグイン不要で完結する「サスケWorks」
ここからは、当社が提供しているノーコードプラットフォーム「サスケWorks」を紹介させてください。
これまで見てきた「確認すべきものを増やさない」という考え方を形にしたサービスです。
すべて標準機能で業務アプリを作れる
サスケWorksには、プラグインという仕組みがありません。
入力フォームや検索、承認フロー、帳票の出力、グラフ表示など、顧客管理や案件管理に必要な機能は最初から標準機能として揃っています。
業務アプリを作るために、ほかの会社が提供する追加機能を探して組み合わせる必要はありません。
サーバーやシステムの管理も提供元である当社が行っています。
サスケWorksも一部の機能でPHPを使っていますが、修正版の公開後すぐに対応を完了しています。
利用する側から見れば、確認すべき相手は1か所だけです。
脆弱性のニュースが出たときも、いくつもの提供元の情報を調べて回る必要はありません。
なお、アプリストアにはほかの会社が作ったアプリもあります。
作った会社が書いたカスタムコードを含む場合もあるため、公開前には当社が内容を審査しています。
拡張はJavaScriptのカスタムコードで対応
標準機能では届かない細かい部分は、「カスタムコード」機能で補えます(Businessプラン以上)。
JavaScriptやCSSを書くことで画面の見た目を変えたり、独自の処理を加えたりできます。
外部のプラグインを入れるのではなく、利用する会社が自分でコードを書いて調整する仕組みなので調べる先が増えることはありません。
ただし、書いたコードは自社で管理することになるので、使うのは標準機能で足りない部分にとどめておくのがおすすめです。
二段階認証などのセキュリティ機能
業務システムには大事な情報が集まるので、ログインまわりの守りも欠かせません。
サスケWorksには、次のようなセキュリティ機能があります。
- 二段階認証:パスワードに加えてワンタイムパスワードで本人確認を行い、不正ログインのリスクを減らします
- IP制限・国の制限:社内のネットワークなど、決められた場所からしかアクセスできないように設定できます
- SSO(シングルサインオン):社内で使っている共通のIDで、安全にログインできます
- 権限設定:アプリやデータごとに、誰が見られるか、誰が操作できるかを細かく決められます
業務をひとつにまとめたいけれど、管理の手間やセキュリティが心配で踏み出せないという会社に向いています。
30日間の無料トライアルもあり、トライアル中はクレジットカードの登録も不要です。
まずは実際に触って、自社の業務に合うかどうかを確かめてみてください。
守り続けられる形でシステムを持つ
今回のPHPの脆弱性では、国内でも多くのサービスが一時停止し、自社で管理しているシステムほど対応に追われました。
次に同じことが起きたときのために考えておきたいのは、作れるかどうかより守り続けられるかどうかで選ぶこと、使うシステムの数をできるだけ減らすこと、そしてプラグインに頼らず標準機能でまかなえる基盤を選ぶことの3つです。
脆弱性はなくなりませんが、振り回されない持ち方はあります。
この記事が、自社のシステムを見直すきっかけになればうれしいです。
今回の件で自社のシステム管理に不安を感じた方や、ノーコードで業務システムをまとめてみたいと考えている方は、お気軽にサスケWorksへご相談ください。
今のツールから移せるかどうか、という相談からで構いません。
著者情報

-
ノーコードWEBアプリ作成ツール「サスケWorks」のオウンドメディアです。
ノーコード技術やアプリ開発に関する情報や初心者向けの使い方、活用事例など、皆さまの業務効率化に役立つ情報をお届けしています。
ノーコードでのアプリ作成に興味がある方や業務改善を目指している方に向けて、実践的なノウハウをわかりやすくご紹介していきます。
最新の投稿
アプリ・ツール選び2026年11月4日PHP脆弱性「PHP2Shell」から考える、中小企業の業務システムの守り方|ノーコードという選択肢
アプリ・ツール選び2026年10月29日ガントチャートの作り方からツールの選び方まで解説
アプリ・ツール選び2026年9月25日発注管理アプリとは?Excelからの移行とノーコードで自作する手順を解説
業務改善2026年9月25日法務DXとは?進め方4ステップとツールの選び方
