ホーム / Critical Brief / No. 101

Paysafe 偽 SDK：正規の決済 SDK を装う 17 パッケージが、決済 API 鍵ごと開発者の秘密を持ち出した

Pillar 01 · 来歴証明 コード来歴 KYC / AML 開示属性証明バイパス
事案日
2026-07-07
公開日
2026-07-10
発行
Lemma Critical Team
関連 Pack
Pack AIncident Response

TL;DR

サプライチェーンセキュリティ企業 Socket が、決済サービス Paysafe・Skrill・Neteller の SDK を装う 17 の悪性パッケージ（npm 13 件・PyPI 4 件）を検出した。各パッケージは正規 SDK が備えるはずの API をそのまま露出し、呼び出しには偽の成功応答を返しつつ、裏で開発環境の秘密を探索して持ち出す。窃取対象は Paysafe API 鍵・AWS 鍵・GitHub トークン・npm トークン、ホスト名・ユーザー名、API 利用メタデータに及び、KYC 系の paysafe-kyc も含む。npm 側は公開から約 6 分でマルウェアとして検知されたが、サンドボックス指標や CPU コア数が 2 未満の環境では処理を打ち切る解析回避を備えていた。手口自体は typosquat の反復だが、本事案に固有なのは、盗まれる対象が決済実行の権限そのもの（Paysafe API 鍵）と KYC 系の資格情報である点だ。決済・本人確認という規制属性の塊が、SDK という信頼された体裁のまま、来歴を検証されずに CI/CD・本番へ取り込まれた。検出と事前証明は代替ではなく補完である。

事案概要

  • 対象: Paysafe・Skrill・Neteller（いずれも決済・電子マネー系サービス）の公式 SDK を装う悪性パッケージ。標的はこれらの決済連携を実装する開発者
  • 検出: サプライチェーンセキュリティ企業 Socket の AI スキャナーが、npm と PyPI にほぼ同時公開されたクラスタを検出
  • 規模: 計 17 パッケージ（npm 13 件・PyPI 4 件）。paysafe-checkout・paysafe-vault・paysafe-api・paysafe-node・paysafe-payments・paysafe-sdk・paysafe-kyc・skrill・skrill-sdk・skrill-payments・neteller などを含む
  • 手口の核心: 各パッケージは正規 SDK が備えるはずの API を露出し、機能するように見せかける。実際には Paysafe のバックエンドと通信せず偽の成功応答を返し、その裏で環境内の秘密（トークン・パスワード・API 鍵）を探索して外部へ送出する
  • 窃取対象: Paysafe API 鍵・AWS 鍵・GitHub トークン・npm トークン、ホスト名・ユーザー名、API 利用に関するメタデータ
  • 解析回避: 一般的なサンドボックス指標が検出された場合や、ホストの CPU コア数が 2 未満の場合に早期リターンし、自動解析環境での発覚を抑える。C2 の最終宛先は XOR・文字シフト・反転による多段デコードで隠され、ngrok 系インフラ下のトラッカードメインに解決された
  • 検知の速さ: npm 側の各パッケージは 1.0.0〜1.0.3 のバージョンを刻み、公開から約 6 分でマルウェアとして検知された
  • 核心: 決済実行の権限を表す API 鍵と KYC 系の資格情報という規制属性の塊が、「決済 SDK」という信頼された体裁のパッケージを通じて、その来歴（正規の発行元に由来し認可された配布物か）を検証されないまま開発環境・CI/CD に取り込まれた

タイムライン

  • 2026-07-07: Socket の AI スキャナーが npm・PyPI に同時公開された 17 パッケージのクラスタを検出。npm 側は各パッケージ公開から約 6 分でマルウェア判定
  • 2026-07-07 以降: Socket が手口（正規 API を装い偽の成功応答を返しつつ秘密を窃取）・窃取対象・解析回避・C2 の難読化を公開し、依存ツリーの点検、CI/CD ログの監査、レジストリプロキシでのパッケージ名ブロック、CI ログ内の PAYSAFE_API_KEY と当該パッケージ名の突合を推奨

注: 技術的事実は Socket の解析および BleepingComputer の報道に基づく。パッケージ数（17）・約 6 分での検知・窃取対象・解析回避・C2 難読化は Socket の観測による。取り込み被害の実件数は本稿時点で公表されていない。最新の一次情報を参照されたい。

