UPSIDER 2026年 開発者の端末で動かした悪いOSSからの侵入

悪意あるプログラムが混入したOSSのパッケージを動かし、開発者の端末が侵害された。翌日に漏れた認証情報を無効にして一次対応を終えたが、6日後に別の認証情報が漏れ、システムの内部に入られた。異常を検知した保護の仕組みが働き、法人カードを含む全サービスが止まった。

UPSIDER の最終報告 2026年6月12日に沿って書いています。最終報告の時点で、全機能は2026年4月9日までに段階的に戻り、外部の専門機関による全ログの精査と影響範囲の特定は5月20日に終わり、個人情報と法人情報の流出の可能性は極めて低いと判断されています。最終報告は、パッケージの名前、漏れた認証情報の種類、漏えいを誰が知らせたかを書いていません。

要点

  • 端緒は、開発に使っていたOSSのパッケージに悪意あるプログラムが混入したサプライチェーン攻撃。開発用の端末が侵害され、そこを経由してシステムの内部に届いた。
  • 3月25日に一部の認証情報の漏えいの通知を受けて即時に無効にしたが、3月31日に異なる認証情報の漏えいの通知を受けた。間は6日。
  • 4月1日3時40分に保護の仕組みが働いて全サービスが止まり、カード決済は同日12時20分に全面に戻った。
  • カード番号、暗証番号、セキュリティコードは、侵害された網の中に無く、トークン化した識別子だけだった。
  • 根本の直しは、開発の端末に本番へ届く長命の鍵を置かないこと。端末が侵害されたら、知らされた1つでなく、端末から届く鍵をすべて替える。

何が起きたか

3月24日に端末が侵害され、25日に1つ目の認証情報を無効にし、31日に別の認証情報の漏えいを知り、4月1日に全サービスが止まり、4月9日までに戻り、6月12日に最終報告が出た 侵害と初動 3月24日 悪いパッケージを 動かし端末が侵害 3月25日 漏えいの通知 即時に無効化 3月31日 別の認証情報の 漏えいの通知 4月1日 3時40分 保護の仕組みが働き 全サービスが停止 間の6日 復旧と調査 4月1日 10時57分 ログイン 12時20分 カード決済 4月9日まで 全機能を 段階的に復旧 4月10日 公表。フォレンジック 調査を始める 5月20日、6月12日 全ログの精査を終え 最終報告を公開 始まりは3月24日、組織が知ったのは3月25日の通知
図1 最終報告の経緯と対応のタイムライン
日時最終報告の内容
2026年3月24日悪意あるプログラムが混入した外部のソフトウェアを実行し、開発者の端末が侵害される[1]
2026年3月25日一部の認証情報の漏えいの通知を受ける。その情報を即時に無効にし、一次対応を終える[1]
2026年3月31日新たに異なる認証情報の漏えいの通知を受ける。すぐに対策本部を置き、被害の範囲が広い懸念から、全域を対象に調査と緊急の対応を始める[1]
2026年4月1日 3時40分被害の拡大を防ぐ保護の仕組みが働き、全サービスが一時停止[1]
2026年4月1日 10時57分ログインの機能と管理画面が戻る[1]
2026年4月1日 12時20分カード決済の機能が全面に戻る[1]
2026年4月9日まで全機能を段階的に戻す[1]
2026年4月10日セキュリティの事案として公表。外部の専門機関によるフォレンジック調査を始める[1]
2026年5月20日外部機関による全ログの精査と影響範囲の特定を終える[1]
2026年6月12日最終報告を公開[1]
  • 止まったのは、法人カードの UPSIDER、PRESIDENT CARD、AI経理の各サービス[1]。
  • 侵害された網の中では、カードの関連の情報をトークン化した識別子だけで持ち、カード番号、暗証番号、セキュリティコードを持っていなかった。それらへの不正アクセスと持ち出しの痕跡も無かった[1]。
  • 顧客のDBへの通信ログと操作ログの精査では、外への流出を示す事実は無かった。攻撃者が一部の外部サービスの情報に届き得た期間はあったが、閲覧や取得の痕跡は無かった。外部サービスの仕様でログの検証が難しい領域は、ベンダーへの照会と二次被害の報告の有無を合わせて評価した[1]。

通った道筋

