背景

Solidity Pro は、Solidity/Web3 開発者向けの VS Code 拡張機能であり、外部に対しては開発支援ツールとして位置づけられています。Gas クエリ、トークン価格、コードスニペット、コンパイルのヒントなどの機能を提供し、その GitHub リポジトリでは AI Audit や Security Scanner などのセキュリティ能力も宣伝していました。

公開イベントでは、Solidity Pro は helper-beeps と web3devtoolsx の 2 つの publisher（配信者）を順に使用しており、それぞれの Extension ID（拡張の一意識別子）は helper-beeps.solidity-pro と web3devtoolsx.solidity-pro でした。公開者の身元は変更されたものの、その後のビルド成果物の中に旧 publisher、リポジトリのアドレス、著作権情報が引き続き保持されており、両者の間に直接的な技術継承関係があることを示しています。

2026年8月6日から7日にかけて、これら2つのExtension IDはいずれもOpen VSXで使用される悪意拡張の制御リストに順次追加されました。本来、バージョンを後ろへ辿っていけば、当該の悪意能力も引き続き見えるはずです。しかし、今回取得したSolidity Pro 4.0.0（publisher：web3devtoolsx）は、まったく異なる結果を示しました。最終bundle（パッケージ化された実行コード）にはGas、トークン価格、ログなどの通常機能しか残っておらず、履歴の悪意バージョンで見られた認証情報収集、リモートローダーのダウンロード、サブプロセス実行、リモートVSIX更新の各モジュールはいずれも消失しています。

そこで問題はこうなりました：明確な悪意の履歴を持つプラグインが、なぜその後のバージョンで再び「クリーン」に見えるのか。

本稿では4.0.0から遡ってSolidity Proのバージョンと公開アイデンティティの変化を追跡し、2つの履歴における悪意バージョン、GitHubのClean commit、publisherの移行、および公開アクティビティのタイムラインを分析します。そのうえで、現在のバージョンだけに基づいてIDE拡張のリスクを判断すると検知に盲点が生じ得ることを議論します。

本稿の分析は静的証拠に基づいており、サンプルの実行や遠隔インフラへの接続は行っていません。

MistEyeの応答

MistEyeはSlowMistが自社開発したWeb3脅威インテリジェンスおよび動的セキュリティ監視プラットフォームで、セキュリティ監視とインテリジェンス集約の機能を統合し、ユーザーにリアルタイムのリスク警告と資産保護を提供します。

MistEyeは、helper-beeps.solidity-proとweb3devtoolsx.solidity-proという2つの公開アイデンティティおよび対応するサンプルの関連づけを行いました。静的なデコード（去混同）と、悪意能力の交差検証、そして公開プラットフォームのタイムラインを組み合わせることで、サンプルハッシュ、拡張ID、危険な要求パス、ならびにリモート更新挙動を抽出し、IDE拡張サプライチェーンのリスク事前警告に利用しています。

https://enterprise.misteye.io/threat-intelligence/SM-2026-905620

1、現在のバージョン

4.0.0がなぜ悪意コードにヒットしなかったのかを判断するには、2つの対象を同時に確認する必要があります。本稿で取得した4.0.0サンプルと、それとbundleが一致するGitHubリポジトリの状態です。

VSIXパッケージの中身：ローカルで再構築した4.0.0パッケージの最終bundleには、主にApiClient、GasTracker、PriceMonitor、Loggerが含まれ、ネットワークアクセスはEtherscanとCoinGeckoに集中しています。拡張がonStartupFinished、またはSolidityファイルを含むワークスペースで有効化された後は、Gas tracker、Price monitor、loggerのみを起動し、3つの公開コマンドを登録します。compileコマンドはHardhat/Foundryの案内メッセージを表示するだけで、コンパイラを実際に呼び出しません。確認済みのファイル、および静的に到達可能なパスの範囲で、履歴バージョンに見られた認証情報収集、リモートローダーのダウンロード、サブプロセス実行、リモートVSIX更新という4種類の悪意能力は見つかりませんでした。

