• 免責
• TL;DR - 対応指針
• 前提
• タイムライン
• 侵害の仕組み
  • 侵害の起点
  • 環境毎の動作差異
    • v4.87.1 の動作（バグっている）
    • v4.87.2 - Windows 環境での動作（うごく）
    • v4.87.2 - 非Windows環境での動作（うごく）
• 注目：LiteLLM 侵害との違い
• 対応指針
  • 1. バージョン確認
  • 2. アンインストールとキャッシュ削除
  • 3. バックドアの確認と除去
  • 4. クレデンシャルのローテーション
  • 5. さらなる被害の同定
• 推奨：自衛手段の整備
• IoCs
  • ネットワーク
  • パッケージそのもの
  • 永続化に関わるもの（Windows）

2026年3月27日、通信プラットフォーム Telnyx の PyPI パッケージが侵害されました。攻撃者は PyPI のメンテナアカウントを乗っ取り、マルウェアを含むバージョン 4.87.1 および 4.87.2 を公開しました。本記事では公開情報をもとに、事象の概要を記録します。また、対応指針を示します。

免責

本記事の目的は事態の把握と対応の促進であり、違法行為への加担・助長を意図するものではありません。 ペイロードの動作は手法の理解に必要な範囲で要約して記載しています。 記述の一部には不正確な情報が含まれている可能性があります。 速報性を優先していますので、ご了承ください。

TL;DR - 対応指針

• pip show telnyx によりインストール済バージョンを確認してください。
• 4.87.1 または 4.87.2 がインストール済の場合、マルウェア感染の可能性があります。
  • 但し筆者が確認できる限り、4.87.1 はバグっており、まともに動かないはずです。
  • 4.87.2 は動作するはずです。存在していれば、感染リスクは高いと思料します。
• 現時点では、感染した場合、漏洩データの範囲や端末内で行われた操作が同定困難です。
  • ワーストケースでは、端末内の全てのデータの漏洩を疑う必要があります。
  • LiteLLM 侵害よりも影響が不明瞭である、と理解ください。
• 影響を受けたバージョンをインストールしている場合は、
  • まずアンインストールしてください。
  • 端末内のクレデンシャルを即座にローテーション してください。
  • 極力エンドポイント内のログを確認し、他に起こり得た操作を追跡してください。
  • キャッシュからの再インストールを防ぐため、pip cache purge も実行してください。
  • 利用継続する場合、現時点で安全と思わしき 4.87.0 以前のバージョンにピン留めしてください。
• Windows 環境ではスタートアップフォルダ内に永続化バイナリが存在し得ます。削除ください。
  • %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe
  • %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe.lock
  • なお C2からドロップされたバイナリ経由で、他の永続化の可能性もあります。
• なお現在は PyPI 上では既に検疫モードで、前述の悪性バージョンをダウンロードできません。
• また 2026/03/27 20:05 JST 時点では、C2 サーバは応答していません。
  • 復活する可能性はあります。継続ウォッチします。

前提

今回の侵害は、脅威アクタ TeamPCP による3月中の一連のサプライチェーン攻撃の最新事例です。TeamPCP は3月19日の Trivy 侵害（CVE-2026-33634, CVSS 9.4）を皮切りに、LiteLLM 侵害等を含む連鎖的な攻撃を展開しています。 もう TeamPCP 系は勘弁してください。

タイムライン

以下に概略を示します。

いずれも GitHub 上に対応するタグやリリースは存在せず、PyPI への直接アップロードです。 LiteLLM と同様の手口ですね。

侵害の仕組み

侵害の起点、プラットフォームごとの侵害内容に分けて説明します。

侵害の起点

今回の侵害では、telnyx/_client.py に悪性コードが注入されています。

telnyx/_client.py は telnyx パッケージの __init__.py から読み込まれるコアモジュールです。 以下を実行すると悪性コードが実行されます。LiteLLM はもうちょっと深い階層が侵害されていたのですが・・・。

import telnyx

つまり、telnyx==4.87.1 または telnyx==4.87.2 をインストールした状態で Python コード中に import telnyx が一度でも実行されていれば、影響を受けた可能性があります。

環境毎の動作差異

v4.87.1 の動作（バグっている）

4.87.1 には Typo があり、動作しません。具体的には以下の位置で実行が失敗します。

$ python3 -c 'import telnyx'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/XXXXXX/telnyx/__init__.py", line 8, in <module>
    from ._client import Client, Stream, Telnyx, Timeout, Transport, AsyncClient, AsyncStream, AsyncTelnyx, RequestOptions
  File "/XXXXXX/telnyx/_client.py", line 7823, in <module>
    Setup()
    ^^^^^
NameError: name 'Setup' is not defined. Did you mean: 'setup'?

Vibe hacking すぎない？このバグは 4.87.2 で修正されます。差分は以下の通り。

-Setup()
+setup()

v4.87.2 - Windows 環境での動作（うごく）

Windows 環境では、以下の流れで動作します。

1. C2 サーバ 83[.]142[.]209[.]203:8080 から hangup.wav をダウンロード
2. WAV のオーディオフレーム内にペイロード（実行ファイル）が含まれるので、それを抽出
3. %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe（スタートアップフォルダ内）に配置
4. subprocess.Popen でバックグラウンド実行
5. その他、ログイン時にもサイレント実行

