PHP脆弱性でいち早くサービス停止、コドモン経営判断の舞台裏　実はオンラインイベントの真っ最中だった（1/4 ページ）

公開 2026年10月30日 12時00分

[ITmedia]

印刷する Googleで優先するソースとして追加

　多くの情報セキュリティ担当者が対応に追われ、今なお爪痕が残るプログラミング言語「PHP」の脆弱性。さまざまなサービスが緊急メンテナンスを実施し、セキュリティアップデートを実施するに至ったが、その中でもいち早くサービス停止を判断し、注目を浴びた企業がある。保育施設や保護者向けSaaSを手掛けるコドモンだ。

　同社は10月21日の午後2時過ぎ、他社に先駆け予防的なサービス停止を告知。保護者アプリを含む全サービスを順次停止した。実は当時、同社は保育関係者向けのオンラインイベントを開催している真っ最中でもあり、停止の判断は生半可なものではなかったという。果たして当時の心境は如何に。小池義則代表取締役に話を聞いた。

小池義則代表取締役

夜間停止のはずが一転……正午すぎに「日中停止」へ

　まず、コドモンがPHPの脆弱性にどのように対応したか、同社がテックブログに掲載しているタイムラインを基に、おおまかな流れを整理しておこう。

大まかなタイムライン（テックブログから引用）

　PHPの開発チームは10月21日午前4時33分（日本時間）、重大な脆弱性2件の存在と、同日午後11時に修正版を公開する予定を発表した。通称「PHP2Shell」と呼ばれるこの脆弱性の深刻度は10点満点中9.2で、最も重い「Critical」（緊急）に分類されていた。

　コドモンが社内で把握したのは午前9時1分。当初は修正版の公開を待ってPHPを更新する方針だったが、公開前から脆弱性に関する情報が海外の掲示板などで広まっていたことから、午前11時37分には「修正版の公開に合わせ、事前に告知したうえで、公式サイトとヘルプページなどを除くほぼ全サービスを夜間に止める」方針が固まった。

　状況が変わったのは正午すぎだ。原因箇所と修正方法とされる情報がSNSやエンジニアコミュニティーで広まり、修正版の公開を待たずに攻撃が成り立つリスクが出てきた。設定変更などで影響を抑える方法も検討したが、非公式に出回る対策が自社の環境で有効かを短時間で確かめるのは難しかった。

　そこで午後0時37分、日中の緊急停止を決定。一部のサービスだけを止める、お迎えの時間まで動かし続ける、監視を強めて攻撃を検知した時点で止める──といった案も検討したが、いずれも十分にリスクを下げられないとして採らなかったという。

　サービスは午後1時ごろから順次停止し、保護者向けサービスは午後1時46分、保育施設などの職員用管理画面は午後2時2分に止まった。最後のサービスが止まったのは午後2時49分。並行して午後2時ごろに、状況を公表する第1報を出した。

　午後3時ごろには第2報を出し、復旧見込みを「未定」から「翌朝」に改めた。見通しのない状態が続けば利用者の不安が大きくなるとの考えからだ。具体的な目標は、施設での利用がピークを迎える午前7時より前、遅くとも午前6時の再開。当初は2時間ほどで作業を終えられると見込んでいた。

　ところが、夕方になって計画の前提が揺らぐ。修正版が公開されても、各システムが利用する配布元からパッケージ（実行可能なファイル）が届くまでには、過去の例で数時間から数日の開きがあった。5時間以上かかれば翌朝の再開には間に合わない。

　そこで同社は午後5時半ごろから、配布元を待つだけでなく、必要な情報が公開され次第、自分たちで完成品を組み立てる“自前ビルド”も並行して準備することにした。当初の計画にはなかった取り組みだが「待つだけになるのは避けたい」と考えた一部のエンジニアが自ら調べ始めたのがきっかけだったという。

　夜間の作業は13人が担当した。午後10時38分に修正版と脆弱性の詳細が公開されたものの、やはり配布元のパッケージが届くまでには時間差があった。同社は主要サービスを自前ビルドで、外部連携用のサーバは配布元のパッケージで動かすことにし、22日午前3時22分、職員用管理画面などを再開。目標とした午前6時の約2時間半前で、脆弱性の把握からはおよそ18時間後のことだった。

　その後、朝の利用ピークも大きな問題なく乗り切り、一部の機能を除く他のサービスも22日中に順次再開。同社によれば、本件に起因する不正アクセスや情報漏えいは確認していないという。その他、プロダクト開発部門から見た当時の状況は同社のテックブログも参照のこと。

次ページへいち早くサービス停止を決意、当時の心境は