AIモデルの危険コード検査ツール「picklescan」に検出回避の脆弱性8件 CVE-2026-3490ほか、v1.0.4へ即更新を

配布されたAIモデルに危険なコードが仕込まれていないかを調べる検査ツールpicklescan（ピクルスキャン）に、検査そのものをすり抜けられる脆弱性が立て続けに8件見つかりました。最も深刻なCVE-2026-3490は、深刻度を10点満点で表すスコア（CVSS）が満点の10.0です。いずれも、picklescanが「問題なし（安全）」と表示したモデルでも、読み込んだ瞬間にパソコンやサーバーで攻撃者のコードが実行されてしまう、という種類の欠陥です。

picklescanは、Hugging Face（ハギングフェイス）という世界最大のAIモデル配布サイトが、アップロードされたモデルの自動検査に使っている定番ツールです。つまり今回の欠陥は、世界中のAIエンジニアが「安全のお墨付き」として頼ってきた検査の網に、まとめて穴が空いた状態を意味します。修正はすべて最新のpicklescan 1.0.4で入っており、利用者は直ちに更新する必要があります。

この記事では、picklescanが何を守るツールなのか、なぜ8件もの「検出回避」が成立してしまったのか、そして開発者がいま何をすればいいのかを、できるだけわかりやすく整理します。あわせて、検査ツールが何度も破られ続ける構造的な理由と、より安全なモデルの扱い方までまとめます。

picklescanとは何か。AIモデルの「危険コード検査ツール」

話を理解するには、まず「pickle（ピクル）」という仕組みを押さえる必要があります。pickleはPythonに標準で備わった、データやプログラムの状態をファイルに保存・復元するための形式です。便利な一方で、復元（読み込み）するだけで中に書かれた命令を実行してしまうという性質を最初から持っています。これはバグではなく、pickleの設計そのものです。

そして、AIの分野で広く使われるPyTorch（パイトーチ）の標準的なモデル保存形式は、この危険なpickleを使っています。torch.load()でモデルを読み込むと、中にコードが仕込まれていればそのまま動いてしまうのです。Hugging Faceには誰でもモデルをアップロードでき、それを他の人が気軽にダウンロードして読み込みます。ここに「悪意あるモデルを置いて、ダウンロードした人のマシンを乗っ取る」攻撃の余地が生まれます。

picklescanは、その危険を事前に防ぐための検査ツールです。pickleファイルの中身を解析し、os.systemやexecのような「危険な関数」が呼び出されていないかを照合し、見つかれば「危険（Dangerous）」と警告します。Hugging Faceは、アップロードされた全モデルをサーバー側でpicklescanにかけ、ProtectAIやClamAVといった他のツールと組み合わせて検査しています。守る側のツールが破られる構図はこれまでも繰り返し報じてきましたが、今回はAIモデルの安全を担う最前線のツールが対象です。

問題は、picklescanの検査が「危険な関数の名簿（ブロックリスト）と照らし合わせる」方式だという点です。名簿に載っていない関数を使われると、危険を見逃します。今回見つかった8件は、いずれもこの名簿の穴を突くものでした。

「安全」と表示されたモデルを、誰が、何のために用意するのか

この穴が刺さる相手は、ネット上に出回る学習済みモデルを「安全なもの」としてあなたの開発環境に届けられる立場の人間です。そこに立てるのは、人気モデルの名前を一文字だけ変えて置いておく出品者、評価の高いモデルを少しだけ改造して「高速版」「日本語対応版」と称して配り直す者、社内で共有されるモデルファイルに手を入れられる内部の協力者です。共通するのは、あなたにコードを書かせる必要も、怪しいリンクを踏ませる必要もないこと。便利そうなモデルを自分から探して取り込む、そのいつもどおりの作業だけで成立してしまいます。

