huggingface_hubに「revisionを1回だけ解決する」機能とパストラバーサル脆弱性の修正が同時収録された

Hugging Faceのモデルをコードから落とすとき、config.json・model.safetensors・トークナイザー・プロセッサ設定など、ファイルを1つずつhf_hub_downloadで取得しているライブラリは多い。その際に地味だが実害のある問題があった。revision="main"のようなブランチ名を、呼び出しのたびにコミットハッシュへ解決していたことだ。huggingface_hub v1.26.0（2026年7月30日公開）のリリースノートは、この問題と解決策をこう説明している。

revisionを1回だけ解決するresolve_revision

Libraries that download many files one by one (config, weights, tokenizer, processor, ...) had to resolve revision="main" into a commit hash on every call — costing one HTTP request per file and risking two calls landing on two different commits if the repo is updated in between. The new HfApi.resolve_revision resolves the revision once and returns a ResolvedRevision: a str subclass whose value stays the user-facing revision (so error messages keep saying "main") while its .resolved attribute holds the commit hash.

（設定・重み・トークナイザー・プロセッサなど、ファイルを1つずつダウンロードするライブラリは、呼び出しのたびにrevision="main"をコミットハッシュへ解決する必要があった——これはファイルごとに1回のHTTPリクエストを要し、途中でリポジトリが更新されると2回の呼び出しが異なる2つのコミットに着地するリスクを伴う。新しいHfApi.resolve_revisionは、revisionを1回だけ解決してResolvedRevisionを返す：strのサブクラスで、値そのものはユーザー向けの表示用revision（エラーメッセージは引き続き"main"と表示される）のままだが、.resolved属性にコミットハッシュを保持する）

リリースノートに掲載されているコード例では、resolve_revision("openai-community/gpt2")を呼ぶとResolvedRevision(initial=None, resolved='607a30d783dfa663caf39e06633721c8d4cfcd7e')が返り、これをhf_hub_downloadのrevision引数にそのまま渡せば、config.jsonとmodel.safetensorsの両方が同じコミットから取得されることが保証される。このマッピングはキャッシュのrefs/フォルダにも書き込まれ、オフラインモードでの再実行時にはキャッシュされた値へ自動的にフォールバックするとも書かれている。

パストラバーサルの脆弱性修正（CVE-2026-15717）

同じv1.26.0には、セキュリティ修正2件が含まれている。1件目はこう説明されている。

First, downloading or uploading to a --local-dir now rejects absolute, drive-relative, root-relative, UNC and ..-traversal filenames on all platforms, interpreting each name under both POSIX and Windows rules (refs CVE-2026-15717). Previously only a Windows-only ..\ check existed, so a malicious repo could write files outside the target directory on Windows clients — and even leak a NetNTLMv2 hash via UNC paths.

（1つ目：--local-dirへのダウンロード・アップロードは、絶対パス・ドライブ相対パス・ルート相対パス・UNCパス・..によるトラバーサルを、すべてのプラットフォームで拒否するようになった。POSIXとWindows双方のルールで各ファイル名を解釈する（CVE-2026-15717参照）。これまではWindows限定の..\チェックしか存在せず、悪意あるリポジトリがWindowsクライアント上でターゲットディレクトリの外にファイルを書き込める——UNCパス経由でNetNTLMv2ハッシュを漏洩させることさえできる——状態だった）

つまり、悪意あるファイル名を持つファイルを含むリポジトリをダウンロードすると、Windows環境では意図しない場所にファイルが書き込まれる可能性があった、という脆弱性だ。リリースノートは「正当なリポジトリのファイル名がこうしたセグメントを含むことはないため、通常のダウンロードには影響しない」と補足している。

2件目の修正はサンドボックス関連だ。

Second, Sandbox.create no longer injects your HF token into the job environment to download the sbx-server binary: the bucket is public, so the bootstrap now downloads it anonymously and no HF credential ever lands in the sandbox unless you explicitly opt in with forward_hf_token=True.

（2つ目：Sandbox.createは、sbx-serverバイナリをダウンロードするためにHFトークンをジョブ環境へ注入しなくなった。バケットは公開されているため、ブートストラップは匿名でダウンロードするようになり、forward_hf_token=Trueで明示的にオプトインしない限り、HF認証情報がサンドボックスに渡ることはない）

v1.26.0の変更点を4カテゴリで整理する

リリースノート全体を見出しレベルで整理すると、v1.26.0は次の4カテゴリの変更を1回のマイナーバージョンに収めていたことが分かる。

