Wasmtimeに脆弱性15件、サンドボックス回避も 49.0.3などで修正

Wasmtimeは、WebAssembly(Wasm)という形式のプログラムを動かす実行環境です。開発元はBytecode Allianceです。Wasmのプログラムを、決めた範囲の外に触れられない「サンドボックス(箱)」の中で動かせます。ほかのプログラムに組み込む部品としても配られ、公式の文書はプラグインの仕組みに使う例を載せています。

このWasmtimeが、10月14日に49.0.3・48.0.6・36.0.18を出し、15件の告知の問題を直しました。日付は開発元の表記(協定世界時)で、日本時間では15日の未明です。

15件のうち1件はHigh(重要)で、ファイルのサンドボックスを抜け出せる問題です。ほかの多くは、Wasmtimeを組み込んだプログラムが丸ごと止まる問題です。

15件の中身と深刻度

「ホスト」は、Wasmtimeを組み込んでWasmを動かす側のプログラムです。止まる11件は、Rustで「パニック」と呼ぶ処理の打ち切りや、スタック(処理の積み重ねの領域)のあふれです。

10月18日時点で、15件にはCVEの番号が付いていません。GitHubの確認済みの脆弱性データベースにも、まだ載っていません。

系統ごとの直した版

Wasmtimeは、毎月20日に新しいメジャー版を出します。公式の決まりでは、12の倍数の版はLTS(長く保守する版)として24か月、ほかの版は2か月保守します。セキュリティの修正は、保守中のすべての版に入れます。

版24は2024年8月20日に出たLTSで、決まりの24か月を過ぎました。2026年8月20日の24.0.13が最後で、今回の修正は出ていません。サンドボックスの件など3件は、版24も対象の範囲に入ります。

Highの1件 ファイルのサンドボックスを抜け出せる

Wasmtimeは、Wasmのプログラムにファイルを使わせるとき、決めたディレクトリの中だけに絞れます。WASI(Wasmがファイルや通信を使うための決まり)の機能で、部品の名前はwasmtime-wasiです。

告知によると、ファイルの名前を変える処理に不具合がありました。シンボリックリンク(別の場所を指す目印のファイル)と組み合わせると、外のディレクトリを箱の中へ移せました。その後は、中身を読み書きできます。告知は、ファイルのサンドボックスを完全に抜け出せる問題だとしています。

当たる条件は2つです。

• Wasmのプログラムに、書き込みを許したディレクトリが1つでもある
• Wasmtimeを動かすOSがmacOSかFreeBSDである。LinuxとWindowsは、OSの動きが違うため対象外です

告知は、回避策は無いとしています。8月に直った近い件(GHSA-vqjp-4c8c-hfgg、High)は、ファイルを開く処理だけを直し、名前の変更は直していませんでした。そのため今回の件は、告知の時点で出ていたすべての版が対象でした。

止まる件とメモリの件は外のWasmを動かす会社ほど重い

止まる11件には、外から受け取ったWasmのプログラムだけで起こせるものがあります。一方、組み込む側が特定の呼び出し方をしている場合だけ起きるものもあります。

利用者が持ち込むWasmを1つのプロセスでまとめて動かしていると、1人のWasmで、ほかの利用者の処理まで止まる恐れがあります(編集部の整理)。プラグインの仕組みや、複数の会社のプログラムを預かる実行環境が、これに当たります。

メモリの件(GHSA-q554-3cjc-rx7p)は、Wasmのプログラムがホストのメモリを際限なく使えた問題です。組み込む側が決めたメモリの上限も効きませんでした。直した版では、1つの実行単位(Store)あたり10万個の上限を新しく設けました。上限は、組み込む側の設定(Store::set_max_component_handles)や、コマンドの指定(-S max-component-handles)で変えられます。