彼らの狙いは派手な破壊ではなく、モデルを読み込んだその瞬間に、開発者の手元にある鍵を静かに持ち出すことです。モデルをtorch.load()で開くと、ファイルに仕込まれたコードがその場で動き、Hugging FaceやOpenAIのAPIキー、AWS・GCPのクラウド認証情報、GPUサーバーへのログイン、まだ公開していない学習データやモデルそのものを読み取って外へ送り出します。picklescanが緑色の「安全」を出したあとに起きるため、踏んだ本人に「いま何かを実行した」という手応えはまったく残りません。本番の推論サーバーほど強いクラウド権限と社内データへの近さを持っているので、そこで動く一つのモデルを汚染できたときの見返りは大きくなります。

後始末を負うのは、そのモデルを取り込んだ開発者と、その人が属する組織です。盗まれた鍵で別のサーバーやデータにまで手を広げられれば、被害は一台では終わりません。漏れた認証情報の総入れ替え、汚染されたモデルの洗い出し、そのモデルを組み込んで世に出したAIサービスの利用者への影響調査まで、長い後始末が続きます。さらに重いのは、「検査済みだから安全」という前提そのものが崩れることで、過去に同じ判断で取り込んだモデルを、もう一度すべて疑い直す羽目になります。だからこそ根本的な対処は、検査をすり抜けられたかどうかを気にせずに済むファイル形式（safetensors）へ移し、picklescan自体もv1.0.4へ上げておくことに行き着きます。まずは、その8件で具体的に何が起きているのかから順に見ていきます。

何が起きるのか。検査は「安全」、でもコードは動く

今回の8件は、攻撃の手口こそ違いますが、結果はどれも同じです。攻撃者が細工したpickleファイル（=AIモデル）を、picklescanが「危険な関数は見つからなかった」と判定する。ところが実際にPyTorchで読み込むと、攻撃者の仕込んだコードが実行される。検査の結果と現実の挙動がズレているのが共通点です。

手口は大きく二つに分かれます。一つは、危険な処理を名簿に載っていない別の関数で代用するやり方です。picklescanはos.systemなどを名簿で見張っていますが、同じことを実現できる「見張られていない関数」はPythonの標準ライブラリの中にいくつも存在します。攻撃者はそちらを使うだけで網をすり抜けます。もう一つは、picklescanの解析プログラム自体のバグを突いて、検査を途中で混乱させたり止めたりするやり方です。検査がエラーで止まる一方、PyTorchはファイルを問題なく読み込んでしまうため、危険が素通りします。

以下では、れいな（CVE自動検知）が拾った8件を、深刻度の高い順に一つずつ見ていきます。技術的な分類（CWE）と修正版もあわせて示します。

修正版がバラバラに見えますが、最新の1.0.4へ更新すれば8件すべてが塞がります。古い版（0.0.27や0.0.33）で個別に直すより、最新版にそろえるのが確実です。

見つかった8つの脆弱性

CVE-2026-3490：名前から任意の関数を呼び出す「万能回避」（CVSS 10.0）

8件のなかで最も深刻な、満点10.0の脆弱性です。Pythonにはpkgutil.resolve_nameという、文字列で指定した名前（例：os:system）から、対応する関数を実行時に取り出す標準機能があります。攻撃者はこれを最初に呼び出すだけで、危険な関数を名簿に一切その名前を登場させずに手に入れられます。picklescanの名簿に何が載っていようと無関係に回避できるため「万能回避（ユニバーサル・バイパス）」と呼ばれます。技術解析やRAXE Labsの報告（GHSA-vvpj-8cmc-gx39）が公開されており、修正は1.0.4で入りました。名簿方式の限界を最も象徴する一件です。

CVE-2026-53873：プロファイラ経由でコードを走らせる（CVSS 9.8）

プログラムの実行速度を計測する標準モジュールprofileには、与えた文字列をそのまま実行するprofile.run()という関数があります。picklescanの名簿はこの「モジュール直下のprofile.run()」を見落としており、攻撃者はここからexec()相当の処理を呼び出して任意コードを実行できました（NVD、CWE-184）。修正は1.0.4。

CVE-2026-53874：getattrの陰にevalを隠す（CVSS 9.8）

危険な処理を「呼び出し可能なオブジェクト」の下にgetattrで包んで入れ子にすることで、危険なevalの呼び出しを検査の目から隠す手口です。pickleファイルの中では検出されず、読み込み時に初めて実行されます（NVD、CWE-502）。修正は1.0.1。