攻撃ベクター

  1. 正規 SDK への擬態: 攻撃者が Paysafe・Skrill・Neteller の SDK に似せた名称（typosquat）でパッケージを npm・PyPI に公開する。正規 SDK が備えるはずの API をそのまま露出し、機能するように見せかける
  2. 偽の成功応答: パッケージは Paysafe バックエンドと通信せず、呼び出しに対して偽の成功応答を返す。連携が「動いているように見える」ため、開発者が異常に気づきにくい
  3. 秘密の探索と窃取: 裏で環境内の秘密（Paysafe API 鍵・AWS 鍵・GitHub トークン・npm トークン、ホスト名・ユーザー名、API 利用メタデータ）を探索し、外部へ送出する
  4. 解析回避: サンドボックス指標や CPU コア数 2 未満の環境では早期リターンし、自動解析での発覚を抑える。C2 の最終宛先は多段デコード（XOR・文字シフト・反転）で隠す
  5. 取り込みと横展開: 窃取された決済 API 鍵・KYC 資格情報・クラウド／レジストリのトークンは、決済処理の悪用、CI/CD への侵入、正規レジストリでの追加パッケージ公開など、規制属性と開発権限の双方に跨る悪用に用いられ得る

構造的論点

本事案は Pillar 01（来歴証明）の code-provenance カテゴリに属する。中心的な失敗 primitive は、開発者が依存として取り込むパッケージ（SDK）が、正規の発行元に由来し認可された配布物かという来歴を、取り込みの前に独立検証していなかった点にある。パッケージは正規 SDK の API をそのまま露出して「決済 SDK」の体裁を満たしたが、その体裁は発行元の真正性を保証しない。手口としての typosquat は、Brief No.028（npm dependency confusion による開発環境偵察）・Brief No.038（IronWorm、盗んだ認証情報で自分を再公開する npm ワーム）・Brief No.090（AIR、偽のエージェントスキルが全スキャナーを通過した）と同じ系列にあり、いずれも「取り込む配布物の来歴が実行・インストールの前に検証されない」構造を共有する。

本事案に固有なのは、窃取される対象が汎用の開発シークレットにとどまらず、決済実行の権限を表す Paysafe API 鍵と、KYC 系の資格情報（paysafe-kyc を含む）という規制属性の塊である点だ。ここで Pillar 04 の視点が重なる。決済 API 鍵は、それを保持する者が資金移動を実行できる規制上の権限であり、KYC 資格情報は本人確認という規制属性を扱う資格である。これらが「決済 SDK」という信頼された体裁で来歴未検証のまま取り込まれ、まとめて流出したことは、Brief No.077（IDMerit、約 10 億件の KYC データ露出）や Brief No.013（Coinbase、内部経由の KYC 生 PII 漏洩）が示した「本人確認・規制属性の塊が、保管・取り込みの時点で真正性を検証されない」構造と接続する。secondary に、決済・KYC の資格情報が対象である点で kyc-aml-disclosure、決済・本人確認の権限が来歴未検証で受理・流出した点で attribute-proof-bypass を併記する。

さらに、偽の成功応答という挙動は、決済連携そのものの完全性にも触れる。連携が「動いているように見える」まま実体では正規バックエンドと通信していない状態は、決済フローの来歴・真正性が実行の前に固定されていないことの表れである。共通する primitive は同じである。すなわち、配布物と、それが運ぶ規制属性の権限が、その来歴を検証する層と切り離されたまま取り込まれている。

検出と証明の落差

Socket の AI スキャナーによる約 6 分での検知、手口・窃取対象・C2 難読化の公開、依存ツリー点検や CI ログ突合の推奨は、被害の拡大抑止と早期対応に不可欠であり、本 Brief がその役割を否定するものではない。実際、公開から数分での検知は、取り込み前に多くの開発者を守り得る。検出は確かに役割を果たす。

一方で、検出は「これから取り込もうとしている決済 SDK が、正規の発行元に由来し認可された配布物か」を、開発者がそれを依存として取り込む時点で独立に立証する材料にはならない。悪性パッケージは正規 SDK の API を露出し、偽の成功応答で機能を装うため、名称と振る舞いの表層からは正規物と区別しにくい。シグネチャや評判に基づく検知は、新規公開の初期には後追いになりやすく、6 分の間に取り込んだ環境では、決済 API 鍵や KYC 資格情報が送出された後になる。監査で「この決済連携は正規に発行された SDK に由来し、この API 鍵は認可された経路でのみ用いられたか」を立証する材料として、「決済 SDK の API を備えていた」という事実だけでは、発行元の来歴や属性権限の使用の独立した証跡にならない。これは検出層の射程外にある、構造的に独立した層の落差である。