厳密にはこの他、 永続化パス/msbuild.exe.lock 隠しファイルに書かれる時刻データをもとに、最後の実行から43200秒（12時間）の間は C2 への通信を控えるような仕組みが実装されています。

v4.87.2 - 非Windows環境での動作（うごく）

その他環境では、以下の流れで動作します。

1. C2サーバ83[.]142[.]209[.]203:8080から ringtone.wav をダウンロード
2. WAV のオーディオフレーム内にペイロード（実行ファイル）が含まれるので、それを抽出
3. バイナリを実行し、結果（stdout）を取得
4. 内容を RSA + AES で暗号化
5. C2サーバ 83[.]142[.]209[.]203:8080 への HTTP POST でリーク

非Windows環境の方は、ただC2からデータを落としてきて実行するだけで、永続化の仕組みは含まれていません。

注目：LiteLLM 侵害との違い

明確な違いはPython パッケージ内の悪性コードが減り、メインロジックがC2から降ってくるバイナリに隠匿されるようになったことです。Python スクリプト側にはほぼ情報量がなく、感染時の影響範囲の調査が困難になっています。

筆者も検体の取得や調査を試みましたが、C2がほぼ応答しません。もう少し継続的に追います。続報あれば追記します。

対応指針

以下は公開情報を踏まえた参考情報であり、記録として示すものです。 正確性・網羅性を保証するものではなく、本指針に基づく対応の結果について筆者は一切の責任を負いません。 実際の対応は各組織の判断に基づいて行ってください。

1. バージョン確認

pip show telnyx 2>/dev/null | grep -i version

4.87.1 または 4.87.2 が表示された場合、以降の手順に進んでください。 それ以外のバージョンであれば、直接的な影響はありません。

2. アンインストールとキャッシュ削除

pip uninstall telnyx
pip cache purge

利用を継続する場合は telnyx==4.87.0 にピン留めしてください。

3. バックドアの確認と除去

Windows 環境では、スタートアップフォルダを確認してください。

# バックドアの存在確認
dir "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe*"

# 存在した場合の除去
del "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe"
del "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\msbuild.exe.lock"

また、C2 サーバー 83[.]142[.]209[.]203:8080 へのアウトバウンド HTTP 通信がないかネットワークログを確認してください。

4. クレデンシャルのローテーション

影響を受けたバージョンが import された可能性がある環境では、当該端末内のあらゆるクレデンシャルのローテーションを検討してください。

5. さらなる被害の同定

LiteLLM の侵害と異なり、今回はどのデータが漏洩対象だったかが定かではありません。被害は、そのタイミングにC2から降ってきたバイナリ次第で定まる、ということです。基本的に、感染エンドポイント内のデータは漏洩した可能性がある、と構えなくてはなりません。

仮にプロセスログ等が追える場合であって、非Windows環境の場合は、C2サーバー 83[.]142[.]209[.]203:8080 への接続後に再度 83[.]142[.]209[.]203:8080 への接続があるかを確認してください。ある場合は、データ漏洩までの攻撃フルパスが動作しているので、その間のログを極力追いましょう。（Windows 環境の場合に、よしなに調査する手段があるかは、私も少し調査しきれていません・・・）

推奨：自衛手段の整備

Trivy 侵害から始まった TeamPCP の連鎖攻撃は、CanisterWorm、Checkmarx、LiteLLM、そして今回の Telnyx へと波及しています。3月19日から1週間余りで5件以上のパッケージエコシステムが侵害されており、窃取済みクレデンシャルを起点にした攻撃は収束の兆しが見えません。 次にどのパッケージが狙われるかは予測できないため、可能な限りの自衛を推奨します。

前回の LiteLLM 侵害の記事でも紹介しましたが、筆者が所属する組織（GMO Flatt Security）から、セキュアなレジストリプロキシ Takumi Guard の PyPI エンドポイント をリリースしています。

Takumi Guard は pip/uv/poetry と PyPI（レジストリ）の間に位置するセキュリティプロキシで、悪意あるパッケージがブロックされます。我々で全ての新規パッケージを検査しています。 また、仮にある時点ではパッケージがマルウェアと判定できず、ブロックされなかった場合も、後日の通知を行う仕組みもあります。

加えて、72時間の検疫期間を設けています。新規公開バージョンが 72 時間はインストールできない仕組みです。TeamPCP による一連の侵害では、いずれも公開から数時間でテイクダウンされているため、この検疫だけでも今回のような攻撃の影響を受ける可能性を大きく低減できます。

導入は index URL の変更のみで完了します。必要に応じて利用を検討してください。

# pip
export PIP_INDEX_URL=https://pypi.flatt.tech/simple/

# uv
export UV_INDEX_URL=https://pypi.flatt.tech/simple/

# poetry
poetry source add --priority=primary takumi-guard https://pypi.flatt.tech/simple/

IoCs

筆者が把握できている限りでの、Indicators of Compromise（IoCs）を以下に示します。

ネットワーク

パッケージそのもの

永続化に関わるもの（Windows）