コドモン、PHP2Shell対策で日中のサービス停止を決断　子どもの情報保護を優先、自前ビルドで翌朝復旧

保育・教育施設向けICTサービス「コドモン」を運営する株式会社コドモンは2026年10月23日、PHPの重大脆弱性「PHP2Shell」（CVE-2026-109618／CVE-2026-109619）への対応を振り返る技術ブログを公開しました。同社は10月21日、修正版の公開を待つ間に攻撃を受ける危険性を考慮し、日中にもかかわらずサービスを予防的に停止。翌22日早朝には、主要機能の再開にこぎ着けています。

今回の停止は、すでにサイバー攻撃を受けたことによるものではありません。同社は10月23日の技術ブログで、本件に起因する不正アクセスや情報漏えいは確認されていないと説明しています。ブログでは、事前告知が十分でない状況で停止を判断した理由、経営陣を交えた意思決定、修正版の配布遅延に備えた自社でのPHPビルド、復旧後の課題まで明らかにしました。

コドモンのPHP2Shell対応のサマリー

• 10月21日、PHP本体の重大脆弱性「PHP2Shell」2件について、当初同日23時に修正版が公開される予定でした。
• コドモンは9時01分に社内で脆弱性を把握し、当初は夜間の修正適用を予定していました。
• 修正版の公開前に攻撃の手掛かりとなる情報が広まったため、12時37分、経営メンバーと協議して日中の緊急停止を決定しました。
• 13時ごろから順次停止し、14時49分に停止対象サービスの停止が完了しました。
• 保育施設の登降園記録、保護者との連絡、請求・支払いなどに影響し、現場では紙の記録などの代替運用が必要になりました。
• PHP修正版が配布元から直ちに届かない事態に備え、17時29分から自社で修正版のビルド環境を用意しました。
• 21日22時38分の修正版公開を受けて夜間に作業し、22日3時22分に職員用管理画面の主要機能や保護者向け連絡帳アプリを再開しました。
• 所在確認アラート機能は23日9時に再開。サービスごとに安全確認と再開の時刻を分けました。
• 同社は今回の対応について、迅速なリスク判断と事前の技術準備を評価する一方、利用者への案内や代替手段の準備には課題があったと説明しています。

修正版の公開前に攻撃リスクが上昇　夜間対応から日中停止へ方針変更

PHP2ShellはPHP本体に存在した重大脆弱性です。条件を満たす環境では、認証されていない外部の第三者がサーバー上でコードを実行するリモートコード実行（RCE）につながる可能性があります。コドモンの主要システム群ではPHPが使われており、子どもや保護者、施設の情報を扱う環境への侵入を防ぐ必要がありました。脆弱性の詳細や修正版については、セキュリティ対策LabのPHP2Shellの解説と修正版・国内サービスの対応状況でも整理しています。

コドモンが社内で脆弱性の情報を把握したのは、10月21日9時01分でした。当初は、23時に予定されていた修正版の公開に合わせ、利用者への案内をしたうえで夜間に停止・更新する計画を検討していました。11時37分には、公開が前倒しされた場合は直ちに停止するという条件付きの方針で経営メンバーと合意しています。

転機になったのは12時03分の情報共有です。SNSや開発者コミュニティで、脆弱性の原因や修正方法に関する情報が、正式公開前から広まり始めていました。コドモンは、出回っていた情報すべての正確性を確認できたわけではないとしながらも、23時以前に攻撃が成立する可能性を排除できないと判断しました。

設定変更による一時的なリスク軽減も検討しましたが、脆弱性の詳細が正式に公開されていない段階では、有効性を短時間で検証することが難しかったとしています。結果として、12時37分に経営メンバーと協議し、当初予定していた夜間の停止を前倒しする判断に至りました。

日中に止めるという判断　セキュリティを優先した経営陣の決断

今回の対応で特徴的なのは、障害や侵害の発生を待つのではなく、攻撃が実行可能になる危険性を重く見て、業務時間内の停止を選んだ点です。コドモンは保育園や幼稚園などの登降園記録、施設と保護者の連絡、請求を支えるサービスであり、日中の停止は利用施設と保護者に直接的な負担をもたらします。同社によると、自らの判断で日中に長時間停止したことは、それまでありませんでした。

緊急協議では「影響のある一部だけを止める」「夕方の降園時間まで稼働を続ける」「監視を強め、攻撃を検知してから止める」という選択肢も検討されました。しかし、システム間のつながりを考えると部分停止では被害の波及を防げる保証がなく、継続運転中に侵入される可能性も残ります。攻撃を検知した時点では、すでに情報への影響が生じているおそれがあることも考慮しました。

特に同サービスには、子どもの健康状態や家庭に関わる情報も含まれています。サービスの利用継続による利便性と、侵害された場合の情報への影響を比較し、後者の危険性を優先した判断でした。十分な根拠を持たない暫定対策や監視強化だけに依存せず、サービス停止という確実性の高い選択肢を採用したことは、被害が発生する前の予防措置として評価できます。

