UPSIDERが不正アクセス被害の最終報告を公開-開発者端末侵害から認証情報が漏えい|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年06月15日更新日時: 2026年06月15日

累計10万社以上（2025年11月時点）が導入する法人カードサービス「UPSIDER」「PRESIDENT CARD」「AI経理」を提供する株式会社UPSIDERは2026年6月12日、公式コーポレートサイトで2026年4月1日のシステム障害に関する不正アクセス事案の最終報告を公開しました。

最終報告は、同社が2026年4月10日に公表した「続報」から外部セキュリティ専門機関によるフォレンジック調査（4月10日〜5月20日）が完了したことを受けて公開されるものです。最終報告の核心は2点です。

第一に、外部の専門機関による全ログ精査の結果、顧客のカード情報・個人情報・法人情報の外部流出を示す事実は確認されなかったという点。

第二に、4月1日に発生したサービス全停止が「攻撃そのものによるシステムダウン」ではなく「被害拡大を防ぐための自動保護機能の作動」であったという点です。

後者は事案の本質的な評価に関わる重要な事実であり、UPSIDERがこの時点で被害をコントロールできていたことを示しています。攻撃の入口はオープンソースソフトウェア（OSS）パッケージへの悪意あるプログラムの混入——いわゆる「ソフトウェアサプライチェーン攻撃」でした。本記事ではUPSIDERの公式最終報告書を一次ソースとして、攻撃連鎖の全容・調査結果の評価・再発防止策・情報システム担当者が自社に活かすべき教訓を解説します。

サマリー

2026年6月12日、UPSIDERが不正アクセス事案の最終報告を公開。外部フォレンジック調査（4月10日〜5月20日）の結果を反映
攻撃の入口：システム開発に使用していたOSS（オープンソースパッケージ）への悪意あるプログラムの混入——ソフトウェアサプライチェーン攻撃
攻撃連鎖：OSS実行→開発者端末の侵害（3月24日）→認証情報の漏えい通知（3月25日・3月31日）→自動保護機能が作動しサービス全停止（4月1日3:40）
サービス停止の原因は攻撃ではなく自動保護機能：「攻撃そのものによるシステムダウン」ではなく「被害拡大防止のためのシステム保護機能の作動」
調査結果：カード情報（カード番号・暗証番号・CVV）はトークン化管理のため保持なし。個人情報・法人情報の外部流出を示す事実は確認されず。一部外部サービスへの攻撃者アクセス可能期間はあったが実際の取得・閲覧の痕跡なし
復旧タイムライン：ログイン機能（4月1日10:57）→カード決済（4月1日12:20）→全機能（4月9日）
特別調査委員会による調査は完了し本最終報告が確定版
サービス規模：累計10万社以上（2025年11月時点）が導入するFinTech企業

1 攻撃の全容—OSSサプライチェーン攻撃の解剖
- 1.1 なぜOSSへの攻撃が危険なのか
2 3段階の攻撃連鎖
3 発覚から最終報告まで—対応タイムラインの全容
4 調査結果—「流出なし」判断の根拠と留保事項
- 4.1 カード情報：トークン化で保護
- 4.2 個人情報・法人情報：「流出なし」判断の丁寧な説明
5 再発防止策
6 情報システム担当者への教訓
7 参考情報

攻撃の全容—OSSサプライチェーン攻撃の解剖

なぜOSSへの攻撃が危険なのか

今回の攻撃の起点は「オープンソースパッケージへの悪意あるプログラムの混入」です。この「ソフトウェアサプライチェーン攻撃」は、2020年代に入って急速に増加している攻撃手法です。

OSSパッケージ（npmやPyPI等で配布されるライブラリ）は多数の開発者が同時に使用する「共有インフラ」です。

攻撃者がパッケージに悪意あるコードを混入することに成功すれば、そのパッケージを使用しているすべての開発環境に一度にマルウェアを送り込めます。開発者は「正規のパッケージをインストールした」つもりのまま、自分の端末が侵害されてしまいます。

OSSサプライチェーン攻撃は2024〜2026年にかけて国内外で急増しており、npm ecosystemへのLazarusグループ（DPRK）による攻撃（週1億DL以上のAxiosを標的）なども確認されています。

3段階の攻撃連鎖

最終報告が明示したUPSIDERへの攻撃は3段階の連鎖として再構成できます。

第1段階（3月24日）：開発者端末の侵害

悪意あるプログラムが混入されたOSSパッケージが実行されたことにより、当該パッケージを使用していた開発者の端末が侵害されました。この時点では、UPSIDERは侵害に気づいていませんでした。

第2段階（3月25日・3月31日）：認証情報漏えいの外部通知

3月25日に外部（クラウドサービス提供元）から「一部認証情報の漏えい」の通知を受領し、即時無効化の一次対応を実施しました。しかし3月31日には「新たに異なる認証情報の漏えい」という別の通知を受領。これを受けて対策本部を設置し、広範な被害範囲を想定した全域調査と緊急対応を開始しました。

2回の認証情報漏えい通知が別々に来ていることは、攻撃者が段階的に侵害範囲を拡大していた可能性を示しています。

第3段階（4月1日3:40）：自動保護機能の作動→全サービス停止

4月1日午前3時40分、不正アクセスに伴う異常を検知したシステム保護機能が自動作動し、全サービスが停止しました。