CVE-2025-71320：pydoc.locateとoperator.methodcaller（CVSS 9.8）

名簿に載っていなかったpydoc.locateとoperator.methodcallerという2つの関数を悪用して、安全確認をすり抜ける脆弱性です（NVD、CWE-184）。これらも名前から別の関数を引き出す道具で、CVE-2026-3490と同系統の発想です。修正は0.0.33。

CVE-2025-71321：ファイルを勝手に書き換える（CVSS 9.8）

名簿がdistutils.file_util.write_fileを見張っていなかったため、攻撃者がシステム上の任意のファイルを上書きできた脆弱性です（NVD、CWE-502）。設定ファイルや起動スクリプトを書き換えられれば、サービス停止やコード実行に直結します。修正は0.0.33。

CVE-2025-71323：ctypesでOSを直接たたく（CVSS 9.8）

ctypesは、PythonからOSの低レベルな機能を直接呼び出せる標準モジュールです。これが名簿に入っていなかったため、攻撃者はctypes.WinDLLでWindowsの中核ファイル（kernel32.dll）を読み込み、システムを直接操作できました（NVD、CWE-184）。検査の網を最も深いところで回避する手口です。修正は0.0.33。

CVE-2025-71325：解析プログラムのバグを突く（CVSS 9.8）

危険な関数を別名で持ち込むのではなく、picklescanの解析プログラムそのもののバグを突いた一件です。pickleの内部命令（STACK_GLOBALオペコード）の読み取り位置を正しく追えない欠陥があり、攻撃者が命令の引数を細工すると検査が混乱し、危険を見逃しました（NVD、CWE-391）。修正は0.0.27。

CVE-2025-71322：pty.spawnでコマンド実行（CVSS 8.8）

名簿に含まれていなかったpty.spawnを使って任意コマンドを実行する脆弱性です（NVD、CWE-693）。8件のなかでは深刻度がやや低い8.8ですが、結局はコード実行に至る点で危険度は高いままです。修正は0.0.33。

なお、これらと同じ波では、uuidやimaplibなど、ほかにも複数の標準モジュールが名簿から漏れていたことがpicklescanの公式アドバイザリ一覧で報告されています。穴は1つや2つではなく、名簿方式の構造そのものに由来する、という見方が裏付けられた形です。

なぜ何度も破られるのか。名簿方式の限界

実は、picklescanが破られたのは今回が初めてではありません。むしろ「破られては直す」を繰り返してきた歴史があります。2025年にはセキュリティ企業のSonatypeやJFrogが相次いで回避手口を公表しており、今回の8件はその延長線上にあります。時系列で振り返ります。

← スワイプで移動

なぜ同じツールが何度も破られるのか。理由は、picklescanの検査が「危険なものの名簿（ブロックリスト）」に頼っているからです。名簿方式は、危険な関数を一つひとつ列挙して見張る方式ですが、Pythonの標準ライブラリには「同じ危険を別の名前で実現できる関数」が無数にあります。一つ塞いでも、攻撃者は次の見落とされた関数を探すだけ。RAXE Labsの報告も「名簿方式は、保存データの解析には構造的に不完全だ」と指摘しています。いたちごっこが構造的に終わらないのです。

この「守る側のツール自体が攻撃面になる」構図は、picklescanに限りません。当ブログでもセキュリティスキャナーTrivyが繰り返し侵害された件や、Trivyから始まった連鎖的サプライチェーン攻撃を追ってきました。安全を担保するはずの仕組みほど、信頼されているがゆえに破られた時の被害が大きくなります。

いますぐやるべき対策

対策は「とりあえずpicklescanを最新にする」だけでは足りません。検査をすり抜けられた以上、過去の判定そのものを信じ直す必要があります。優先順に整理します。

1. picklescanを1.0.4以降へ更新する。 pip install --upgrade picklescanで最新版にします。CIやコンテナで自動導入している場合は、固定しているバージョンが古いままになっていないか確認してください。これで今回の8件はすべて塞がります。