一方で、停止すればそれだけで適切なインシデント対応が完結するわけではありません。利用者に対する代替手段の提示、停止理由の説明、再開の見通しの共有も、安全確保と並行して行う必要があります。コドモン自身も、今回の緊急停止は必要な判断だったとしつつ、事前の案内が不足したことを反省点として挙げています。

復旧の鍵は、PHP修正版の配布を待つだけにしなかったこと

サービスを停止した後、別の問題が見えてきました。PHP開発元が修正版を公開しても、各システムで実際に利用するパッケージやコンテナイメージが、直ちに提供されるとは限らなかったのです。

コドモンはDocker公式PHPイメージ、packages.sury.org、Amazon Linux、Ubuntu 24.04 LTSなど複数の提供経路を利用していました。過去の更新状況を調べると、PHP本体の修正版公開から実際に利用できるパッケージが届くまでには、数時間から数日程度の差がありました。翌朝の登園時間までに再開するには、配布元を待ち続けるだけでは間に合わないおそれがありました。

そこで17時29分、修正版公開後に自社でPHPをビルドする代替策を並行して準備する方針を決定しました。19時台には主要システムについて自社ビルド版の動作確認が進みました。ただし、限られた時間で負荷試験などを十分に実施できたわけではなく、通常の配布元による更新を優先し、自社ビルド版は必要な場合に限る運用としました。

21日22時38分に修正版が公開された後も、配布元によっては更新版の入手に時間がかかりました。22日1時49分、コドモン本体は自社ビルド版で再開する方針を決定。一方、外部連携用サーバーの一部には配布元の修正版を適用しました。複数の方法を組み合わせ、3時22分に主要機能を再開しています。

夜間作業チームは13人。これとは別に事前準備チーム、早朝待機チームを設け、開発・運用側では計21人の体制で対応しました。22日6時からの利用ピークに備えてサーバー台数も増やし、通常よりアクセス数が多い状態でも、目立った性能劣化を起こさず運用できたと説明しています。

修正版公開、各ディストリビューションでの提供、適用、検証、サービス再開はそれぞれ別の工程です。パッチの配布時刻だけを基準に復旧計画を立てず、複数の調達・適用経路を確保していたことが、翌朝の主要機能再開につながりました。

保育施設・保護者への影響　主要機能は22日早朝に再開

一時停止中は登降園の打刻、施設と保護者との連絡、アンケート、支払いなどの一部業務をシステム上で実施できませんでした。施設側では紙による記録などに切り替える必要があり、保護者側でも連絡や情報確認ができない時間帯が生じました。サービスサイトとヘルプページは停止せず、案内を掲載する経路として残されました。

重要な登園関連機能を先に復旧させ、他のサービスや機能は安全性と作業状況を確認しながら段階的に再開しています。特に、登園予定時刻を過ぎても記録がない園児を検知する「所在確認アラート機能」は、主要機能よりも再開を遅らせました。再開時刻を一律にそろえず、機能ごとに判断した形です。

同社は、予防的な停止であることを利用者に十分説明できず、不正アクセスを受けたために停止したのではないかという不安の声も寄せられたと明かしています。メンテナンス画面の表示内容や、代替運用を停止前に整理できなかったことも、今後の改善点として挙げています。

企業の情報システム部門・経営層が参考にできる対応

今回の対応は、脆弱性の重大性だけで停止を決めた事例ではありません。自社環境の構成、公開済み情報の内容、修正版の提供状況、想定被害、サービス停止に伴う業務影響を短時間で照合し、経営層が判断した点に特徴があります。

修正版が未公開の重大脆弱性に直面した場合、企業の情報システム部門は、まず対象ランタイム・依存コンポーネントを利用するサービスを洗い出し、外部から到達できる経路と、保管する情報の種類を確認します。そのうえで、WAFなどの暫定策が自社環境で有効と判断できるか、機能制限やネットワーク遮断が可能か、停止する場合の代替業務と利用者通知を準備します。実際の停止判断は、リスクと業務継続性の双方を踏まえて行う必要があります。

また、復旧計画では「開発元が修正を公開する時刻」と「自社サーバーへ安全に適用できる時刻」を区別して管理します。利用中のOSパッケージ、コンテナイメージ、依存する外部システムごとに更新経路を記録し、更新が遅れる場合の代替手段と撤退条件を決めておくことで、緊急時の判断材料が増えます。

コドモンが公開した記録は、予防的な停止を迅速に決めたことだけでなく、その判断を支えた社内連携や、十分に準備できなかった点まで示しています。安全を優先してサービスを止める判断は、結果的に情報漏えいが発生しなかったかどうかだけで評価できません。判断時点で入手可能だった情報に照らして合理性があったか、利用者への影響をどのように抑えたかを検証することが、次の対応につながります。

なお、10月21日の停止については、コドモンのPHP脆弱性対応による緊急停止の初報でも報じています。本記事は10月23日の技術ブログで明らかになった、意思決定と復旧作業の詳細を扱っています。

出典

• PHP2Shellへの対応を振り返って（2026年10月23日）―コドモン Product Team Blog
• メンテナンス・障害情報、緊急メンテナンスおよび再開案内―株式会社コドモン