その動画素材は罠かもしれない：動画編集ソフトのFFmpeg脆弱性

動画編集ソフトは、あなたが再生ボタンを押す前に、内蔵した FFmpeg で全ファイルをデコードする。細工されたファイルは、そのサムネイル生成の最中にメモリ破壊のバグを踏ませることができる。編集ソフトの更新が最も効く対策なのは今も変わらないが、2026-07-22 に公開された6件のアドバイザリは現行最新の FFmpeg を影響範囲に名指しし、修正は開発ブランチにしかない。「更新して終わり」では閉じない。

「怪しい .exe は開くな」はネットリテラシーの基本だ。だが、あなたが完全に信頼している .mp4 のほうは、タイムラインに触れた瞬間そのままメディアパーサに渡っている。

多くの動画編集ソフトはデコードに FFmpeg を使っている。ソフト本体が1〜2年更新されていないなら、中の FFmpeg もその日からパッチを受け取っていない。

プレビューした時点で、デコードは終わっている

再生ボタンを押す必要はない。ファイルを手動で開く必要すらない。

タイムラインに動画をドラッグした瞬間、ソフトはバックグラウンドでデコードを始める。サムネイル、波形、プロキシ。その処理はすべて内蔵の FFmpeg を通る。

これは実測できる。サムネイルを1枚 作るだけでも、デマルチプレクサとデコーダは動く。

ffmpeg -loglevel verbose -i holiday_clip.mp4 -frames:v 1 thumb.png

Input #0, matroska,webm, from 'holiday_clip.mp4':
  Stream #0:0 -> #0:0 (h264 (native) -> png (native))
  Input stream #0:0 (video): 20 packets read (24974 bytes); 5 frames decoded; 0 decode errors;

静止画1枚のために20パケット読んで5フレームをデコードしている。「プレビューしただけ」と「デコードした」は同じことだ。

拡張子はパーサを決めない

ここが、この手の記事でいちばん取りこぼされる部分だ。上のログをもう一度見てほしい。ファイル名は holiday_clip.mp4 なのに、FFmpeg は Input #0, matroska,webm と言っている。

このファイルは Matroska を僕がリネームしただけのものだ。FFmpeg は中身を probe して Matroska デマルチプレクサに回した。同じファイルを subtitles.srt にしても、やはり matroska,webm と判定される。

cp real_matroska.mkv holiday_clip.mp4
ffprobe -v error -show_entries format=format_name -of default=nw=1 holiday_clip.mp4
# format_name=matroska,webm

つまり、末尾の .mp4 はどのパーサが動くかを何も教えてくれない。僕の環境のビルドはデマルチプレクサ 373・デコーダ 559 を持っていて、中身ベースの判定がある以上、開いたファイルからはそのどれもが射程に入る。「自分は MP4 しか扱わない」人にとってもマイナーなデコーダのバグが他人事でないのは、これが理由だ。

攻撃が成立するとしたら、こう動く

以下はシナリオであって、起きた事件の報告ではない。その区別は節の最後で必ず付ける。あなたはそこそこ登録者のいる YouTuber で、企業案件を装ったメールが届いたとする。

件名: [PR 案件のご相談] 新作タイトルのご紹介

本文: ぜひご一緒できればと思います。参考用に未公開のゲームプレイ映像を添付しました。

添付: gameplay_demo_v2.mp4

攻撃の流れ

ステップ1: 罠

添付ファイルは、普通のプレーヤーでは再生に失敗する（壊れて見える）か、あるいは普通に再生できるが、特定のパーサが誤処理する不正な構造を抱えている。

ステップ2: 接触

あなたは愛用の編集ソフト（ワークフローが回っているから更新していないやつ）を開き、ファイルをタイムラインに落とす。

ステップ3: 発火

編集ソフトの FFmpeg がファイルを probe し、中身からデマルチプレクサを選び、サムネイルを描く分だけデコードする。不正なフィールドがバッファの末尾を越える書き込みを起こす。攻撃者の仕事はここで終わりではなく、ここから始まる。 ASLR・スタックカナリア・DEP が「バッファが壊れた」と「コードが動いた」の間に立ちはだかっていて、メモリ破壊のバグの多くはクラッシュで止まる。これをコード実行に変えるのは、特定のビルドを狙った相応の作業だ。

ステップ4: 被害