新機能とセキュリティ修正が同じリリースに同居する理由

resolve_revisionという利便性の向上と、CVE番号付きの脆弱性修正が同じマイナーバージョンに同居しているのは、オープンソースライブラリのリリースサイクルではよくあることだが、利用者側は「新機能が入った」という見出しだけを見て、同時にセキュリティ修正も入っていることを見落としやすい。huggingface_hubを--local-dir付きで使っている、あるいは信頼していないリポジトリからファイルをダウンロードする場面がある場合は、このバージョンへの更新自体に意味がある。

同じリリースにはもう1つ、別の大きな機能追加があった

タイトルには出てこないが、v1.26.0のリリースノート原題は「Resolve revisions only once, security hardening, and resource groups for Jobs & Collections」で、実は3本柱の3本目がある。

Organization resource groups are now supported across the client. For collections, create_collection accepts an optional resource_group_id, and the new update_collection_resource_group method wraps the dedicated Hub endpoint to assign a collection to a resource group afterwards (passing None removes it). For Jobs, run_job, run_uv_job and create_scheduled_job accept a resource_group_id parameter, mirrored by a --resource-group-id option on the hf jobs run, hf jobs uv run and hf jobs scheduled run commands. Beyond access control within an organization, resource groups are also used for cost attribution and per-group spending limits.

（組織のリソースグループが、クライアント全体で使えるようになった。Collectionsではcreate_collectionが任意のresource_group_idを受け取れるようになり、新設のupdate_collection_resource_groupメソッドで後からリソースグループを割り当てられる（Noneを渡すと解除）。Jobsではrun_job・run_uv_job・create_scheduled_jobがresource_group_idパラメータを受け取り、CLIのhf jobs run・hf jobs uv run・hf jobs scheduled runには--resource-group-idオプションが対応する。組織内のアクセス制御だけでなく、コスト帰属や、グループ単位の支出上限にもリソースグループが使われる）

hf jobs run --resource-group-id <group-id> python:3.12 python train.py

つまりv1.26.0は、「ダウンロードの堅牢化」だけでなく、「組織アカウントでのJobs実行を、コスト管理単位ごとに分離できるようにする」というエンタープライズ寄りの機能拡張も同時に含んでいた。あわせてhf jobs ls（およびhf jobs scheduled ls）にJob名を表示するNAME列と--nameフィルタが追加され、これまでlabelの中にしか無かったJob名がトップレベルのフィールドとしてhf jobs inspectやコマンド結果に出るようになった、ともリリースノートは説明している。

ついでに直ったバグ：100,000バイトちょうどのsafetensorsヘッダーが読めなかった

同リリースには地味だが具体的なバグ修正も含まれている。PR #4603（修正者コメントは2026年7月29日付、Cursorが編集アシストしたPR説明文と明記）によれば、parse_safetensors_file_metadataはbytes=0-100000というHTTPレンジリクエストを送るが、HTTPのバイトレンジは両端含む（inclusive）仕様のため、実際には100,001バイトが返る——内訳は8バイトのサイズプレフィックスと、99,993バイトのヘッダー本体だ。ところがコードはmetadata_size <= 100000という条件でヘッダーサイズを判定していたため、ヘッダーが99,994〜100,000バイトちょうどのモデルファイルだけ、サイレントに切り詰められてheader is not json-encoded stringというエラーで失敗していた、という。この不具合はコミュニティの@joe0731氏による「非常に正確な報告」（PR本文の謝辞）がきっかけで見つかり、修正は「実際に受信したバイト数と比較する」という1行の変更だったという。

CVE-2026-15717の詳細な影響範囲までは追っていない

本記事はv1.26.0のリリースノート本文のみを情報源としている。CVE-2026-15717の共通脆弱性評価システム（CVSS）スコアや、National Vulnerability Databaseなど外部のCVEデータベース上での詳細な記載は、本記事の調査範囲では確認していない。この記事を書いている自分の手元で、実際に悪意あるファイル名を含むリポジトリを用意して旧バージョンでの脆弱性を再現する検証も行っていない。resolve_revisionについても、実際に自分の環境でオフラインモードのフォールバック挙動を確認する検証は行っていない。

関連記事: Hugging Face 使い方 / 生成AIのセキュリティリスク──企業が押さえるべき6つの脅威と対策 / ファインチューニング やり方・費用・いつ使うべきか【2026年入門】

感想・指摘はコメント欄へ。