2. 古い版で「安全」と判定したモデルを再評価する。 修正前のpicklescanで検査を通して取り込んだモデルは、本当は危険だった可能性があります。とくに信頼できない配布元から落としたPyTorchモデルは、最新版で検査し直すか、扱いを見直してください。「過去に安全と出たから大丈夫」という前提は、今回でいったん崩れています。

3. より安全なモデル形式（safetensors）へ移行する。 根本的な解決は、コードを実行できてしまうpickle形式そのものから離れることです。Hugging Faceが開発したsafetensorsは、数値データだけを保存しコードを実行する余地がない形式で、ONNXも同様です。可能な限りこうした形式で配布・読み込みを行えば、検査をすり抜けられる心配自体がなくなります。検査に頼るより、危険な仕組みを使わないことが最も確実です。

4. 多層防御で「検査をすり抜けられた前提」に備える。 モデルの読み込みは、ネットワークを遮断した使い捨ての環境（サンドボックス）で行う、本番サーバーには余計なクラウド権限を持たせない、といった備えが有効です。検査は防御の一枚目にすぎず、それ一つに頼らない設計が重要です。汚染されやすい依存関係を継続的に点検するには、OSSサプライチェーンの監視・スキャンの考え方が役立ちます。

なお、外部のAIモデルを安易に信頼して読み込む危険は、picklescan以外でも繰り返し問題になっています。当ブログでは悪意あるAIモデルでサーバーが乗っ取られるSGLangの脆弱性や、外部モデルを信頼して読み込む設定が悪用されるvLLMの事例も取り上げています。

CISA KEVへの登録状況

2026年6月18日時点で、今回の8件は、米政府CISAが「実際に攻撃に使われている」と認定した脆弱性リスト（KEVカタログ）には登録されていません。とはいえpicklescanはAIモデル配布の根幹で使われるツールであり、悪意あるモデルの大量配布という大規模なサプライチェーン攻撃に直結しうる類のものです。本サイトでは、攻撃中とCISAが認定したCVEの一覧をCISA KEVダッシュボード（日本語版）で随時更新しています。

よくある質問

まとめ

AIモデルの危険コードを検査するツールpicklescanに、検査をすり抜ける脆弱性が8件見つかりました。最も深刻なCVE-2026-3490はCVSS満点の10.0で、名前から任意の関数を呼び出して名簿を丸ごと無効化できます。picklescanが「安全」と表示したモデルでも、読み込んだ瞬間にパソコンやサーバーが乗っ取られる恐れがあり、Hugging Faceなどの裏側でも使われているため影響範囲は広いです。

対策は、まず最新の1.0.4へ更新すること。そのうえで、古い版で「安全」と判定して取り込んだモデルを再評価し、可能ならコードを実行できないsafetensors形式へ移行することです。検査ツールが何度も破られてきた歴史が示すのは、名簿で危険を列挙する方式の限界です。検査に頼り切るのではなく、危険な仕組みそのものを避け、読み込みを隔離する多層の備えが、AI開発の現場でこれからますます重要になります。

参照元

• ▸ NVD - CVE-2026-3490（pkgutil.resolve_name 万能回避・CVSS 10.0）
• ▸ NVD - CVE-2026-53873（profile.run経由のexec）
• ▸ NVD - CVE-2026-53874（getattrでevalを隠蔽）
• ▸ NVD - CVE-2025-71320（pydoc.locate / operator.methodcaller）
• ▸ NVD - CVE-2025-71321（distutilsで任意ファイル書込）
• ▸ NVD - CVE-2025-71322（pty.spawn）
• ▸ NVD - CVE-2025-71323（ctypes）
• ▸ NVD - CVE-2025-71325（STACK_GLOBAL解析バグ）
• ▸ picklescan 公式セキュリティアドバイザリ一覧（GitHub）
• ▸ RAXE Labs - PickleScan Universal Blocklist Bypass and Stdlib RCE Modules
• ▸ Sonatype - Bypassing picklescan: Four Vulnerabilities
• ▸ JFrog - Unveiling 3 Zero-Day Vulnerabilities in PickleScan
• ▸ ReversingLabs - Malicious ML models on Hugging Face（nullifAI）
• ▸ Hugging Face - safetensors（安全なモデル形式）