悪意あるプログラムが入ったOSSのパッケージを開発者の端末で動かし、端末の認証情報が漏れ、1つを無効にした後に別の認証情報でシステムの内部に入られ、保護の仕組みがサーバーを止めた 外の部品 開発者の端末 サービスの側 OSSの パッケージ 悪いコードが混入 名前は最終報告 に無い 3月24日 実行 端末が侵害される 開発の作業の中で 端末から届く 認証情報 1つ目 25日に無効化 2つ目 31日に通知 システムの内部 開発用の端末を経由して アクセスできる状態 保護の仕組み 異常を検知して自動で サーバーを止める 2つ目の出どころは 最終報告に無い
図2 最終報告の発生原因の節をもとにした道筋。認証情報の種類と、どの認証情報で内部に入ったかは書かれていない

最終報告の発生原因は2つに分けて書かれる。不正アクセスの原因は、パッケージを通じて開発用の端末が侵害され、これを経由してシステムの内部へアクセスできるようになったこと。サービス停止の原因は、その異常を検知して、被害の拡大を防ぐ保護の仕組みが働き、サーバーが止まったこと[1]。

使っているパッケージに悪いプログラムが混入する型は、正規の名前のまま悪い版が出る形で、A03 ソフトウェアサプライチェーンの不備 の型2にあたる。導入の時のスクリプトで端末の資格情報を集めて外へ送る例もそこにある。開発の環境から取られた秘密が次の段に使われた海外の例に LastPass 2022年 がある。

どのパッケージだったか

最終報告はパッケージの名前も、言語の生態系も、悪いコードが何をしたかも書いていない[1]。同じ頃の他の悪い版の件と結び付けて読まない。2つ目の認証情報が1つ目と同じ端末から取られたものかも書かれていない。

1つを替えても残るもの

開発者の端末には、用途の違う鍵が並ぶ。架空の端末で示す。悪いコードが端末で動いた時点で、この一覧の全部が取られたものとして扱う。漏えいの通知が届くのは、そのうち提供元が見つけた1つかもしれない。

悪い例。架空の開発者の端末にある鍵と、通知の届いた1つだけを替えた初動

# 架空の端末 dev-07.example.com の鍵の棚卸し
~/.npmrc                 公開の権限のあるトークン      通知あり。無効化した
~/.config/gh/hosts.yml   リポジトリへ書けるトークン    替えていない
~/.aws/credentials       本番の長命のアクセスキー      替えていない
~/work/api/.env          本番DBの接続の文字列          替えていない
~/.ssh/id_ed25519        踏み台 192.0.2.10 へ入れる鍵  替えていない

直した例。端末から届く鍵を全部替え、端末を作り直し、そもそも本番の鍵を置かない

1 端末を網から外し、作り直す。中身を信じて掃除しない
2 端末から届いた鍵と、その端末で開いていたセッションを全部無効にする
3 無効にした鍵の利用の記録を、侵害の時刻から遡って見る
# 次からは、本番へは期限の短い資格情報を作業のたびに発行し、端末に長命の鍵を残さない

CISA は、npm の生態系の広い侵害のときに、開発者の資格情報をすぐに全部回すよう求めた[2]。漏れた鍵の扱いの順は、無効化、差し替え、使われた跡の調査、掃除、再発の止めである。秘密の鍵の扱い の漏れたときの順にある。

どこで止められたか

取り込む、動く、持っている、一部だけ替える、内部へ届く、の5段それぞれの下に、止める仕組みを置く 1 取り込む 悪い版が入る 2 動く 端末が侵害 3 持っている 端末の鍵が漏れる 4 一部を替える 6日後に別の鍵 5 内部へ届く 保護で全停止 取り込みの網 版の固定 日の浅い版を待つ 走らせない 導入時のスクリプト 隔てた作業の場 置かない 本番へ届く長命の 鍵を端末に置かない 全部替える 届く鍵を全部 端末も作り直す 内部の制御 接続元と権限を 絞る。検知で止める 3が根本。4は端末が侵害されたと知った時に1回で済ませる初動
図3 侵入が進む5段と、それぞれで止める仕組み
段この件で発表されたこと止める仕組み
1 取り込む開発で使っていたOSSのパッケージに悪いプログラムが混入した[1]版をロックファイルで固定し、公開から日の浅い版を入れない[3][4]
2 動くそのソフトウェアを実行し、開発者の端末が侵害された[1]導入の時のスクリプトを既定で走らせない。外の部品を動かす作業を、鍵の無い隔てた場で行う[5]
3 持っている端末を経由してシステムの内部にアクセスできる状態になった[1]本番へ届く長命の鍵を開発の端末に置かない。要るときに期限の短い資格情報を発行する[6]
4 一部を替える3月25日に通知された認証情報を無効にして一次対応を終えたが、31日に異なる認証情報の漏えいの通知を受けた[1]端末が侵害されたと分かった時点で、端末から届く資格情報を全部回し、端末を作り直す[2]
5 内部へ届く異常を検知した保護の仕組みが自動で働き、サーバーを止めた[1]。再発防止策に内部のアクセス制御の厳格化と、予兆を捉える分析の基盤を挙げた[1]開発者の資格情報で届く範囲を絞る。止める仕組みは、止める範囲を決めておく