重要な事実：この停止は「攻撃者がシステムを破壊した」結果ではなく、**「攻撃を検知したUPSIDERのシステム保護機能が被害拡大を防ぐために能動的に実行した措置」**です。4月1日4時から10時にかけて、対象デバイスの隔離・攻撃経路の遮断・全本番環境サーバのクリーンアップと整合性チェックを実施し、10時57分にはログイン機能を、12時20分にはカード決済機能を復旧させています。

発覚から最終報告まで—対応タイムラインの全容

日付	出来事
2026年3月24日	OSSパッケージ実行→開発者端末が侵害される
2026年3月25日	外部から認証情報漏えいの通知受領→即時無効化・一次対応完了
2026年3月31日	別の認証情報漏えいの通知受領→対策本部設置・全域調査開始
2026年4月1日 03:40	システム保護機能が自動作動→全サービス停止
2026年4月1日 04:00〜10:00	デバイス隔離・攻撃経路遮断・サーバクリーンアップ・整合性チェック
2026年4月1日 10:57	ログイン機能・管理画面の復旧
2026年4月1日 12:20	カード決済機能の全面復旧
2026年4月9日まで	全機能を段階的に復旧
2026年4月10日	セキュリティ事案を公表。外部フォレンジック調査を開始
2026年5月20日	外部機関による全ログ精査・影響範囲の特定が完了
2026年6月12日	最終報告を公開

開発者端末の侵害（3月24日）から最終報告公開（6月12日）まで約80日間にわたる対応でした。

調査結果—「流出なし」判断の根拠と留保事項

カード情報：トークン化で保護

最終報告によれば、UPSIDERは侵害されたネットワーク内でカード関連情報をトークン化された識別子のみで管理しており、カード番号・暗証番号・セキュリティコード（CVV）を保持していません。PCI DSS（ペイメントカード業界データセキュリティ基準）が要求するトークン化がUPSIDERの実際のリスクを大幅に低減した実例です。外部調査においてもこれらの情報への不正アクセスおよびデータ持ち出しの痕跡は確認されていません。

個人情報・法人情報：「流出なし」判断の丁寧な説明

個人情報・法人情報については、最終報告が注目すべき丁寧な説明を行っています。

顧客データベースへの通信ログ・操作ログを精査した結果：外部への情報流出を示す事実は確認されず
攻撃者が「一部の外部サービス上の情報にアクセスし得た期間」が存在したが：実際に情報が閲覧・取得されたことを示す痕跡は確認されず
「外部サービスの仕様上の制約によりログ検証が困難な領域」が存在したが：外部ベンダーへの直接照会、二次被害や不審な挙動の報告実績を含め総合的に評価した結果、流出の痕跡は確認されず

この説明が示すのは、UPSIDERが「完全なログが取れなかった領域」の存在を開示した上で、それを複数の手法（直接照会・二次被害確認等）で補完して「流出の可能性は極めて低い」という判断に至ったということです。「ログが取れなかった部分についての評価手法まで開示した」という透明性の高さは、インシデント対応の模範的な姿勢として評価できます。

再発防止策

最終報告が示した再発防止の方向性は以下のとおりです。

入口での侵害防止の強化に加え、**「万が一の侵入を想定した被害最小化」**というゼロトラスト的な発想を前面に出している点が注目されます。入口を完全に塞ぐことは困難であるという現実認識のもと、侵入後の被害をいかに限定するかという「多層防御（Defense in Depth）」の考え方です。

具体的には内部アクセス制御の更なる厳格化（最小権限の原則の徹底・開発者端末から本番環境へのアクセス経路の制限等）と、潜在的な予兆を早期に捉えるための多角的な分析基盤の強化（SIEM・UEBA等による異常検知の高度化）が挙げられています。

情報システム担当者への教訓

今回のUPSIDERの事案から、自社のセキュリティ対応に活かすべき教訓を整理します。

OSSパッケージの利用リスク管理：開発環境で使用するOSSパッケージの定期的な脆弱性スキャン（Software Composition Analysis：SCA）と、パッケージのハッシュ値検証による改ざん検出の導入を検討してください。GitHub Advanced SecurityやSnyk・OWASP Dependency-Checkなどのツールが活用できます。

開発環境と本番環境の隔離：今回の攻撃は「開発者端末の侵害」から「本番システムへのアクセス」につながっています。開発環境から本番環境への直接アクセスを制限し、承認済みのCI/CDパイプラインのみを通じたデプロイを強制することで、この種の攻撃のラテラルムーブメントを制限できます。

認証情報の外部漏えい監視：今回UPSIDERは3月25日と3月31日に「外部クラウドサービス提供元からの認証情報漏えい通知」を受け取りました。GitGuardian・Trufflesecurity等のシークレットスキャニングツールや、HaveIBeenPwned等のクレデンシャル漏えい監視の導入が早期発見に有効です。

カード情報のトークン化の重要性：今回UPSIDERの被害が限定的だった大きな理由の一つが、カード情報のトークン化による「保持しない」設計です。カード決済機能を持つサービスにおいては、PCI DSSへの準拠とトークン化・ポイント・トゥ・ポイント暗号化（P2PE）の採用が根本的なリスク低減につながります。

自動保護機能の設計：今回のシステム停止が「被害拡大防止の自動措置」として実行されたことは、UPSIDERの事前設計が機能した証拠です。「攻撃を検知した時に自動的にサービスを停止・隔離するシステム保護機能」の実装と、その発動後の迅速な復旧フローの整備がセットで必要です。