画面には「ファイルの読み込みに失敗しました」が出るか、ソフトがそのまま落ちる。これが起きやすいほうの結末で、同時に「攻撃が失敗したとき」の見え方でもある。 成立してしまった場合は、編集ソフトのプロセスが届く範囲——保存済みの認証情報、セッション Cookie、チャンネルの認証トークン、プロジェクト一式——が攻撃者の手に渡る。

標的型でデータファイルが実行ファイルに勝つのはこの構図があるからだ。「動画は安全」というあなたの前提そのものが利用されている。

そして、約束した区別を付ける。 ここまでは一度も「起きたこと」の話ではない。2026年7月の6件について、NVD に載る CISA-ADP の評価はすべて exploitation: none（悪用の公開された証拠なし）で、うち4件は automatable=no（自動化できない）ともされている。この脅威モデルに手を打つ価値があるのは、実際に攻撃が流行しているからではなく、頼んでもいないファイルが、あなたの同意なくデコードされる という到達性のほうだ。

なぜ編集ソフトが狙い目なのか

1. 内蔵 FFmpeg の更新ラグ

編集ソフトは FFmpeg を DLL で同梱するか、静的リンクで焼き込む。ベンダーが更新をやめた時点で、その中の FFmpeg はパッチを受け取らなくなる——恒久的に。changelog が「最終更新 2021年」なら、中身は 2021年の FFmpeg だ。

2. 「動画＝データ」という思い込み

多くの人は「実行ファイル」と「データ」の間に硬い線を引いている。動画はデータ側に見える。ウイルス対策ソフトの主戦場は既知マルウェアのシグネチャ照合であって、コンテナ構造を深く読んでロジックバグを探すことではない。

3. コーデックの複雑さと、巨大なデフォルトビルド

H.264・H.265・AV1・VP9 はどれも巨大な仕様だ。だが攻撃面は、あなたが実際に使うコーデックよりずっと広い。僕の環境の標準的な GPL ビルドには、数百のうちこんなものが入っている。

ffmpeg -demuxers | grep -E "vobsub"
ffmpeg -decoders | grep -E "vqavideo|adpcm_adx"

 D   vobsub          VobSub subtitle format
 V....D vqavideo             Westwood Studios VQA (Vector Quantized Animation) video (codec ws_vqa)
 A....D adpcm_adx            SEGA CRI ADX ADPCM

1990年代の Westwood Studios 製ゲームフォーマットのデコーダが、2026年のビルドに入っている。そして中身ベースの判定があるからこそ、それが「送られてきたファイル」の射程に入る。ただし、ビルドに入っているもの全部がその経路で届くわけではない。マルチプレクサはその形式に出力する ときしか動かないし、ネットワークストリームを前提にしたデマルチプレクサもある。この線引きは重要なので、後の節でもう一度扱う。

実在する FFmpeg の CVE と、それを直したバージョン

以下の各行は 2026-08-02 に NVD の API から読んだものだ。実際に効くのは「修正版」の列で、そしてこの列こそ多くの記事が省く。

読み方の注意を2つ。「修正版」は ffmpeg.org/security.html が挙げるバックポート先のリリースを全部並べている——NVD の影響バージョン範囲はこれより粗く、5.0.3 で直ったバグについて「パッチ済みの 4.4.4 も影響あり」と平気で言ってくる。CVSS はスコアを付けた主体とセットで書いた。NVD と採番ベンダーはしょっちゅう食い違う——ときに5点も。

この表から取り出しておきたいことが3つある。

MP4 のパーサ自体もやられている。 CVE-2026-40962 は libavformat/mov.c の整数オーバーフローで、CENC（Common Encryption）の subsample データ経由で到達する——仮定の話ではなく、細工された MP4 が通る実際の経路だ。同時に、採点者の食い違いが最も露骨な例でもある。NVD は 9.8 Critical、MITRE は 4.9 Medium と言っている。

字幕ファイルは格下の脅威ではない。 CVE-2026-64830 は VobSub デマルチプレクサのヒープオーバーフローで、VulnCheck は「FFmpeg の VobSub デマルチプレクサを使う任意のアプリケーションで任意コード実行に至る可能性がある」と書いている。.sub / .idx のペアがそれをやる。

