攻撃者がLinux向けWebホスティングサーバー用セキュリティスイート「cPGuard」のアップデート基盤を侵害し、約3,000台の顧客サーバーに悪意あるアップデートを配信しました。
このセキュリティスイートを提供するOPSShieldは、攻撃者が同社の課金・ライセンスサーバーから、顧客の連絡先情報とハッシュ化されたパスワードを盗み出したことも認めました。
攻撃の経緯
攻撃者は2026年11月2日のUTC 02:04から02:09にかけて、偽のcPGuardアップデート（バージョン5.88.12〜5.88.19）をOPSShieldのアップデート用ストレージにアップロードしました。
その後70分以上にわたり、cPGuardのエージェントが約2,950台の顧客サーバーに偽のアップデートをインストールし、root権限で実行しました。
偽のアップデートは短いスクリプトで、機密性の高いファイルを収集し、攻撃者の管理下にあるサーバーへ送信するものでした。OPSShieldはこのインシデントに関する初期報告で、送信先がOPSSHIELD自身のライセンスサーバーだったと説明しています。盗まれた情報は侵害されたアカウントの配下に保存され、攻撃者が後で回収できる状態でした。
収集・送信されたデータには、パスワードハッシュ、rootのSSH鍵、MySQLのrootパスワード（存在する場合）、rootのシェル履歴（入力したパスワードやトークンが含まれている可能性があります）、クラウドストレージの鍵が含まれます。
同社は「[このスクリプトは]2つの痕跡も残しました。/var/tmp/.cpg91511_shに置かれた隠しrootシェルと、/var/tmp/.i93677/配下のファイルです」と付け加えています。
OPSShieldの報告によると、攻撃者はアップデート基盤を侵害する前日に、同社の課金ポータルを調査していました。偽の身元で顧客アカウントを登録し、cPGuardの無料トライアルを注文してインストールすることで、エージェントがライセンスシステムとどのように通信するかを調べていたとのことです。
1時間半後、攻撃者は課金ポータルのコールバックページに細工したリクエストを送信しました。その数分後には、課金・ライセンスサーバー上でコマンドを実行できる状態になり、顧客アカウントの記録収集を開始しています。対象は約7,900人の顧客の氏名、会社名、住所、メールアドレス、bcryptでハッシュ化されたパスワードです。
OPSShieldは次のように指摘しています。「この種の攻撃は、実行が急速に速く、安価になっています。攻撃者はAIツールを使って弱点をスキャンし、見慣れないコードを読み解き、独自のツールを数週間ではなく数時間で作成します。最初の探りから偽アップデートの配信まで約10時間という今回の攻撃の速さが、それを物語っています」
攻撃者は、同社のクラウドサーバー3台のコピーも作成していました。
OPSShieldのこれまでの対応
OPSShieldは、攻撃者が偽のcPGuardアップデートをアップロードするために使ったアクセス／アップデート用の鍵を、どのように入手したのかをまだ特定できていません。課金・ライセンスサーバー上でコマンドを実行された経緯も不明です。
同社は「ログには、侵入のきっかけとなった正確なリクエストが記録されていません。そのため該当コードを精査し、見つかった2つの侵入経路の可能性を修正したうえで、関連するベンダー製コンポーネントを1行ずつ検証しています。SSH、コントロールパネル、FTP、APIトークンなどは原因から除外しました」と説明しています。
調査は現在も続いています。同社は当面の措置として、攻撃者が到達したと把握しているすべてのシステムへのアクセスを遮断しました。
盗まれたアップデート用ストレージの鍵と、すべてのクラウドAPIトークンおよびアクセスキーを失効させました。さらに、攻撃者のSSH鍵、複製されたサーバー、スナップショットをクラウドアカウントから削除し、ログイン保護も強化しています。
顧客向けには、悪意あるアップデートが仕込んだ隠しrootシェルを削除するクリーンなアップデート（v5.88.26）を公開しました。続くアップデートでは、i93677のスケジュールタスクも削除されます。
OPSShieldは、自社サーバー全体のSSH鍵とパスワードをすべて入れ替え、課金ポータルのセッションをすべてリセットし、課金システムとリセラーのAPIキーもローテーションしました。攻撃者が保持するコピーを無効にするため、cPGuardのライセンス鍵ペアもすべて再発行しています。
最後に、課金、ライセンス、社内管理の各サーバーを、クリーンなイメージから再構築しています。PHPとWebファイアウォールの設定を厳格化し、全リクエストのログも取得します。
顧客が取るべき対応
まず、自社サーバーに悪意あるバージョンのcPGuardがインストールされていないかを確認する必要があります。インストールされていた場合は、次の対応が必要です。
- バージョン5.88.26以降に更新し、悪意あるスケジュールタスクと隠しrootシェルが削除されたことを確認する。あわせて、見覚えのないユーザー、SSH鍵、サービス、外部への通信など、不正な変更の兆候がほかにないかサーバーを調べる
- 信頼できる復旧環境から、rootとパスワードが有効なその他のローカルLinuxアカウントのパスワードをリセットする
- 影響を受けたデータベースのパスワード、S3アクセスキー、DigitalOceanトークン、rootのシェル履歴に記録されたパスワード・APIキー・トークン、/root/.s3cfg内の鍵をローテーションする
- /root/.ssh配下に保存されたSSH秘密鍵を入れ替え、その公開鍵を信頼しているすべてのシステムから古い公開鍵を削除する
- 念のため、OPSSHIELDの課金ポータルのパスワードをリセットし、二要素認証を有効にする
cPGuardは一定間隔でアップデートを確認するため、すべての顧客サーバーが偽のアップデートを受け取ったわけではありません。OPSShieldは「その時間帯にcPGuardがオンラインでなかった場合、サーバーは偽のアップデートを受け取っていません」と述べています。
攻撃者が手動でサーバーにログインしたことを確認し、直接連絡した顧客に対しては、11月1日より前に取得したクリーンなバックアップからサーバーを再構築するよう推奨しています。
OPSShieldは、自社サーバーで見つかったものを含む侵害指標（IoC）の一覧を公開しており、顧客の復旧作業の支援も申し出ています。
翻訳元: https://www.helpnetsecurity.com/2026/11/04/cpguard-update-supply-chain-compromised/