事前証明（pre-execution attestation）は、パッケージの取り込みと、それが運ぶ属性権限の使用の経路に、来歴の証明を 1 段挟むことでこの落差を埋める。依存を取り込む前に「この配布物は正規の発行元に由来し、認可された版か」を検証し、証明が伴わなければインストール・実行を事前に block する。加えて、決済 API 鍵や KYC 資格情報のような規制属性の権限を、その保管と使用を分離し、「この属性はこの操作にこのスコープで用いられる」ことを証明した上でのみ行使可能にすれば、鍵の平文流出そのものを避けられる。事前証明は検出に対する代替ではなく 補完 であり、両層の組み合わせで、決済・KYC を扱う開発サプライチェーンの trust boundary が確立される。

対応経緯と業界動向

  • 研究（Socket）: AI スキャナーで 17 パッケージを検出し、npm 側は各公開から約 6 分でマルウェア判定。開発者には、依存ツリーの点検、CI/CD ログの監査、レジストリプロキシでの当該パッケージ名のブロック、CI ログ内の PAYSAFE_API_KEY と当該パッケージ名の突合による侵害有無の確認を推奨
  • レジストリ（npm / PyPI）: 悪性パッケージは検知後に対処対象となる。ただし新規公開の初期数分は検知が後追いになりやすく、取り込んだ環境では秘密の送出が先行し得る
  • 業界横断の論点: 決済・KYC のような規制属性を扱う SDK は、窃取された鍵・資格情報が即座に資金移動や本人確認の悪用に直結するため、汎用ライブラリの typosquat より被害の射程が広い。決済連携を実装する組織では、依存の来歴検証（署名・発行元の確認）と、決済 API 鍵・KYC 資格情報の保管と使用の分離が、対策の要として共有された。2026 年前半だけで npm・PyPI のサプライチェーンキャンペーンは前年を大きく上回るペースで増えており、来歴検証を取り込み時点に置く必要性が繰り返し指摘されている

Lemma による分析

本事象で露呈した検出と証明の落差（決済 SDK の来歴と、それが運ぶ決済・KYC の属性権限が、取り込み・使用の前に独立検証されない）に対し、Lemma は以下の設計を提示する。

  • 配布物の来歴の事前証明: 依存パッケージを取り込む前に、それが正規の発行元に由来し認可された版であることを独立検証し、証明が伴わなければインストール・実行を事前に reject する
  • 属性権限の保管と使用の分離: 決済 API 鍵や KYC 資格情報のような規制属性の権限を、平文で環境に置いて全継承させるのではなく、「この属性はこの操作にこのスコープで用いられる」ことを証明した上でのみ行使可能にする。鍵そのものを送らずに、権限の充足だけを証明する
  • 決済フローの真正性の固定: 決済連携が正規のバックエンドに接続していることを来歴として固定し、偽の成功応答のように実体を伴わない連携を、証明の欠落として検出可能にする
  • 選択的開示: 決済・本人確認の資格情報そのものを開示せずに、「この主体はこの決済・この属性の権限を満たす」ことだけを最小開示で証明する

検出（事後のスキャン・手口の公開・依存点検）は被害の是正に、事前証明（取り込み・使用前の来歴と属性権限の独立検証）は決済・KYC を扱う開発サプライチェーンの信頼確立に、それぞれ相補的に働く。

Sources

Brief 配布について

本資料は公開情報の構造化分析であり、特定組織への監査・診断・推奨ではありません。

(c) 2026 FRAME00, INC. — Built for decisions that matter.

関連 Brief
コード来歴の全 26 件を見る
No. 100 · 2026-07-10

Aptos：Move VM の型混同で、あるオンチェーン資源が別の資源として扱われ得た（約 3,000 ドルの検証環境で再現）

ブロックチェーンセキュリティ企業 Hexens が、Aptos の Move VM（同レイヤー 1 上の全スマートコントラクトを処理する実行環境）に、stale-cache（古いキャッシュ）由来の type-confusion（型混同）で、…

コード来歴 ブリッジ信頼設定データ来歴
Brief →
No. 092 · 2026-07-01

exploitarium：匿名の「bikini」が AI 自動ファジングで見つけた多数のゼロデイ PoC を一括公開し、報告の来歴・真正性を受け手が検証できない

Vulnpocalypse の具体例

コード来歴 エージェント暴走認証・認可
Brief →
No. 090 · 2026-06-30

AIR：偽のエージェントスキルが全スキャナーを通過し、約26,000エージェントに到達した

スキャン後に差し替えられる外部リンクが盲点だった

コード来歴 エージェント基盤認証・認可
Brief →
Cite this Brief

この Brief を引用する

Lemma Critical Team. (2026).
"Paysafe 偽 SDK：正規の決済 SDK を装う 17 パッケージが、決済 API 鍵ごと開発者の秘密を持ち出した".
Lemma Critical Brief No.101. Lemma / FRAME00, Inc.
https://lemma.frame00.com/ja/critical/briefs/101-paysafe-fake-payment-sdk/