FFmpeg の CVE が全部この経路で踏めるわけではない。 この記事の前版は、上の表に CVE-2020-20891 を入れていた。入れるべきではなかった。あれは libavfilter/vf_gblur.c——ガウスぼかしフィルタ のバッファオーバーフローで、コマンドに -vf gblur を明示的に足したときにしか通らない。タイムラインにファイルを落とすだけでは一生触れない。

同じ物差しを当てた結果、上の表には2026年7月の6件のうち4件しか載せていない。CVE-2026-64833 は S/PDIF マルチプレクサ——出力側で、S/PDIF にエンコードする ときに通る経路であって、ファイルを開いたときではない。CVE-2026-64834 は細工された RTP/ASF ストリーム を必要とする。ディスク上のファイルではなくネットワーク経路だ。どちらも同じビルドに実在するバグだが、どちらもドラッグ&ドロップでは発火しない。「FFmpeg」の隣に CVE 番号が並んでいることは、「ファイルでそれを引ける」ことを自動的には意味しない。ここが脅威モデルと恐怖リストの分かれ目だ。

更新しても、既知の問題が全部消えるわけではない

ここからが居心地の悪い部分で、この記事を書き直した理由でもある。

FFmpeg 8.1.2 は 2026-06-17 にリリースされた現行の安定版だ。そして 2026-07-22、VulnCheck は6件のアドバイザリ（CVE-2026-64830〜CVE-2026-64835）を公開した。その 8.1.2 自体 が影響範囲に入っている。うち4件は CVSS v3.1 の基本値が 8.8 だ。

修正は存在する。2026-06-29 と 2026-06-30 に master に入っている。ただしリリースには入っていない。それがこのプロジェクトのやり方だからで、ダウンロードページにはっきり書いてある。

The release branches only cherry pick selected changes from the development branch, which therefore receives much more and much faster bug fixes such as additional features and security patches.

（リリースブランチは開発ブランチから選んだ変更だけを cherry-pick する。したがって開発ブランチのほうが、追加機能やセキュリティパッチのような修正をはるかに多く、はるかに速く受け取る。）

自分でも確かめた。僕がこのマシンに置いているビルドは release/8.1 ブランチの先頭だ。

ffmpeg -version | head -1
# ffmpeg version n8.1.2-34-g9b6c8969e0-20260801

8.1.2 タグから34コミット先、ビルド日は 2026-08-01。そしてその34コミットの中に vobsub・nvdec・adx・vulkan_hevc の修正は無い。あれらは master にいる。一方、リリースごとの修正 CVE を並べている ffmpeg.org/security.html は、2026-08-02 時点で CVE-2026-64830〜64835 をどこにも載せていない。

パッケージマネージャは、思っているより遅れているかもしれない

「パッケージマネージャの FFmpeg を使え、あれはメンテされている」という昔ながらの助言は、実際のアーカイブに当ててみると成立しない。Ubuntu 24.04 LTS の場合:

apt-cache policy ffmpeg

ffmpeg:
  Installed: 7:6.1.1-3ubuntu5
  Candidate: 7:6.1.1-3ubuntu5
  Version table:
 *** 7:6.1.1-3ubuntu5 500
        500 http://archive.ubuntu.com/ubuntu noble/universe amd64 Packages

候補は noble/universe の1つだけで、同梱 changelog の最新エントリは 2024-04-05——librist の入れ替えに伴うリビルドであって、セキュリティ修正ではない。一方 Ubuntu 自身の CVE トラッカーは、noble の修正版を 7:6.1.1-3ubuntu5+esm5（CVE-2024-7055）と 7:6.1.1-3ubuntu5+esm1（CVE-2024-31578）と記載している。+esm は素の archive ではなく Ubuntu Pro の拡張メンテナンス経由で配られるビルドを指す。

Ubuntu Pro は個人利用なら5台まで無料なので、sudo pro attach 一発で届く距離ではある——ただし「やる必要がある」と知っていれば、の話だ。この教訓は Ubuntu の外にも一般化する。パッケージマネージャのバージョン番号が教えてくれるのはどの upstream リリースから始まったか であって、そのバイナリに何のパッチが入っているかではない。

使っている編集ソフトの FFmpeg を調べる

この話題を扱う記事はどれも「内蔵 FFmpeg のバージョンを気にしろ」と言う。読み方まで書いている記事はほぼ無い。読める。FFmpeg はバージョン文字列をバイナリに焼き込んでいるからだ。

Linux か macOS なら、ライブラリに strings を当てる。