GitHubリポジトリには他に何があるか。4.0.0パッケージ自体にはソースが含まれていないため、さらにGitHub上で公開工程を遡りました。リポジトリ内でpackage.jsonがv1.0.0へバージョン戻しされたコミット（commit 95dce4f、コミットメッセージは「Clean release」）があり、そのout/extension.jsと4.0.0のbundleはいずれも10,633バイトで、SHA-256が一致しています。

このコミットのout/extension.jsにも同様にApiClient、GasTracker、PriceMonitor、Loggerしか含まれておらず、有効化・無効化の関数は初期化とクリーンアップのみを行います。しかし同じコミットのsrc/ディレクトリの中身は別の様相です：src/telemetry/Web3Analytics.ts は依然として存在し、ファイルヘッダには「Sends install ping immediately, then scans for secrets」と書かれています。内部にはBIP39の語彙表、ウォレット認証情報の識別、WORKERSへの外部転送設定、大規模ファイル収集の上限などが含まれています。さらにsrc/services/AutoUpdater.tsも同様に保持されており、30分周期のバージョンチェックとリモートVSIXインストールのロジックが定義されています。

GitHubリポジトリ（Clean commit 95dce4f）
├── src/telemetry/Web3Analytics.ts # 悪意のある収集工程のソースコードは依然として残っている
├── src/services/AutoUpdater.ts # リモートVSIX更新のソースは依然として残っている
├── .vscodeignore # src/**、scripts/**、*.ts を除外
└── out/extension.js # パッケージ化時に見えるクリーンなbundle

なぜ悪意のあるソースがVSIXパッケージに入らなかったのか？ここには2つの境界があります。

1つ目は実行入口です：Clean commitのsrc/extension.tsはWeb3AnalyticsとAutoUpdaterに対するimportおよび起動ロジックを削除しており、esbuildがこの入口から依存関係のグラフを構築する際、これら2つのモジュールをout/extension.jsに組み込みません。

