cPGuardの更新経路が侵害され約2950台で偽更新が実行｜最新版と認証情報の交換を

OPSSHIELDは2026年11月3日、Webホスティング向けのセキュリティ製品cPGuardの更新配布経路が侵害され、顧客サーバーで偽の更新が実行されたと公表した。OPSSHIELDの11月3日付事件報告では、偽更新を実行した顧客サーバーを約2,950台と説明している。運用者は最新版へ更新したうえで、対象時間帯に稼働していたサーバーの認証情報を交換する。更新で既知のバックドアを除去しても、持ち出された秘密情報は失効しない。

更新を配った側で何が起きたか

同社の調査では、攻撃者は自ら登録した顧客アカウントを使い、請求・ライセンス管理アプリを経由してコマンド実行に至った。その後、奪ったアクセスキーで更新用ストレージに偽更新を置いた。侵入を成立させた正確なリクエストはログに残っておらず、同社は可能性のある入口を修正して調査を続けている。顧客が不審なファイルを手動で入れた事案ではなく、通常の更新経路で配られた点が重要だ。

同社が顧客サーバーへの偽更新の導入時間帯として示したのは、11月2日11時08分から12時20分まで（日本時間）だ。偽更新はroot権限で実行され、ローカルアカウントのパスワードハッシュ、rootのSSH関連ファイルやシェル履歴、存在する場合はデータベース設定を収集した。一部ではクラウドストレージのキーも対象になった。同社は顧客側に残った痕跡として、隠されたrootシェルと定期実行の設定を挙げている。公式報告に掲載された同社内部サーバーの痕跡には、顧客サーバーで確認したものと区別すべき項目がある。

最新版と過去の導入履歴を別々に確認する

OPSSHIELDの初報と更新履歴の確認手順によると、影響を受ける更新は5.88.12から5.88.19まで。/opt/cpguard/logs/install_log の更新成功記録をサーバー単位で確認する。該当する版が記録されていれば影響版を導入した証拠になるが、その記録だけでは個々のファイルの取得や転送までは分からない。ログが欠けている場合や、該当行が見つからない場合も、その結果だけで対象外と判断しない。対象時間帯にオンラインだったかを監視記録などと照合し、判定できなければ提供元に確認する。

初報は5.88.25以降を案内したが、詳報では既知の隠しシェルを取り除くクリーンな5.88.26と、定期実行の設定を取り除く後続更新に触れ、最新版への更新を求めている。更新後は cpgcli --version で稼働ホストごとに導入版を確認する。続けて、同社が示す /etc/cron.d/i93677、/var/tmp/.i93677/、/var/tmp/.cpg91511_sh が残っていないことを確認する。痕跡が消えていることは、更新前に実行されなかった証明にはならない。調査が必要な環境では、残存物を処理する前に時刻やログなどを保全し、社内の初動担当へ渡す。

サーバーから使えた認証情報を失効させる

同社は対象時間帯にcPGuardがオンラインだったサーバーについて、root権限で参照できた秘密情報が知られた前提での対応を求めている。信頼できる端末や復旧環境からrootとローカルユーザーのパスワードを変更し、SSH鍵は新しい鍵へ切り替える。旧公開鍵を接続先の許可一覧から外し、身に覚えのない鍵が登録されていないかも確認する。SSHで接続していたバックアップ先や別の管理サーバーがあれば、交換先の一覧に含める。

データベースの管理パスワードや、rootの設定・履歴に保存されていたAPIキーやトークンも対象になる。新しい値を発行しただけでは旧値が引き続き使える場合があるため、利用先での切り替えと旧値の失効をそれぞれ確認する。これは運用上の提案であり、すべてのサーバーから同じ秘密情報が盗まれたという意味ではない。手動でログインされたと同社から通知された場合、同社は11月1日より前のクリーンなバックアップからの再構築を案内している。

請求ポータルはサーバーとは別に対応する

OPSSHIELDは、請求ポータルでも約7,900アカウントの氏名・会社名・郵便住所・メールアドレス・パスワードハッシュが流出したと説明している。ハッシュはbcryptで保存されていた。同社は、対象時間帯にcPGuardがオンラインでなかった場合も、請求ポータルのパスワードをリセットし、二要素認証を有効にするよう案内している。サーバーの対応状況とポータルの対応状況を分けて記録すれば、片方の完了を理由にもう片方を見落とさずに済む。