strings -a /usr/lib/x86_64-linux-gnu/libavcodec.so.60 | grep -E "FFmpeg version|^Lavc[0-9]+\.[0-9]+\.[0-9]+$"

FFmpeg version 6.1.1-3ubuntu5
Lavc60.31.102

Windows なら、編集ソフトのインストール先にある avcodec-*.dll / avformat-*.dll か同梱の ffmpeg.exe に対して、同じ検索をかける（Git Bash・WSL・Sysinternals の strings.exe のいずれでもいい）。

ここでのハマりどころが2つある。

• 見るのは FFmpeg version ... の行で、Lavc の数字ではない。 Lavc 番号が特定できるのはブランチであってポイントリリースではない。FFmpeg 6.1.6 の libavcodec も 60.31.102 なので、Lavc60.31.102 では 6.1.1 と 6.1.6 を区別できない——そして CVE-2024-7055 が直ったのは 6.1.2 だ。
• ベンダーがパッチしたビルドは、番号の見た目より安全なことがある。 ディストリビューションや一部の編集ソフトのベンダーは、バージョンを上げずに修正だけバックポートする。この文字列は、ベンダーに問い合わせるための出発点であって、判定結果ではない。

番号が取れたら、上の表の「修正版」列と、リリースごとの修正 CVE を並べている ffmpeg.org/security.html に突き合わせる。

クリエイターが取るべき3つの防衛策

メモリ破壊の悪用を理解しなくても、露出は意味のある幅で減らせる。

レベル1（必須）: 編集ソフトを更新する

依然として、他を大きく引き離して効果が高い行動だ。「最新リリース」と「完全にパッチ済み」の差は週 単位。「2021年のビルド」と「完全にパッチ済み」の差は5年 分の、公開され採点されインデックスされた CVE で、うちいくつかには PoC コードが付いている。NVD の CVE-2024-7055 のエントリ自身が「the exploit has been disclosed to the public（エクスプロイトは公開済み）」と書いている。

今すぐやること:

1. 動画編集ソフトを開く
2. 「ヘルプ」→「アップデートを確認」または「バージョン情報」を開く
3. 最終更新が12か月以上前なら、即アップデートするか、乗り換え先の検討を始める

使っているのが DaVinci Resolve でも、Adobe Premiere Pro でも、Final Cut Pro でも、Filmora でも、Kdenlive でも、changelog を自分で開いて日付を読んでほしい。記事に載っているリストを信用しないこと——この記事のリストも含めて。リストはスナップショットだが、changelog の日付は30秒で確認できる事実だ。オープンソースならリポジトリが直接答える。Kdenlive の KDE リポジトリには 2026-07-30 までのリリースタグがある。

レベル2（運用）: 隔離が先、無害化は後

よく見る助言——「FFmpeg で再エンコードすればエクスプロイトを剥がせる」——は、誰を守るのかについて順序が逆 だ。そしてこの記事の前版も同じ間違いをしていた。

再エンコードは、まず敵性の入力をデコードする。それが再エンコードの本質そのものだし、ログにもそう出る。

ffmpeg -loglevel verbose -i suspicious.mp4 -c:v libx264 -crf 23 -c:a aac sanitized.mp4

Stream #0:0 -> #0:0 (h264 (native) -> h264 (libx264))
  Input stream #0:0 (video): 25 packets read (30038 bytes); 25 frames decoded; 0 decode errors;

25フレームがデコードされている。あなたの FFmpeg が、あなたの マシンで、攻撃者が狙っているまさにそのコードパスを通して。出力ファイルは次に受け取る人にとって本当にきれいになる。きれいにならないのはあなただ。

だから、順番はこうする。

ステップ1: 出所不明のファイルは使い捨ての VM かコンテナで開く。 VirtualBox・VMware、あるいはホストのマウントを持たない --network=none の Docker コンテナ。汚染されたら消せばいい。作業マシンを実際に守るのはこの工程だけだ。

ステップ2: その VM の中で再エンコードする。 最新の FFmpeg を使い、本番の編集環境に持ち込むきれいなファイルを作る。

ステップ3: 形式が分かっているならデマルチプレクサを固定する。 自動判定はどのパーサでも動きうるということだ。1つに固定すれば、攻撃面はそのパーサに縮む。

ffmpeg -f mp4 -i suspicious.mp4 -c:v libx264 -crf 23 -c:a aac sanitized.mp4

