Pythonのfilelockに脆弱性2件 共用のディレクトリのロックが破られる 4.2.1へ

Pythonで、複数のプロセスが同じファイルを同時に書かないようにする部品「filelock」に、脆弱性2件が公表されました。どちらも、SoftFileLockなどの「ソフトロック」の処理にあり、同じサーバーにアカウントを持つ別の利用者が、共用のディレクトリを使って起こすものです。対象は4.1.0〜4.2.0で、4.2.1で直っています。

GitHubの勧告のデータベースに載ったのは2026年10月23日(米国時間)です。2件とも、AnthropicのOSSの検査の道具が10月15日に報告し、保守の担当が確かめたものです。

2件の中身

対象は、SoftFileLock・MarkerSoftFileLock・SoftFileLease、lifetimeの指定を使ったロックの処理です。どちらも、攻撃する側が同じマシンにアカウントを持つ「ローカル」の脆弱性で、ネットワークの外からは起こせません。

対象の版は1週間だけ出ていた

PyPIの記録では、対象の版が出ていた期間は短く、4.2.1からは直っています(10月25日に当社が確かめた時点の最新は4.2.4)。

filelockは、ほかの多くの道具の依存に入っています。PyPIの登録の情報では、virtualenv(Python 3.10以降でfilelock 3.24.2以上5未満)、tox(3.25以上)、huggingface-hub(3.10.0以上)、PyTorch、datasetsが、filelockを使うとしています。どれも4.1.0〜4.2.0を除いていないため、10月9日〜17日に依存を入れ直した環境には、対象の版が入っている可能性があります(当社の見立て)。これらの道具がソフトロックを使っているかは、勧告には書かれていません。

同じOSSの検査の道具は、virtualenvでも脆弱性を見つけています(virtualenvの脆弱性が6件に 21.14.9へ更新を)。

すぐ上げられないときの対処

勧告は、修正版に上げられない場合の対処として次を挙げています。

• ソフトロックは、ほかの利用者がファイルを作れないディレクトリ(ロックを使う人だけが入れる0700のディレクトリ)に置く。共用の/tmpのような場所に置かない
• 1件目は、inodeの番号を使い回さないtmpfsに置くことでも避けられる。flockが使える手元のext4なら、SoftFileLockより、ふつうのFileLockを使う
• 2件目は、LinuxのCPython 3.11では起きない。別の利用者が決められる名前に、FileLockを取らない

影響する会社・しない会社

• 影響する: 複数の人がログインして使う開発用のサーバー、分析用のサーバー(JupyterHubなど)、共用のCIの実行機で、filelock 4.1.0〜4.2.0とソフトロックを使っている会社
• 確かめる: 10月9日〜17日に、Pythonの仮想環境やコンテナのイメージを作り直した会社。依存として対象の版が入っていないかを見ます
• 影響しにくい: 1人だけが使う端末や、ほかの利用者のいないコンテナで動かしている場合。どちらの脆弱性も、同じマシンの別の利用者が前提です(当社の見立て)
• 影響しない: filelockの4.0.x以前か、4.2.1以降を使っている場合

情シスが今日やること

1. 版を確かめます。 共用のサーバーやCIの実行機で、pip show filelock やロックファイル(requirements.txt、poetry.lockなど)で、filelockの版を一覧にします。とくに10月9日〜17日に作った環境やイメージを優先します。
2. 4.2.1以降に上げます。 対象の版が入っていれば、4.2.1以降(確かめた時点の最新は4.2.4)に上げ、コンテナのイメージは作り直します。
3. 共用のディレクトリの使い方を見直します。 複数の利用者がいるサーバーで、キャッシュやロックのファイルを/tmpのような共用の場所に置く設定がないかを、開発の部門と確かめます。置き場所は利用者ごとのディレクトリにします。
4. 依存の入れ直しの記録を残します。 どの日にどの版の部品を入れたかが分かると、今回のように短い期間だけ出ていた版を追いやすくなります。ロックファイルとイメージの作成の記録を残す運用にします(当社の見立て)。