UPSIDER、開発者端末の侵害による不正アクセス・サービス一時停止 最終報告書を公表：一次対応で「認証情報刷新」も 6日後に別の認証情報を盗まれる

UPSIDERは2026年4月1日に発生した第三者による不正アクセス事案およびシステムの一時停止について、外部の専門機関によるフォレンジック調査を踏まえた報告書を公表した。

[石川俊明，＠IT]

　法人向け決済サービスを展開するUPSIDERは2026年6月12日、同年4月1日に発生した第三者による不正アクセス事案および被害拡大の防止を目的としたサービスの一時停止について、外部のセキュリティ専門機関による調査結果を踏まえた最終報告書を公表した。

　不正アクセスの原因は、システム開発で使用していた外部ソフトウェア（オープンソースパッケージ）に悪意あるプログラムが混入された「ソフトウェアサプライチェーン攻撃」だった。外部の専門機関によるログ精査の結果、顧客情報やカード情報の外部への流出を示す事実は確認されなかったという。

　同社は、スタートアップや中堅企業を中心に累計10万社以上（2025年11月時点）が導入するクラウド法人カードなどを展開するFinTech企業。公表された報告書から、開発者端末の侵害からサービスの一時停止の対応に至るまでのいきさつが明らかとなった。

「漏えいした認証情報を無効化・刷新」も　6日後に別の認証情報を盗まれる

　報告書によると、不正アクセスの発端は2026年3月24日、悪意のあるプログラムが混入されたOSS（オープンソースソフトウェア）の実行により、開発者端末が侵害されたことにある。

　翌25日に一部の認証情報に関する漏えい通知を受領し、同社は当該情報の無効化および刷新の一次対応を完了した。しかし、6日後の2026年3月31日21時37分、システム内部の異なる認証情報が窃取された兆候を検知。広範な漏えいの恐れがあると判断し、対策本部を設置して緊急対応を開始した。

　2026年4月1日3時40分、不正アクセスに伴う異常を検知し、被害拡大を防止するシステム保護機能（サーバの強制停止）が作動。カード決済およびログインを含む全サービスが一時停止した。

　同日4時から10時にかけて、対象デバイスの隔離、攻撃経路の遮断、全本番環境サーバのクリーンアップおよび改ざんの有無を調べる整合性チェックを実施。同日10時57分にログイン機能を復旧し、同日12時20分にカード決済機能を復旧させた。

開発者端末の侵害から報告書公開までのタイムライン（提供：UPSIDER）

　外部専門機関を交えたフォレンジック調査では、侵害が発生した2026年3月24日から遮断に至る全期間までのログを精査した。ネットワーク内において、カード関連情報をトークン化された識別子のみで管理しており、カード番号・暗証番号・セキュリティコードは保持していない。この不正アクセスによるデータ持ち出しの痕跡は確認されなかったという。

　「顧客データベースのログを精査した結果、情報流出を示す事実は確認されなかった。一部の外部サービス上の情報にアクセスし得た期間はあったものの、仕様上の制約によりログ検証が困難な領域についても、外部ベンダーへの直接照会や二次被害の有無などを総合的に評価した結果、情報が閲覧・取得された痕跡は確認されていない」（UPSIDER）

今後の対応

　既に実施した復旧対応として、侵害された可能性のある全認証情報の刷新、侵害端末の隔離、全本番環境サーバの健全性確認を挙げている。同社は今後の恒久対応として「入口での侵害防止強化」の他、「内部アクセス制御の厳格化」「潜在的な予兆を早期に捉えるための多角的な分析基盤と体制の強化」を進めるとしている。

記者の目

　2026年に入り、企業の開発環境やソフトウェアサプライチェーンを狙ったサイバー攻撃が国内外で猛威を振るっている。OpenAIがJavaScriptライブラリ「TanStack」を狙ったソフトウェアサプライチェーン攻撃により従業員端末が侵害された事案（関連記事）や、GitHubの認証情報を窃取され、サービスの一時停止やソースコード・個人情報の漏えいといった事案に直面したマネーフォワードの事例が記憶に新しい（関連記事）。UPSIDERの事案も、まさに一連のトレンドと地続きにある、極めて深刻な国内の被害事例といえる。

　ソフトウェアサプライチェーン攻撃を巡っては、OSSエコシステムそのものの構造的な難しさが指摘されている。悪意あるパッケージが公開された際、OSSコミュニティーはわずか数時間未満で発見し、その都度無効化（テイクダウン）してきた。しかし攻撃者はそのわずかな露出時間の間にダウンロードした開発者の端末を乗っ取り、次の侵害につなげるための認証情報（クレデンシャル）を窃取している（関連記事）。迅速な一次対応だけでは攻撃者を完全に食い止めることが困難というわけだ。

　UPSIDERの報告書からは「25日の対応後も開発者端末を通じて攻撃者が6日間かけてシステム内部を探索した」のかどうかは読み解けない。しかし事実として、一次対応で認証情報を刷新したにもかかわらず別の認証情報が窃取されていることから、「流出した認証情報は直ちに無効化・変更する」というセキュリティの定石だけでは、ソフトウェアサプライチェーン攻撃の脅威を完全に排除しきれないことを示唆している。

　では、開発者や開発者端末という「強力な権限を持ちながら、無防備になりやすい入り口」を守るために、あらためて企業はどのような対策に乗り出すべきなのか。

　1つ目は「開発者端末はいつか必ず侵害される」という前提に立ち、開発者端末が侵害されたときに自社ではどのようなビジネスリスクが生じるのかを再点検するとともに、現在利用しているコンポーネントを棚卸しすることだ。ただし、開発者の権限を厳格に分離したことで、自由度が低下する場合、開発スピードを著しく低下させるリスクもある。利便性とセキュリティをどう両立させるかがポイントとなる。

　2つ目は、想定されるビジネスインパクトを踏まえ、サイバー防御やIT投資の優先順位を見直すことだ。システムのダウンタイムが生じれば売上減少や顧客からのクレーム、信用の失墜といったリスクに直結する。被害に遭う前から、経営層をはじめとするステークホルダーと「有事の際のビジネス継続性とセキュリティのトレードオフ」について認識を共有しておくことが重要だ。

　3つ目は、ハッキングされても「悪用できる永続的な認証情報」を与えないアプローチへの移行だ。UPSIDERのようにデータをトークン化して保持しないデータ設計は理想的だが、既存システムの構造やビジネスモデルによっては、一朝一夕での導入が困難なケースも考えられる。まずは都度発行、廃棄するような「リフレッシュトークンローテーション」への移行や、侵害を前提とした対策を検討したい。

　攻撃者が防衛側の対策を回避すべく、信頼されがちで監視の目が届きにくい「開発エコシステム」を突いて内部への侵入を成功させている今、企業には「開発者端末はいつか必ず侵害される」という前提に立ち、利便性とセキュリティを両立させる現実的な対策が求められている。