中身が本当は MP4 でなければ、どのパーサに渡るか分からない状態ではなく、MP4 デマルチプレクサの段階で止まる。僕は .mp4 という名前の Matroska で試した。-f mp4 は moov atom not found で失敗し、Matroska デマルチプレクサには一度も到達しない。

ステップ4: VirusTotal は関所ではなく補助として使う。 既知のマルウェアは捕まる。メディアコンテナの中の新規のパーサ悪用は、シグネチャエンジンが探すようにできているものではない。

レベル3（選定）: メンテナンスの止まったソフトを使わない

「慣れているから」は、業務のワークフローに abandonware を置き続ける理由としては足りない。

• 公式の changelog かリリースノートで日付を確認する
• オープンソースならリポジトリの最近のコミットとタグを見る
• ソフト名 + 「release notes」で検索して、実際の最終リリースを探す

1年以上リリースもセキュリティ告知も無いなら、それはサポート外だ。そう扱うこと。

もう一段手前: ファイルを受け取らない

ここまでは全部、ファイルがすでにディスクに届いた前提の話だ。NordVPN の Threat Protection Pro は一段手前で働く——既知の悪性サイトをブロックし、ダウンロードをスキャンする。VPN に接続していなくても単体で動く。シグネチャベースの層なので、新規のパーサ悪用はアンチウイルス同様に見抜けない。だが多くの攻撃は普通の悪性リンクやダウンロードから始まるので、そこは受け持ってくれる。

よくある質問

Q1: iPhone で撮った動画は安全ですか

実用上は安全だ。自分のカメラやスマホが作ったファイルの中身は通常の画像データだ。リスクは、第三者から受け取ったファイルや、信用できない場所からダウンロードしたファイルのほうにある。

Q2: ウイルス対策ソフトを入れていれば防げますか

部分的に。従来型のアンチウイルスはシグネチャ照合に寄っている。不正なコンテナのフィールド経由で踏むメモリ破壊のバグはシグネチャではなく、特定バージョンのパーサが誤処理するデータの形 だ。アンチウイルスは一層であって解決策ではない。

Q3: Mac なら影響しませんか

影響する。ただし挙げる例は選ぶ必要がある。ソフトウェアデコーダはどの OS でも同じ C なので、CVE-2026-64830（VobSub デマルチプレクサ）と CVE-2026-64835（ADX デコーダ）は Mac にも PC と同じように当てはまる。一方、あの6件のうちハードウェア 経路の2件は当てはまらない。FFmpeg 自身のハードウェアアクセラレーション対応表は、NVENC/NVDEC/CUVID（CVE-2026-64832）と Vulkan（CVE-2026-64831）を macOS・iOS では利用不可としている。macOS の緩和機構は優秀だが、「Mac はウイルスに感染しない」は脅威モデルではない。

Q4: 動画が普通に再生できたら安全ですか

普通に再生できることは安全の証拠にならない。大部分は正しくデコードされつつ、1つのフィールドがパーサを境界の外に追い出す、という構造にすることはできる。

Q5: YouTube や Google Drive のスキャンで検出できますか

クラウド側がスキャンしているのは既知マルウェアのシグネチャだ。特定のデマルチプレクサの中でだけ挙動がおかしくなる不正なメディアコンテナが引っかかる見込みは薄い。クラウドストレージを無害化の工程として数えないこと。

Q6: FFmpeg 自体が危険なソフトなのですか

そうではない。むしろこの記事の数字は、直しているプロジェクトの証拠であって、放置しているプロジェクトの証拠ではない。2026年7月のアドバイザリの修正は数日のうちに master に入っている。問題は「master で直っている」と「あなたの編集ソフトの中のコピーに載っている」の距離のほうで、そこは年単位になりうる。ちなみに FFmpeg のセキュリティページは、脆弱性報告における「a spike in AI generated, false positives（AI が生成した誤検知の急増）」に対処していることも書いている。これはこれでメンテナの負担だ。

Q7: HandBrake で再エンコードすれば無害化できますか

きれいな出力ファイルは作れる。FFmpeg と同じだ。そして同じ落とし穴も付いてくる。HandBrake も、そのために敵性の入力を自前の同梱 FFmpeg でデコードしなければならない。そのバージョンも確認し、作業は捨てられる場所でやること。

Q8: 字幕ファイル（.srt, .ass, .sub）もリスクですか

