so-vits-svc 脆弱性 CVE-2026-65701（歌声変換OSS、CVSS 9.1・v3.1）が2026年7月23日に公開された。だが「アップデートすれば直る」という通常のCVE記事のセオリーが、この記事には通用しない。本家の最終コミットは2023年11月11日で、以降2年9か月にわたって更新が止まっているからだ。★28,151・fork 5,044という規模のOSSが、脆弱性を抱えたまま凍結している——この記事では、so-vits-svcを今も使っている、あるいはforkして運用している開発者が、修正パッチを待たずに今できることを実測データとともに整理する。
- ・何が起きた：AI 音声変換 脆弱性として、歌声変換OSS
so-vits-svcの/wav2wavFlaskエンドポイントに wav2wav パストラバーサル脆弱性 CVE-2026-65701（CVSS 9.1・v3.1／9.3・v4.0）が2026-07-23に公開された。 - ・なぜ厄介か：本家は2023-11-11を最後に更新が止まっており（以降2年9か月コミット無し）、公式リリースも0本。修正パッチが出る見込みは無い。
- ・星数と実体の乖離：★28,151・fork 5,044という人気規模の一方、直近の活性度は事実上ゼロ。starやforkの多さは「過去の人気」であって「現在メンテされている」ことの証明にはならない。
- ・今できること：
/wav2wavエンドポイントの外部公開を止める、配布モデル・設定ファイルをチェックサムで検疫する、メンテされているフォーク（RVC等）への移行を検討する、の3択が現実解。 - ・日本語カバレッジ：本記事執筆時点でセキュリティ面を扱った日本語記事は確認できず（ツールとしての使い方記事はZennに複数存在）。
サプライチェーン攻撃・依存OSSのリスク全般については サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト で体系的にまとめている。
so-vits-svcとは｜CVE-2026-65701の概要と公開までの時系列
so-vits-svc（SoftVC VITS Singing Voice Conversion） は、svc-develop-team が開発するPython（PyTorch）製の歌声変換OSSだ。VITSという音声合成モデルとSoftVC（Soft Speech Units）を組み合わせ、あるアーティストの歌声を別の声質に変換する用途で、2023年前後に日本語圏を含む音声変換コミュニティで広く使われた。ライセンスはAGPL-3.0（README・LICENSEファイルとも一致）。
・GitHub Star数：28,151（GitHub API実測・2026-08-04）
・Fork数：5,044
・総コミット数：約854（Linkヘッダから概算）
・contributor数：45
・公式リリース：0本（バージョンタグを切った正式リリースが一度も出ていない）
・最終push：2023-11-11（以降コミットなし＝本記事執筆時点で約2年9か月のso-vits-svc 更新停止状態）
so-vits-svc セキュリティを語るうえで欠かせないのが、この「更新停止したまま脆弱性が見つかった」という組み合わせだ。歌声変換という用途自体はニッチでも、GitHub上での知名度は高く、今も検索すればインストール手順がヒットするため、古い手順のまま使い続けている利用者が一定数いる可能性がある。
CVE-2026-65701のタイムラインは次の通りだ。2023-11-11の最終pushの時点で、この脆弱性を含むコードはすでにリポジトリに存在していたとみられる。それから2年9か月が経過した2026-07-23、GitHub Security Advisory（GHSA-cc9w-9gmw-9p6j）としてこの脆弱性が公表された。開示日から本記事執筆時点（2026-08-04）まで、修正コミットは1件も入っていない。通常のCVE記事であれば「脆弱性公開→修正パッチのリリース→アップデート推奨」という流れで書けるが、so-vits-svcにはこの「修正パッチのリリース」というステップ自体が存在しない。
このプロジェクトが広まった経緯にも触れておきたい。SoftVC（Soft Speech Units）は、音声認識モデルが出力する連続的な特徴量を使って音色を変換する手法で、離散的な特徴量を使う手法に比べて発音の自然さを保ちやすいとされていた。VITS自体はEnd-to-Endで学習できるTTS（音声合成）アーキテクチャで、so-vits-svcはこれを歌声変換向けに転用したものだ。2023年当時、少ないデータ量からでも自然な歌声変換ができる実装として、日本語圏でも「歌ってみた」系のコンテンツ制作でしばしば参照された。この知名度の高さが、今もインストール手順を検索すれば見つかってしまう状態につながっている。
CVE-2026-65701の技術詳細｜wav2wavエンドポイントのパストラバーサル
CVE-2026-65701は、so-vits-svcが公開する /wav2wav というFlaskのAPIルートに存在するパストラバーサル脆弱性だ。VulnCheckの技術詳細によれば、このルートが受け取る audio_path パラメータの検証が不十分で、../../ のようなディレクトリ境界を突破する文字列を含むパスを渡すことで、本来アクセスできないはずのファイルを読み取れる可能性がある。
audio_pathパラメータを指定"] --> B["/wav2wav Flaskルート
パスの検証が不十分"] B --> C["../../ を含む文字列で
ディレクトリ境界を突破"] C --> D["サーバー上の任意ファイルを
読み取り"]
深刻度はCVSSのバージョンによって2種類の数字が公表されている点に注意したい。CVSS v3.1で9.1（Critical）、CVSS v4.0で9.3（Critical）——評価機関が対立しているわけではなく、採点方式のバージョン差であり、いずれにせよ最上位の深刻度である点は変わらない。
任意ファイル読み取りが実際にどこまで到達しうるかは、so-vits-svcをどう動かしているか次第で変わる。ローカルPC上で自分専用に動かしているだけなら影響は限定的だが、WebUIをクラウドサーバーに立てて外部からアクセスできる状態にしている、あるいは学習済みモデルの配布・推論をサービスとして提供している場合は話が変わる。サーバー上に置かれた設定ファイル・環境変数・SSH鍵・他アプリケーションの認証情報などが同じファイルシステム上にあれば、パストラバーサルによってそれらを読み取られるリスクがある。RCE（リモートコード実行）まで到達するかどうかはGHSAの技術詳細では明言されていないが、「任意ファイル読み取り」単体でもCVSS 9.1というスコアが示す通り、機密情報の漏洩としては十分に深刻だ。
GHSAの脆弱性データには機械可読なバージョン範囲（vulnerabilitiesフィールド）が設定されていない。so-vits-svcにはそもそもバージョンタグを切った公式リリースが存在しないためだ。NVD／VulnCheckの一次情報は影響範囲を「commit
730930d まで」というコミットハッシュ単位で示している。本記事でも存在しないバージョン番号を捏造せず、この表記に統一する。
① このOSSは結局何ができる：VITSベースの歌声変換。数分の音声データから話者の声質を学習し、別の音声に変換できる ② 何を解決してきたか：歌ってみた動画・音声コンテンツ制作での声質変換という需要を、無料かつローカル実行で満たしてきた。ただし脆弱性そのものは未解決のまま放置されている ③ 何を代替できるか：機能面ではメンテされているフォーク（後述のRVC等）が代替になる。
so-vits-svc 脆弱性 が危険な理由｜Star 28,151 と開発停止の乖離
★28,151・fork 5,044という数字だけを見れば、so-vits-svcは今も活発なOSSに見える。しかし実態は逆だ。contributorの内訳を見ると、45名中 ylzz1997 が382コミット（総854の約45%）を占め、2位以下は急減する典型的な「少数の中核開発者に依存した」プロジェクトだった。そしてその中核開発者を含め、2023-11-11以降は誰もコミットしていない。
この「star数と実体の乖離」は、AI関連OSSで繰り返し起きるパターンだ。starやforkは「かつて多くの人が価値を感じた」という過去の人気の指標であり、「現在も安全にメンテされている」ことの証明にはならない。so-vits-svcのように公式リリースが1本も無いプロジェクト（＝バージョニングされないまま「動くコード」だけが置かれ続けている状態）は、脆弱性が見つかっても「どのバージョンから直っているか」を示す手段自体が存在しない。
バス係数（プロジェクトが少数の開発者にどれだけ依存しているか）の観点でも、so-vits-svcは典型例だ。45名のcontributorのうち上位1名が総コミットの半数近くを占め、2位・3位以降は急減する分布になっている。2023年時点ではこの体制で開発が回っていたとしても、その中核メンバーが離脱すれば、たとえ他のcontributorが残っていてもプロジェクト自体が実質的に止まってしまう。企業スポンサーの後ろ盾も無いため、脆弱性が公表されても「誰が責任を持って直すか」が構造的に定まっていない状態だったといえる。人気OSSを選定する際は、star数だけでなく「最終コミット日」「contributor分布」「公式リリースの有無」の3点を必ず確認する価値がある。
so-vits-svc 脆弱性の影響を自分の環境が受けていないか確認する方法
再現実験は行わない（他者のサーバーへの攻撃検証は絶対に避けること）。自分の環境で so-vits-svc を動かしている、あるいは動かしていた形跡がないかを確認する範囲にとどめる。
# so-vits-svc関連のプロセス（Flask/wav2wav/inference_main）が動いていないか確認
ps aux | grep -iE "flask|wav2wav|inference_main"
# 該当ポートが外部にLISTENしていないか確認（ポート番号はREADME記載の起動設定を個別に確認する）
netstat -an | grep LISTEN
本記事の執筆環境（検証用サンドボックス）で上記コマンドを実行した結果、flask / wav2wav / inference_main に該当するプロセスは検出されず、LISTEN中のポートも sshd と名前解決用のローカルリスナーのみだった。該当プロセスが無ければそれで確認は完了で、無理に脆弱性を再現させる必要はない。
Dockerコンテナ経由でso-vits-svcを動かしている場合は、ホストOS側で ps aux を実行してもコンテナ内のプロセスは見えない点に注意したい。その場合は docker ps でso-vits-svc関連のコンテナが起動していないかを確認し、起動している場合は docker port <コンテナ名> でホスト側に公開されているポートを洗い出す。ポートが 0.0.0.0 に公開されている（＝ホストのすべてのネットワークインターフェースからアクセス可能になっている）場合は、127.0.0.1 へのバインドに変更するか、ファイアウォールで外部からのアクセスを遮断する。
配布されているモデルファイルや設定ファイルを外部から取得して使っている場合は、改ざんされていないかチェックサムで検疫する習慣も有効だ。
# ダウンロードしたモデル・設定ファイルのチェックサムを確認する例
sha256sum <ダウンロードしたモデルファイル>
so-vits-svcの脆弱性への緩和策｜公式パッチが来ない前提でできること
「最新版にアップデートしてください」という通常のCVE記事の定番対策が、so-vits-svcには存在しない。そのため緩和策は、利用者側の運用でリスクを下げる方向に絞られる。
・エンドポイントの外部公開を止める：/wav2wav を含むFlaskサーバーを、ローカルホスト以外（0.0.0.0 等）にバインドして公開していないか確認し、公開している場合は遮断するかリバースプロキシ側で認証を挟む
・配布物の検疫：モデルファイル・設定ファイルを外部から取得する場合は、配布元とチェックサムを突き合わせてから展開する
・展開先ディレクトリの隔離：audio_path 等のユーザー指定パスがどのディレクトリを起点に解決されるかをコード側で把握し、コンテナやサンドボックス環境で実行してホスト側のファイルシステムに影響が及ばないようにする
・fork版の情報を確認する：svc-develop-team の名前を継いだ非公式フォークが存在する場合、そのフォーク側でCVE-2026-65701相当の修正が入っているかを個別に確認する（本記事執筆時点でフォーク側の修正状況までは未確認であり、断定しない）
・長期的にはメンテされている代替への移行を検討する：後述のフォーク移行を参照
これらの中で最も即効性があるのは、やはり「エンドポイントの外部公開を止める」ことだ。so-vits-svcはもともとローカル環境やクローズドな研究用途での利用を想定して作られており、/wav2wav のようなFlaskルートに強固な認証機構が備わっていない。インターネットに直接公開する運用自体が、この脆弱性の有無にかかわらずリスクの高い構成だったといえる。すでに公開してしまっている場合は、Nginx等のリバースプロキシでBasic認証やIP制限を追加するだけでも、攻撃対象を大きく絞り込める。
so-vits-svcはAGPL-3.0でライセンスされている。AGPLはGPLと異なり、ネットワーク経由でサービスとして提供する場合にもソースコード開示義務が及ぶ。本家が更新停止している状況で独自にパッチを当てて外部提供する場合、この開示義務が発生する点を運用ルールに組み込んでおく必要がある。
メンテされているforkへの移行｜so-vits-svcからRVCへ
so-vits-svcと同じくVITS系の音声変換OSSとして、RVC（Retrieval-based Voice Conversion） が、実質的な後継として日本語圏でもよく使われている（RVCの使い方・学習手順は当サイトの別記事で詳しく解説している）。
| 項目 | so-vits-svc（本家） | RVC（隣接記事で解説済み） |
|---|---|---|
| ライセンス | AGPL-3.0 | MIT |
| GitHub Star数 | 28,151（2026-08-04実測） | 約3.6万（2026年7月時点・既存記事より） |
| 公式リリース | 0本（バージョンタグなし） | 別記事で解説対象のため本記事では扱わない |
| 開発状況 | 最終push 2023-11-11、以降更新なし | 本サイトの別記事で解説済み。移行先候補として言及 |
| 本記事での位置づけ | CVE-2026-65701（CVSS 9.1）の影響を受ける、修正見込みのないプロジェクト | ライセンス面（MIT）・エコシステムの観点で検討に値する移行先候補 |
RVCとso-vits-svcはどちらもVITS系の音声変換だが、細かな仕様やライセンスはフォークごとに異なる。歌声変換に特化した用途でso-vits-svc系のフォークを使い続ける場合も、どのフォークがCVE-2026-65701相当の修正を取り込んでいるかを移行前に個別確認することをお勧めする。
関連するAI開発者ツールの脆弱性事例
so-vits-svcのように、AI/開発者向けOSSのエンドポイントが原因で任意ファイル読み取りに繋がるパストラバーサル系の脆弱性は他にも報告されている。Windmill 脆弱性 CVE-2026-29059｜認証不要でファイルと秘密情報を読まれる、確認と対策 は同種の「認証不要でのファイル読み取り」を扱った事例で、影響範囲の考え方や確認コマンドの組み立て方が参考になる。
複数のCVEを抱えた開発者ツールという観点では、datamodel-code-generator 脆弱性12件｜生成コードのimportでRCE・修正は0.64.0 のように、こちらは修正版が存在するケースとの対比としても読める。「パッチが来る脆弱性」と「パッチが来ない脆弱性」で、利用者が取るべき対応がどう変わるかが見えてくる。
AIツール全般の安全な運用という論点では、OpenClawのセキュリティリスク完全ガイド：138件のCVE、Cisco調査、安全な使い方 も、更新が活発なOSSでも脆弱性が積み重なりうるという点で併読の価値がある。
まとめ｜so-vits-svcの脆弱性とどう向き合うか
今so-vits-svcを使っている、あるいは自分のサーバーで動かした形跡がある場合は、
/wav2wav エンドポイントの外部公開状況を確認し、必要であれば遮断する。長期的な選択肢としては、メンテされているフォークやRVCのような後継OSSへの移行も検討したい。
参照ソース
・GHSA-cc9w-9gmw-9p6j｜CVE-2026-65701（svc-develop-team/so-vits-svc 公式 GitHub Security Advisory・一次ソース） — CVSS 9.1（v3.1）／9.3（v4.0）・脆弱性の技術詳細
・NVD — CVE-2026-65701 — 公式脆弱性データベースの記録
・VulnCheck Advisory — so-vits-svc path traversal via wav2wav Flask route — 攻撃面（audio_pathパラメータ）の技術詳細
・svc-develop-team/so-vits-svc（公式リポジトリ） — star/fork/コミット/リリース数等の実測値・最終pushの確認