2つ目はパッケージ内可視性です：.vscodeignoreはsrc/**、scripts/**、および*.tsを除外しますが、out/**は保持するため、同設定で生成されるVSIXには残ってもTypeScriptのソースは元のソース形式では入りません。v1.0.0のコミット情報は「Clean release」と書かれていますが、悪意のあるモジュールのソースファイルはこのコミットで削除または変更されていません——最終成果物はクリーンになっていますが、プロジェクト内部の悪意モジュールは、以後のソースやビルド設定の変更で再び組み込まれる余地が残っています。

悪意のあるモジュールのソースコードがリポジトリ内に残っており、.vscodeignoreによって、この設定に基づいて生成されるVSIXの外に除外されています

2、過去の悪意あるバージョン

現行バージョンもClean commitのbundleも元の悪意モジュールを見つけられなかった以上、調査は継続し、Solidity Proが2つの公開アイデンティティの下で登場した履歴バージョンを追跡する必要があります。

Solidity Proは常に同じ悪意の実装を使っているわけではありません。helper-beepsの公開アイデンティティで取得された2.4.1と、web3devtoolsxの公開アイデンティティで取得された3.4.0は、明らかに異なる2系統の実行方法を示しています。前者は遅延ダウンロードとリモートコード実行を中心に、後者は組み込みの認証情報収集とリモート更新チャネルを中心にしています。

2.4.1：遅延投機（遅延デリバリー）

本稿で取得したSolidity Pro 2.4.1サンプル（publisher：helper-beeps）では、拡張がSolidityファイル、またはHardhat/Foundryのワークスペース内で有効化され、telemetryはデフォルトで有効です。起動後、コードはすぐにダウンロード段階へ進むのではなく、24〜48時間のランダムな待機ウィンドウが設定されます：

MIN_DELAY_MS: 86400000,
MAX_DELAY_MS: 172800000

待機が終了すると、コードはCI、GITHUB_ACTIONS、JENKINS_HOME、GITPOD_WORKSPACE_IDなどの環境変数に対して存在性の判定を行い、該当すれば即終了します。その後、6つのエンコードされたホームディレクトリの相対パスを順にfs.existsSyncでフィルタします。これらのパスはこの段階では存在性のふるい分けのみに使われます。

フィルタ後、コードは2つのエンコードされたエンドポイントを順に試し、各エンドポイントに固定パス /firmware を要求します。応答を受け取ったら長さを検証し、crypto.createDecipherivでAES-GCMにより復号します。復号テキストは権限を制限した状態で一時ディレクトリの .py ファイルへ書き込み、その後child_process.spawnをdetached方式で実行します。約60秒後にunlinkSyncで一時ファイルを削除します。/firmwareの実際の応答が取れなかったため、2段階目の具体的な機能は不明です。

ローカルのランダム遅延、環境フィルタ、遠隔の暗号文取得、復号とPythonサブプロセス実行の連鎖

3.4.0：認証情報の収集

Solidity Pro 3.4.0（publisher: web3devtoolsx）のpackage.jsonのactivationEventsは、workspaceContains:*.sol と onStartupFinished を同時に宣言しています。拡張はVS Codeの起動完了後に自動でactivate()へ入り、ユーザーが公開コマンドを実行する必要はありません。

デフォルト設定 solority-pro.telemetry.enabled=true はWeb3Analyticsを作成し起動します。READMEでは匿名の利用データのみを収集し、private keyやソースは保存しないとしていますが、このモジュールが実際にスキャンする対象は、開発者の信頼領域のコア資産をカバーしています：

  • ウォレットと署名の素材：EVM秘密鍵、BIP39メニモニック、keystore、Solana id.json、ブラウザウォレット拡張データ（MetaMask、Phantom、Coinbase Wallet、Rabby）。

  • ソースコードと公開の証憑：GitHub ghp_/gho_/github_pat_トークン、GitLab glpat-、.npmrc、PyPIトークン、.netrc、Gitの認証情報。

  • クラウドとインフラ：AWS access/secret/session key、Kubernetes設定、Docker認証、Azure、GCP設定。

  • プロジェクトと操作の痕跡：.envおよびその変種、API key、AIサービストークン（sk-、sk-proj-、sk-ant-）、Shellの履歴とホスト情報。

EVM秘密鍵の正規表現が、privateKey、PRIVATE_KEY、WALLET_KEY、DEPLOYER_KEYなどの一般的な変数名と、64ビットの16進値をカバーしています：

var _0x4e0bcc = [
  /["']privateKey["']\s*:\s*["'](?:0x)?([0-9a-fA-F]{64})["']/g,
  /(?:PRIVATE_KEY|PRIVATEKEY|ETH_KEY|ETHKEY|WALLET_KEY|WALLETKEY|DEPLOYER_KEY|OWNER_KEY)\s*=\s*["']?(?:0x)?([0-9a-fA-F]{64})["']?/gi,
  /(?:privateKey|private_key|ethKey|eth_key|walletKey|wallet_key)\s*[:=]\s*["'](?:0x)?([0-9a-fA-F]{64})["']/gi,
  /(?:priv(?:ate)?[ _-]?key|secret)[:=]\s*["']?(0x[0-9a-fA-F]{64})["']?/gi
];

SSHディレクトリ収集ロジックは、~/.ssh/ 内の候補となる秘密鍵ファイルを列挙し、内容を読み取ってextractSecrets抽出器に渡します。収集結果は2つのHTTP要求パスで外部へ送信されます：テキストJSONはHTTPS経由で難読化されたCFG.WORKERSホストへPOST /x、完全なレポートはmultipart/form-dataとして同じホストへPOST /y。

この収集チェーンと並行して動くのはAutoUpdaterです。これはactivate()の中で条件なく作成され起動され、telemetry設定には依存しません。起動後すぐに1回 /version を要求し、その後は30分ごとに2つのハードコードされたWorkerをポーリングします。応答にversionとurlが含まれていれば、コードはバージョン番号を照合し、VSIXをダウンロードしてVS Codeのインストールコマンドを呼び出し、最後に一時ファイルを削除します。

更新チェーン全体に完全性（インテグリティ）の検証は一切ありません。更新器自体がハッシュ、署名、publisher、証明書を固定する仕組みを実装していないためです。つまり、サーバー側は任意のポーリングのタイミングで、より高いバージョンとダウンロードアドレスを返し、いつ更新をトリガーし、どのVSIXを配送するかを自分で決められます。さらに重要なのは、更新前に「OK」ボタンしかない通知が1つ表示されるだけで、通知フローが終わるとそのままインストールを継続する点です。本当のキャンセル選択肢がなく、ユーザーの選択結果も読み取りません。

この種の収集対象が危険なのは、IDE Extension Host自体が開発者の信頼領域の内部にあるためです。Web3開発用マシンには、多くの場合、ウォレットの素材、ソースコードリポジトリの認証情報、パッケージ公開トークン、CI/CD、クラウドプラットフォーム設定が同時に保存されています。1つの拡張サプライチェーン攻撃は、複数のセキュリティ境界を同時に跨ぐ可能性があります。

4種類のサンプルまたはバージョンの役割の対応表：

拡張起動後に自動でトリガーされる認証情報収集、/x と /y の外伝、および独立実行のリモートVSIX更新チャネル

3、publisherの移行

Solidity Proの2.4.1と3.4.0は同じExtension IDではありません。前者はhelper-beepsが公開し、後者は新しいpublisher web3devtoolsxを使用しています。なぜそれらを同じ調査ラインに載せられるのか？

初期のv3.4.0コミット fe794a2 の内部メタデータが、この問いへの直接の答えになっています。package.jsonはpublisher: web3devtoolsx、バージョン3.4.0を宣言し、repositoryはgithub.com/web3devtoolsx/solidity-proを指しています。同じコミットのout/package.jsonではpublisher: helper-beeps、バージョン3.3.0、repositoryはgithub.com/helper-beeps/solidity-proのままになっています。LICENSEファイルはいまも「Copyright (c) 2026 Helper Beeps」と書かれています。

2つのpackage.jsonは同一のコミットに由来しており、Solidity Proがweb3devtoolsxというアイデンティティの下で作った初期ビルド成果物が、helper-beepsの工程から直接生成されていることを示しています。コードまたはビルド成果物に直接的な出所の関連が存在します。

ビルド成果物の継承関係と、公式の悪意タグのタイムラインを重ねると、publisherのローテーション・パターンがより明確になります：

helper-beeps.solidity-proが公式のmaliciousリストに追加されました（2026-08-06 14:27:24 UTC）
    │ 8時間32分48秒
    ▼
web3devtoolsxのGitHubアカウント作成（2026-08-06 23:00:12 UTC）
    │ 約16分
    ▼
新しいSolidity Pro v3.4.0が登場
    │ 翌日
    ▼
web3devtoolsx.solidity-proも公式のmaliciousリストに追加されました（2026-08-07 12:38:52 UTC）

初回コミットには、旧publisher、バージョン、リポジトリのアドレス、著作権の残存が示す直接の出所関連がある

4、Clean release

GitHubの初回commitで悪意のあるv3.4.0のbundleを送ったのは、わずか13分29秒後に過ぎません。同じリポジトリには、バージョンをv1.0.0へ戻したClean commitも行われています。この超短い時間窓の間に、publisherはOpen VSXのnamespace claimを一時的に開始し、自ら閉じています（issueはコメントなしで、web3devtoolsx本人がクローズ）。

Clean commitの変更は、2種類のターゲットに正確に集中しています。実行面ではWeb3Analyticsの有効化、AutoUpdaterの起動、telemetry設定、javascript-obfuscator依存関係、難読化ビルド手順を削除しました。製品表面ではAI Audit Engine、Security Scanner、100K+バッジ、誇張した能力に関する文言を削除しました。バージョン番号は3.4.0から1.0.0へ後退しています。

これらの変更はすべて、名称が「Clean release」とされている同一コミット内に集中しています。これは、公開的に到達可能な高リスク入口と、一部の目立つマーケティング文言を直接削除し、新しいbundleだけをチェックするシステムが元の悪意モジュールにヒットしなくなるようにしています。清掃は完全ではありません：package.jsonのdescriptionにある「Trusted by 100K+」や「vulnerability scanner」の表現は削除されていません——最も目立つバッジは削除されていますが、もしこのmanifestが実際にビルドされて公開されていれば、検索結果やストアページのメタデータに影響し得る情報が残ります。先述の通り、悪意のあるソースはsrc/ディレクトリに完全に保持されており、ただし.vscodeignoreによって最終パッケージに入らないだけです。

Clean releaseで変わるのは最終的な納品物であり、この工程にすでに起きていた履歴ではありません。

5、信頼性の“包装”

バージョンの変化とほぼ同時に起きたのは、新しい公開アイデンティティによる素早い“包装”です。web3devtoolsxアカウント作成後、約16分以内に、企業風のプロフィール資料、6つの著名プロジェクトのfork、プロダクトのリポジトリ、成熟したバージョン番号、100K+の主張が一斉に集中して出現しました。これらのシグナルが短時間で集中して現れることは、客観的に新規アカウントが成熟した組織の外観を持って見えることにつながります。

企業風のプロフィール資料。アカウント作成から約15分後、Profileには「Web3 Dev Tools」という名称、companyフィールド、Zug所在地、公式サイト、Twitterリンク、公開済みの1つの製品、そして2つの「Coming Q3」製品ロードマップが含まれていました。2026年8月12日までに再確認したところ、followers、following、gistsなどの長期的な活動指標はいずれも0のままでした。

6つの著名プロジェクトのfork。アカウントは13秒以内に、OpenZeppelin Contracts、Foundry、Hardhat、Chainlink、Uniswap v3-core、ethers.jsを連続でforkしています。一般の閲覧者はホームページで馴染みのWeb3プロジェクト名を目にしますが、forkは上流リポジトリのコピーを意味するだけで、貢献、協力、またはあらゆる形式の裏付け（保証）を必ずしも示しません。

标题: fig:

バージョン・タグと作成日時が一致していません。リポジトリ作成から8秒後に行われた初回コミットには、v2.4.1、v2.4.5、v3.2.3、v3.3.0、v3.4.0の5セットのバージョン・タグが同時に付与されており、ソースの先頭には2025年に初めてリリースされたとも記載されています。これらのバージョンと年齢タグは、アカウントおよび当日に作成された公開履歴とは明らかに一致していません。

社会的証明の反復強化。「100K+」がrepository description、package.json、out/package.json、READMEバッジ、README本文、そしてビルド出力のすべてに同時に現れており、プロジェクトの公開情報においてユーザー規模の主張が繰り返し強調されていることが分かります。現存資料だけでは、この数字の真偽を独立して検証できませんが、この種の表現は成熟したバージョン番号、企業化されたProfile、そして著名プロジェクトのforkと同様に、Solidity Proの対外的な“成熟した製品イメージ”を構成しています。

标题: fig:

これらの宣伝文言は、前文で確認済みの実際のコード挙動と明確に矛盾しています。READMEではprivate keyやソースコードを保存しないとしていますが、設定ではtelemetryを匿名の利用データとして扱うと説明しています。さらにビルドスクリプトでは、javascript-obfuscatorの難読化プロセスを「privacy」と呼んでいます。製品はAI監査、脆弱性スキャン、リ・エントリー（再入）検出をうたっていますが、公開コマンドは主にGasの照会、トークン価格の表示、そしてHardhat/Foundryでコンパイルするための案内メッセージ1つにとどまります。

組織情報、有名なfork、成熟したバージョン番号、100K+、実際に使える小機能、プライバシー説明などは、閲覧者の拡張に対する初期判断に影響します。各要素を単独で見ると正常に見える場合もありますが、異常なのは、これらのシグナルが悪意コード、短いタイムライン、旧publisherのビルド残骸と同時に現れる点です。

6、単一バージョン検知の盲点

悪意のコードは削除できても、バージョン履歴、公開アイデンティティ、そして工程（エンジン）の出所は自動的にゼロにはなりません。

最初の5章の発見をまとめると、Solidity Proにはプラットフォームやセキュリティ製品が重視すべきパターンが見えてきます。すでに明確に悪意の履歴と関連づけられている拡張名とpublisherがあり、悪意の能力を未検知にする新バージョンを公開することで、現在のビルドだけをチェックする検知は、再びcleanや未ヒット／低リスクの結果を返してしまう可能性があります。

この種のパターンと通常のセキュリティ修正を区別するには、新しいコードがクリーンかどうかだけに頼ってはいけません。4つの層で問題を同時に照合する必要があります：

  • ハッシュと現在のbundleへの回答：このファイルには今、何が含まれているのか。

  • バージョン履歴への回答：この拡張IDまたはpublisherは、それ以前に何を納品していたのか。

  • publisherとコードの出所への回答：現在のパッケージは、どの既知の悪意ある案件と直接的に結び付いているのか。

  • 現在のリモート制御面への回答：現在のローカルコード、または履歴バージョンは、サーバーが納品内容を変更することを許可しているのか。

拡張市場とセキュリティ製品の観点では、これは検知対象が「単一ファイルのハッシュ」から、バージョン履歴、publisherの変更、ビルド成果物の差異、そしてリモート制御の側面まで拡張される必要があることを意味します：

  • 履歴バージョンのハッシュと復号（デコード）結果を保存する。新バージョンが大量の危険モジュールを削除する場合、差異審査をトリガーすべきであって、信頼性を自動復元してはなりません。

  • 旧publisherの残留、コードの類似度、ビルドスクリプトを関連付け、コードまたはビルド成果物の出所関連を構築する。

  • 周期的な/versionチェック、遠隔URL、一時VSIXインストール記録をランタイム監視に組み込む。

  • ダウンロード数、stars、企業風Profileは文脈としてのみ扱い、安全な裏付けとしては扱わない。

まとめ

Solidity Proには、helper-beepsとweb3devtoolsxという2つの公開アイデンティティの下で、いずれも明確な悪意の実装が存在します。2.4.1は、ローカルでのランダムな遅延と環境フィルタを前提条件として、遠隔から暗号化されたPythonをダウンロードして実行します。3.4.0は、VS Codeの起動後に自動で認証情報収集をトリガーし、/x と /y の2つのHTTP要求パスを通じて外部に流出させると同時に、遠隔応答に駆動されるVSIX更新チャネルも維持します。初期の3.4.0のout/package.json、repository、著作権情報はいずれもhelper-beepsを指しており、2つの公開アイデンティティのビルド成果物に直接の出所関連があることを示しています。

GitHubのClean commitの最終bundleでは、これらの悪意モジュールは削除されていますが、リポジトリは依然として悪意のあるモジュールのソースファイルを保持しています。ローカルで再構築した4.0.0パッケージでも、元の悪意モジュールは見つかりませんでした。悪意の入口と構築物を含む初期コミットからClean commitまでの間隔はわずか13分29秒で、企業風のプロフィール資料、6つの著名fork、プロダクトのリポジトリ、成熟したバージョン宣言は、アカウント作成後約16分以内に集中して現れました。

このケースが最終的に示すのは次のことです：現在のファイル、または現在のバージョンだけで拡張のリスクを判断しても、到底不十分です。悪意のあるコードは最新のbundleから消えることがありますが、過去に記録された悪意はそれによって無効にはなりません——同じ名前とpublisherで以前に悪意のあるコードを納品していた事実を、クリーンな新バージョンで消し去ることはできません。

推奨

  1. helper-beeps.solidity-pro または web3devtoolsx.solidity-pro をインストールした開発者は、まずネットワークを隔離し、拡張ディレクトリ、インストールパッケージのコピー、プロセス、ネットワークログを保持したうえで、該当バージョンを無効化してアンインストールしてください。その後、VS Codeのプロセスツリー、一時ディレクトリ内のPythonファイル、異常なVSIXインストール記録、ならびにプロキシログ内の /firmware、/x、/y、/version リクエストを確認します。

  2. Solidity Pro 3.4.0（publisher：web3devtoolsx）を実行したことがある場合、ウォレットの秘密鍵、メニモニック、GitHub/GitLab/npm/PyPI/AWS/Cloudflare/AIサービスおよびCI/CDトークンが漏洩している可能性があります。関連する認証情報は、クリーンな端末から優先的に取り消すかローテーションしてください。暗号資産は新しいseedまたは秘密鍵を使うウォレットへ移し、元のウォレットのパスワードを変更するだけでは不十分です。

  3. Solidity Pro 2.4.1（publisher：helper-beeps）を実行したことがある場合、ホストが当該サンプルの遅延ウィンドウを跨いだ可能性、または実稼働時間が確認できないなら、潜在的なローカルコード実行イベントとして調査を行うべきです。

  4. 企業のセキュリティチームは、まずExtension ID、危険な要求パス、既知のWorker、一時ファイル、異常なプロセスツリーを優先的に検索し、その後、2つのサンプルSHA-256、拡張のインストール時刻、そしてVS Codeプロセスのネットワーク記録を組み合わせて影響範囲を確定してください。重点検知は、VS Code Extension Hostがdetached Pythonを起動し、一時パスからVSIXをインストールし、高価値の設定を読み取った後にmultipart HTTPSを開始する、といった行動の組み合わせです。

  5. 拡張市場では、デフォルトのtelemetry内に、認証情報の読み取り、リモートダウンロード、復号実行、または公式チャネルを迂回してVSIXをインストールする能力が含まれている場合、強制的に人手による監査を行うべきです。過去バージョンを保持し、バージョン間の差異審査も実施して、以後の未検知の悪意コードが自動的に旧バージョンのリスクラベルをクリアしてしまうリスクを避けてください。

IOC

悪意のあるファイル


filename: helper-beeps.solidity-pro-2.4.1.tar.gz 

SHA256: 7b53b1d93f46babc7415d898e17e71ffb6f3a3af3adb222f21c03adea8b30d50
filename: web3devtoolsx.solidity-pro-3.4.0.gz 

SHA256: bcbaf774f9cea0b0131859b96ba0eeadfd5a49bba59302de1bcf3d884300d508

MistEyeについて

MistEyeはSlowMistが独自に開発したWeb3脅威インテリジェンスおよび動的セキュリティ監視プラットフォームで、APIを通じてオープンソースパッケージのエコシステムにおける悪意のある活動の検知や、サプライチェーンリスクの事前警告を提供します。


今回関与したすべての悪意あるパッケージおよびIOCは、MistEyeの脅威検知エンジンに接続済みです。開発者はAPIを通じてプロジェクトの依存関係を自動検知でき、既知の悪意あるパッケージにヒットしているかを迅速に判断し、対処の提案を得られます。


📖 APIドキュメント：https://app.misteye.io/api-docs


🛠️ MistEye-DepScan：https://github.com/slowmist/MistEye-DepScan軽量級CLIツールで、1行のコマンドでプロジェクトの依存関係と、グローバルにインストールされたパッケージ内の既知の悪意あるパッケージをスキャンします。npm / PyPI / Rust（Cargo）/ Go / RubyGemsのエコシステムに対応


🛠️ MistEye-Skills：https://github.com/slowmist/misteye-skillsAIコード作成アシスタントのセキュリティスキルパックで、依存関係のインストールやURLアクセスの前に自動でMistEyeのセキュリティ検知をトリガーします


🛠️ MistEye-DNS-Guard：https://github.com/slowmist/MistEye-DNS-GuardRustで実装されたローカルDNSリレーで、悪意のあるドメインやリスクのあるアクセスを検知し、フィッシング、C2などのネットワーク脅威を識別します。


本稿はSlowMistの脅威インテリジェンスタイムが、MistEyeの脅威インテリジェンスプラットフォームと、SlowMist Agent AI主導の分析を組み合わせて作成しました。不明点や質問があれば、ぜひお問い合わせ・フィードバックしてください。


参考リンク：

[1] https://yeethsecurity.com/blog/2026-08-06-Solidity-Pro-WhiteCobra-C2-to-Telegram