リスクだし、脚注扱いにできない。CVE-2026-64830——2026-07-22 公開、VulnCheck 採点で CVSS 8.8、2026-08-02 時点でどのリリースにも修正が入っていない——は、細工された .sub / .idx のペアで発火するヒープオーバーフローだ。出所不明の字幕ファイルは動画ファイルとまったく同じに扱うこと。

Q9: 編集ソフトは最新です。これで終わりですか

最も効く1手は済んでいるし、続けてほしい。ただし 2026-07-22 に公開された6件は、現行リリースである FFmpeg 8.1.2 を影響範囲に名指ししていて、修正は master にしかない。更新は年 単位の露出を閉じるが、週 単位の露出は閉じない。知らない相手から来たファイルには、その上に隔離を重ねること。

関連記事

• FFmpeg の商用利用ライセンス完全ガイド：LGPL・GPL・特許の考え方 — FFmpeg を製品に載せるなら、ライセンス遵守はもう一つの義務になる

まとめ

脅威モデルは具体的だ。編集ソフトの中の古い FFmpeg が、信用できない出所のファイル を処理し、そこでは拡張子はどのパーサが動くかを決めない。

実際にやること:

1. 編集ソフトを更新する。 年単位の露出がクリック1つで閉じる。他にこれに並ぶものは無い。
2. 内蔵バージョンを strings で読む。 上の表の「修正版」列と突き合わせる。
3. 出所不明のファイルは VM で開く。 そこで再エンコードし、形式が分かるなら -f でデマルチプレクサを固定する。
4. メンテナンスの止まったソフトを使うのをやめる。 慣れているかどうかは関係ない。

1つだけやるなら、編集ソフトを開いてバージョン情報を出し、日付を見る。1年以上前なら今日動くこと。

あなたのチャンネルとアーカイブと認証情報は、ソフトを更新する面倒より価値がある。

参考文献

• FFmpeg Download — 8.1.2 のリリース日・ライブラリバージョン・リリースブランチの cherry-pick 方針。2026-08-02 参照
• FFmpeg Security — リリースごとの修正 CVE、「AI generated, false positives」の記述。2026-08-02 参照
• NVD: CVE-2026-64830 — VobSub デマルチプレクサのヒープオーバーフロー、2.1–8.1.2。2026-08-02 参照
• NVD: CVE-2026-64831 — Vulkan HEVC のスタックオーバーフロー、8.0–8.1.2。2026-08-02 参照
• NVD: CVE-2026-64832 — NVDEC の double-free、4.4–8.1.2。2026-08-02 参照
• NVD: CVE-2026-64835 — ADX デコーダの境界外アクセス、4.4–8.1.2。2026-08-02 参照
• NVD: CVE-2026-40962 — MOV/MP4 の CENC 整数オーバーフロー、8.1 で修正。NVD 9.8 対 MITRE 4.9。2026-08-02 参照
• NVD: CVE-2024-7055 — PNM デコーダのヒープオーバーフロー、影響範囲と修正版。2026-08-02 参照
• NVD: CVE-2024-31578 — av_hwframe_ctx_init の use-after-free、7.0 と 6.1.3 で修正。2026-08-02 参照
• NVD: CVE-2022-3109 — VP3 の NULL ポインタ参照、5.0.3 で修正。2026-08-02 参照
• NVD: CVE-2019-17542 — VQA デコーダのヒープオーバーフロー、4.2 で修正。2026-08-02 参照
• NVD: CVE-2020-20891 — gblur フィルタのオーバーフロー。この脅威モデルがカバーしないCVE の例として引用。2026-08-02 参照
• VulnCheck advisory: FFmpeg VobSub heap overflow — CVE-2026-64830 の CNA アドバイザリ。2026-08-02 参照
• FFmpeg wiki: HWAccelIntro — プラットフォーム対応表。NVENC/NVDEC/CUVID と Vulkan は macOS・iOS で利用不可。2026-08-02 参照
• Ubuntu CVE tracker: CVE-2024-7055 — noble の修正版は 7:6.1.1-3ubuntu5+esm5（Ubuntu Pro / ESM）。2026-08-02 参照
• Ubuntu Pro — 個人利用は5台まで無料。2026-08-02 参照
• Kdenlive releases (KDE Invent) — 2026-07-30 までのリリースタグ。2026-08-02 参照