GluonTSのtar展開に任意ファイル書き込み 0.17.0更新と派生コードの点検

時系列予測ライブラリGluonTSのtar展開処理に、想定したディレクトリの外へファイルを書き込める脆弱性CVE-2026-119083が公表されました。外部から受け取ったデータセットをGluonTSで展開するバッチ、検証用ノートブック、データ取込サービスが確認対象です。AWSは0.17.0以降への更新と、フォーク・派生コードへの修正反映を推奨しています。

AWSの告知2026-171-AWSは2026年11月5日08時30分PST、つまり日本時間11月6日01時30分の公表です。本記事は11月8日に一次資料を確認した対応解説です。公開された修正版があることと、自社で動く取込処理が修正済みであることを分けて点検します。本サイトでは悪意あるアーカイブによる攻撃試験は行っていません。

外部アーカイブを展開する処理が入口になる

開発元の説明では、細工したtarにシンボリックリンクやハードリンクを含めることで、展開したファイルの書き込み先を意図した領域の外へ誘導できる可能性があります。実際に書き込める範囲は展開プロセスの権限に依存します。ライブラリが導入されているだけで、外部から自動的にサーバー全体を操作できるという説明ではありません。

本件のCVSS 3.1基本値は7.8です。開発元のベクトルはローカル、利用者の操作ありという評価になっています。Webサービスから取込ジョブを起動する構成では、誰がアーカイブを供給できるかも合わせて調べてください。公開HTTPポートがないジョブでも、利用者がアップロードしたファイルを後から処理するなら、外部入力との接点があります。

たとえば、需要予測用のデータを業務部門から受け取り、夜間に展開して学習用ディレクトリへ置く構成が考えられます。この例で確認するのは、予測モデルの精度ではなく、受領したファイルがどのプロセスで展開され、どこへ書き込めるかです。これは説明用の構成例で、特定組織の被害を示していません。

最初に実行環境と入力経路を対応付ける

本サイトでは、ジョブ名、入力元、GluonTSの版、Pythonの版、実行ユーザー、展開先を一行にまとめることを提案します。ソースリポジトリの依存ファイルだけを見るのではなく、定期ジョブ、ワーカー、ノートブック、コンテナなど実際の実行単位に結び付けます。開発端末と本番で異なるPython環境を使っていないかも確認します。

入力元は、社内のファイル共有、外部ストレージ、委託先からの受領、利用者のアップロードなどに分けます。「社内に置かれたファイル」というだけで作成元まで信頼できるとは限りません。どの担当者が供給元と内容を確認したか、後から追える状態を作ります。通信が暗号化されていることだけでは、アーカイブの中身の安全性は判断できません。

GluonTSを推論にだけ使うサービスと、データを展開する前処理では、今回の入口が違います。パッケージが存在するという情報から更新対象を洗い出した後、tarを処理するコードへ絞って露出を確認します。一方、現在は展開しないからといって依存更新を永久に不要とせず、将来の機能追加やバッチの再利用も含めて保守計画へ残します。

修正版を入れた環境で動いているか確認する

AWSと開発元のセキュリティ告知は、0.17.0未満を影響版、0.17.0を修正版として案内しています。採用する配布物と依存関係を確認し、互換性試験を行って更新します。修正の取り込みがある独自配布物を利用する場合は、版の文字列だけで例外扱いせず、供給元の対応記録で今回のリンク経由の書き込みが防がれるか確認してください。

確認用には、対象ジョブが使うPythonでpython -m pip show gluontsとpython --versionを実行し、結果と実行ファイルの所在を記録する方法があります。これは導入版を調べる例で、脆弱性の悪用可否を証明するコマンドではありません。仮想環境を複数持つ端末では、普段のシェルで得た結果をそのままジョブへ適用しないようにします。

コンテナでは依存定義を変更しただけで完了にせず、再ビルドしたイメージを対象ワーカーへ配備し、稼働中のイメージを確認します。再試行用の古いジョブ定義や、障害時に起動する予備環境が旧イメージを参照していれば、次の実行で影響版へ戻るおそれがあります。配備記録には、修正を含む成果物と使用したジョブの識別子を残します。

GluonTSのコードをコピーして独自の取込処理へ組み込んだ環境も確認します。pipのパッケージを更新しても、リポジトリ内に取り込んだコードは置き換わりません。AWSが派生コードにも修正を求めている点を踏まえ、展開処理を検索し、呼び出している実装と修正対象の対応をレビューします。名前にsafeが含まれているという理由だけで検証を省略しないでください。

Python更新は多層防御として扱う