HTTPの件(GHSA-5qpp-g3j2-8frx)は、Wasmの側が、許していない宛先へ要求を届けられた問題です。許した宛先が、受け取った要求を別の宛先へ転送する中継(フォワードプロキシなど)だった場合に起こります。外の中継でWasmの通信先を絞る会社は確かめます。

6月の件と10月2日の件も今回の版に含まれる

6月に直した件(GHSA-4ch3-9j33-3pmj、Moderate)があります。読むだけに設定したファイルを、別の場所を通して書き換えられた問題です。直した版は、6月の24.0.11・36.0.12・45.0.3・46.0.1です。

この件は、GitHubの脆弱性データベースに10月16日に載り、CVE-2026-58494が付きました。そのため、今になってDependabot(使っている部品の脆弱性を知らせるGitHubの機能)の通知が届くことがあります。古い件で、今回の49.0.3・48.0.6・36.0.18に上げれば含まれます。

10月2日にも、Critical(緊急)の1件を含む8件の告知が出ています(49.0.2・48.0.4・36.0.17で修正)。今回の版に上げれば、これらの修正も含まれます。

悪用の記載は、告知とリリースノートにありません。米国CISAのKEV(悪用が確認された脆弱性の一覧)にも、10月16日版で載っていません。

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

• 影響する: Wasmtimeを自社のサービスや道具に組み込み、利用者や取引先が持ち込むWasm(プラグインなど)を動かしている会社。直した版より前なら、止まる件の多くに当たります
• 影響する: とくに急ぐのは、macOSかFreeBSDの上でWasmtimeを動かし、Wasmにディレクトリへの書き込みを許している会社です(Highの件)
• 確認が要る: Wasmのプラグインやエッジ(利用者に近い場所)の実行環境など、Wasmtimeを中に含む製品やクラウドのサービスを使う会社。中の版と直す予定は、提供元に聞きます
• 確認が要る: 版24や、37〜47の系統を使っている会社。今回の修正は出ていないため、保守の続く系統へ移ります
• 影響しない: Highの件は、LinuxやWindowsの上で動かす場合は対象外です。ほかの件があるので、上げる計画は立てます
• 影響しない: 49.0.3・48.0.6・36.0.18以降に上げた会社

情シスが今日やること

1. Wasmtimeを使っているかを洗い出します。 開発部門と委託先に聞きます。Rustのプログラムなら、Cargo.lockでwasmtime・wasmtime-wasi・wasmtime-wasi-httpの版を見ます(cargo tree -i wasmtime でも出ます)。コマンドとして使っているなら、wasmtime --version で版を見ます。
2. Dependabotの通知を待たずに確かめます。 今回の15件は、10月18日時点で通知が届きません。
3. 直した版へ上げる日を決めます。 49系は49.0.3、48系は48.0.6、36系は36.0.18です。版24や37〜47は修正が出ないため、36・48・49のどれかの直した版へ移ります。
4. Wasmtimeを含む製品・サービスの提供元に聞きます。 中のWasmtimeの版と、10月14日の修正を入れた版の予定を聞きます。たとえばWasmのアプリの実行基盤Spinは、10月15日のv4.2.3で、使うWasmtimeを49.0.3にしています(Cargo.toml)。
5. 上げるまでは、Wasmに渡す権限を絞ります。 Highの件は回避策が無いと告知にあります。macOSやFreeBSDの上なら、信頼できないWasmに書き込みを許したディレクトリを渡していないかを見直します(編集部の補足)。

PythonやGoなど言語向けの包み(バインディング)を使う場合は、配布元で中のWasmtimeの版を確かめます。Python向けのwasmtime(PyPI)は、10月18日時点で最新が49.0.0で、49.0.3に当たる版はまだありません。

FreeBSDそのものの10月の修正は、FreeBSDに複数の脆弱性 修正版公開 TCP・サウンド・bhyveで扱っています。部品の脆弱性に追いつく更新の回し方は、AIが脆弱性を見つける時代の更新運用 OSS・SBOM・OT対策の進め方にまとめています。