1と2 取り込む、動く。部品の入口

悪い版は正規の名前で出るため、名前を確かめても防げない。止める所は、版を意図して選んで固定すること、出た直後の版を入れないこと、導入の時に走るスクリプトを止めることである。pnpm の minimumReleaseAge と、導入の時のスクリプトの扱いは AIが持ち込む部品の危険 にある。npm の ignore-scripts は、依存の導入の前後に走るスクリプトを止める[5]。どれも、悪い版に気付かれる前に入れてしまう時間を縮める策で、固定した版そのものが悪ければ防げない。

3 持っている。端末に置く鍵

端末で悪いコードが動けば、その利用者が読めるものは全部読まれる。端末の上の秘密を守る手は、端末の外にしか無い。本番へ届く鍵を端末に置かず、作業のたびに期限の短い資格情報を発行すれば、漏れても使える時間が限られる[6]。置き場所と権限の絞り方は 秘密の鍵の扱い にある。AIの道具に開発を任せる端末でも同じで、道具が読める鍵は道具が動かす部品にも読める。

4 一部を替える。初動の範囲

この件で最も多くを教える段である。3月25日の一次対応は、通知された認証情報の無効化だった[1]。その時点で分かっていたのは、外の部品のせいで鍵が漏れたことである。報告の表だけでは、端末の侵害が25日に分かっていたかは読み取れない。ただ、漏えいの通知が1つ届いたら、その鍵の出どころを辿り、出どころが端末なら端末から届く鍵を全部漏れたものとして扱う、という順で初動の範囲を決められる。31日には、同社は全域を対象とする調査と対応に切り替えた[1]。

通知は漏れの全部ではない

漏えいの通知は、提供元か誰かが見つけた鍵の分だけ届く。通知の無い鍵が漏れていないことを示さない。

5 内部へ届く。止める仕組みと、止まる範囲

保護の仕組みは、異常を検知して自動でサーバーを止めた。その結果、3時40分から12時20分まで、カード決済を含む全サービスが止まった[1]。最終報告は、カードの情報の不正アクセスと持ち出しの痕跡も、顧客のDBからの流出を示す事実も無かったとする[1]。止める仕組みは被害を限る側に働いたが、決済のように止まると利用者が困るサービスでは、どの異常でどこまで止めるか、戻すときに何を確かめるかを先に決めておく。カードの番号を網の中に持たずトークン化していたことも、侵入された後に効く守りである[1]。

守り方

根本の直し
  • 開発の端末に、本番へ届く長命の鍵を置かない。作業のたびに期限の短い資格情報を発行する[6]。秘密の鍵の扱い
  • 端末が侵害されたら、通知の来た鍵だけでなく、端末から届く資格情報とセッションを全部無効にし、端末を作り直す[2]。
  • 外の部品の版を意図して選んで固定し、ロックファイルと差分で変化を見る[3]。A03 ソフトウェアサプライチェーンの不備
緩和の策
  • 導入の時のスクリプトを既定で止め、要る部品だけ確かめて許す[5]。公開から日の浅い版を入れない。AIが持ち込む部品の危険
  • 外の部品を初めて動かす作業は、本番の鍵の無い隔てた場で行う。
  • 開発者のアカウントにフィッシングに強い多要素認証を掛け、外への通信の異常を見る[2]。
  • 開発者の資格情報で届く内部の範囲を絞り、内部のアクセスを記録して予兆を見る。同社の再発防止策もこの2つを挙げる[1]。
  • 自動で止める仕組みは、止める範囲と戻す手順を先に決めておく。
  • カードの番号のような値は、侵入され得る網の中に持たず、トークンにする[1]。

参照

  1. 最終報告 2026年4月1日のシステム障害に関する不正アクセス事案に関する調査結果のご報告 UPSIDER、2026年6月12日
  2. Widespread Supply Chain Compromise Impacting npm Ecosystem CISA、2025年9月23日
  3. A03:2025 Software Supply Chain Failures OWASP Top 10:2025
  4. Dependency resolution settings, minimumReleaseAge pnpm Docs
  5. npm config, ignore-scripts npm Docs
  6. Secrets Management Cheat Sheet OWASP Cheat Sheet Series