開発元はPython 3.14以降でTarFile.extractall()にdata展開フィルターが既定で適用され、このリンク経由のトラバーサルを防ぐと説明しています。ただし、GluonTS 0.17.0への更新を推奨する方針は変わりません。Pythonの更新だけを理由に、ライブラリと派生コードの修正を保留し続ける判断にはしないでください。

Python公式資料も、3.14で既定のフィルターがdataへ変わったことを説明しています。同時に、フィルターがすべての危険な挙動を防ぐわけではないと注意しています。アーカイブの展開という作業には、保存領域や処理時間、既存ファイルとの衝突なども関わるため、今回のパス境界の修正だけで入力処理全体が安全になったとは扱いません。

Pythonを先に変える場合は、GluonTS以外の依存ライブラリや学習ジョブの互換性も検証します。本番の処理をそのまま新しいランタイムへ切り替えるのではなく、同じ正常データで読込、前処理、出力までを比較します。特定のデータ形式を扱うために危険な展開動作へ戻す設定を入れるなら、その理由と影響を別途レビューする必要があります。

更新できるまで未検証のtarを処理しない

AWSが示す暫定策は、信頼していない、または検証していない供給元のtarをGluonTSで展開しないことです。取込キューの受付を続けるかと、展開処理を実行するかを分け、確認前のファイルが自動で処理されない状態を作ります。業務を継続するために管理者権限で再実行する方法は、書き込める範囲を広げるおそれがあります。

本サイトからは、展開用の作業領域に他の処理の成果物や秘密情報を置かず、必要な権限だけで処理する構成を提案します。コンテナを使っていても、ホストの作業ディレクトリや共有ボリュームを書き込み可能で渡していれば、その境界は別に確認します。コンテナ内という説明だけで、他のジョブへ影響しないとは判断できません。

暫定停止中のファイルには受領時刻、供給元、処理状態を残します。修正後に再投入する際は、同じファイルを既に処理していないかも照合します。今回の問題を解消するための更新が、重複した学習データや二重の集計を生まないように、再開対象と除外対象を決めてからキューを戻します。

正常系と境界の確認を別の試験にする

更新後の正常試験には、実際に使う形式のデータセットを用います。展開の成功だけでなく、後続の読込と出力が従来の業務要件を満たすことを確認します。依存関係の変更で正常データが拒否される場合は、入力形式の前提が変わったのか、別のライブラリの変更なのかを切り分けます。

境界を確かめる試験は、本番とは分離した一時環境で行います。試験用の出力領域と、その外側の変更有無を確認できる領域を用意し、許可しないリンクやパスが拒否されることを開発側の回帰試験へ含める方法があります。攻撃用のアーカイブを本番へ投入して診断する必要はありません。

試験で展開が失敗した場合、途中のファイルが残る可能性も考慮します。Python公式資料は、例外発生時に部分的な展開が起こり得ることと、後片付けが利用側の責任であることを説明しています。失敗した作業領域をそのまま次の入力へ使い回さず、当該ジョブに割り当てた領域を特定して、調査に必要な記録と業務用データを分けて処理します。

過去の処理は展開時点と権限から調べる

更新は今後の不正な書き込みを防ぐための措置です。過去に影響版で未検証のtarを展開した場合は、受領ファイル、実行時刻、ワーカー、書き込み可能だった場所を照合することを提案します。展開先の一覧だけでなく、そのプロセスから到達できた共有領域も確認範囲の判断材料になります。

ファイルの更新時刻だけで悪用を断定せず、正規の配備や別ジョブの更新記録と比較します。異常が見つかった場合は、入力ファイルを再実行せず保全し、調査担当者へ引き継ぎます。参照した告知に個別組織の侵害が報告されていないことと、自組織で侵害がなかったことは別です。ログ不足の期間は、確認できた期間と区別して報告します。

対応の完了条件は、影響する実行環境と派生コードへ修正が届き、外部tarの受領から展開までの経路が整理され、正常データの処理と書き込み境界を確認できていることです。学習や分析の担当者だけで完結させず、入力元の管理者、ジョブ運用者、ストレージ管理者で、残った調査範囲を共有してから通常運用へ戻します。

セキュリティ告知の日付を、修正版の初回リリース日と混同しないことも必要です。0.17.0のリリース記録には、パストラバーサル以外の変更も含まれます。以前から0.17.0を使っている環境は、告知が新しいという理由だけで未修正とせず、実際の版と配布物を確認します。逆に、古い版へ個別の変更を取り込んだ環境は、修正範囲を供給元へ問い合わせて記録を残します。