国産のテキストエディタ「サクラエディタ」に、OSコマンドインジェクションの脆弱性（CVE-2026-59561）が公表されました（JVN#74538868、2026年8月24日公開）。細工された名前のフォルダに置いたファイルを編集中に「ターミナルを起動」機能を使うと、任意のOSコマンドが実行される可能性があります。CVSS v4.0で8.4、v3.0で7.8。修正版はv2.4.3です。
ただし、この記事で本当にお伝えしたいのはそこではありません。v2.4.3が直したセキュリティ問題は8項目あるのに、CVEが振られJVNに載ったのはそのうち1件だけという点です。しかもv2.4.3は、前バージョンv2.4.2から3年8か月ぶりのリリースでした。JVNの注意喚起を入口に脆弱性管理をしている現場ほど、実像を取りこぼしやすい構図になっています。
この記事でわかること
- CVE-2026-59561の中身と、実際に踏むことになる場面
- v2.4.3で修正された8項目のうち、JVNに載ったのは1件だけという事実
- 3年8か月ぶりの更新であることが、社内の資産管理に何を意味するか
- 自社に入っているかを確認する具体的な手順（ビルド番号の落とし穴つき）
サクラエディタとは何者か
サクラエディタとは、Windows向けの日本語テキストエディタです。サクラエディタ開発コミュニティが開発するオープンソースソフトウェアで、Grep（複数ファイル横断検索）、矩形選択、文字コード自動判別、マクロといった機能を備えています。
使うのは開発者だけではありません。設定ファイルやログを開く、CSVを直す、バッチファイルを書くといった作業で、情シス・運用担当・業務部門が日常的に使っています。「作業手順書に『サクラエディタで開く』と名指しで書いてある」という現場も珍しくないはずです。
厄介なのは、どこから入ったかが追いにくいことです。配布物はGitHubのリリースページにインストーラ版とzip版（実行ファイルのみ）の2種類が置かれており、zip版は解凍して置くだけで動きます。つまりWindowsの「インストールされているプログラム」に登録されず、資産管理ツールのソフトウェア一覧に出てきません。以前取り上げたTera Termの脆弱性とまったく同じ構図です。「うちは配っていない」ではなく「置かれていないか」を探す必要があります。なおGitHubのリリースAPIで実測すると、v2.4.2のダウンロード数は約254万回（2026年8月24日時点）。導入台数ではありませんが、桁の感覚はつかめます。
何が起きたのか：CVE-2026-59561
サクラエディタには「ターミナルを起動」する機能があり、編集中のファイルが置かれたディレクトリをカレントディレクトリとしてシェルを起動します。このとき、ディレクトリ名を表す文字列を無害化せずに使っていました（JVNの記述）。結果として、フォルダ名に仕込まれた文字列がコマンドとして解釈されます。開発側のアドバイザリとリリースノートでは、この機能を「PowerShellを開く」「PowerShellを管理者として開く」と呼んでいます。メニュー上の表記が異なるので、社内周知の際は両方の呼び名を添えると確実です。
| 項目 | 内容 |
|---|---|
| CVE | CVE-2026-59561（CWE-78 OSコマンドインジェクション） |
| アドバイザリ | JVN#74538868 / JVNDB-2026-000115 / GHSA-6x2x-729r-wjh5 |
| CVSS v4.0 | 8.4（AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N） |
| CVSS v3.0 | 7.8（AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H） |
| 影響を受けるバージョン | v2.4.3 より前のすべて |
| 修正版 | v2.4.3（2026年8月8日公開） |
| NVDの状態 | Awaiting Analysis（スコアはCNAであるJPCERT/CCの値） |
どういう場面で踏むのか
AV:L（ローカル）かつUI:A（利用者の操作が必要）なので、遠隔から一方的に撃たれるタイプではありません。成立には「攻撃者が名前を決めたフォルダ」が端末上に置かれ、利用者がその中のファイルを開き、さらにターミナル起動機能を使う、という流れが必要です。
ただ、そのお膳立ては業務のなかで普通に起きます。メールやチャットで受け取ったzipを解凍する、共有フォルダやNAS上のフォルダを開く、ファイル転送サービスから落としたフォルダを開く。いずれもフォルダ名は送り手が決めており、zipの中のフォルダ名まで確認してから解凍する人はまずいません。そして、この機能を使うのはターミナルを日常的に開く層＝情シスや運用担当です。管理者権限で作業していれば、そのままの権限でコマンドが走ります。LINE PC版インストーラの事例と同様、「利用者の手元で成立する脆弱性」は影響を受ける端末の重要度で評価すべきです。
JVNに載ったのは、修正8項目のうち1件だけ
ここが本題です。v2.4.3のリリースノートの「セキュリティ修正」欄には8項目が並んでおり、CVEが採番されJVNに載ったのは、このうち先頭の1件だけです。
| 修正内容 | アドバイザリ | 深刻度 | CVE / JVN |
|---|---|---|---|
| 「PowerShellを開く」機能のOSコマンドインジェクション | GHSA-6x2x-729r-wjh5 | High（7.8） | CVE-2026-59561 / JVN#74538868 |
| キーワードヘルプ辞書インポートのバッファオーバーフロー 等 | GHSA-hmv4-c8rc-fq53 | High（7.0） | なし |
| WSHマクロ経由のExecCmdスタックバッファオーバーフロー | GHSA-g26p-p558-cmwj | High | なし |
| 制御プロセス起動時、プロファイル名によるスタックバッファオーバーフロー | GHSA-jg35-7phr-86wq | Medium | なし |
| 長いファイルパスによるViewDiffInfo / TagsMakeのオーバーフロー | GHSA-jpr9-7379-v6m7 | Low | なし |
| CUtf7の書き込み範囲チェック漏れ | PR #1869 | ― | なし |
| CopyDirDirのバッファオーバーフロー | PR #2501 | ― | なし |
| ファイルダイアログの出力先バッファサイズ不整合 | PR #2530 | ― | なし |
CVEが付いていない側にも、開発側がHighと評価したものが2件あります。たとえばGHSA-hmv4-c8rc-fq53は、キーワードヘルプ辞書のインポート機能でパス文字列を長さ検査なしに固定長バッファへコピーしていたというもの。アドバイザリには公式のv2.4.2バイナリで実際にアクセス違反を発生させ、フォルト先アドレスが攻撃者の入力に由来することまで確認した、という検証結果が記載されています。CVEが無いから軽い、ということではありません。
なぜこうなるのか
CVE採番とJVN掲載は深刻度順に自動で行われるものではなく、誰かが届け出て、調整機関が動いたものだけが載る仕組みです。JVN#で始まる番号は国内の「情報セキュリティ早期警戒パートナーシップ」経由の届出案件を意味します（海外CERT由来はJVNVU#）。つまりJVNへの掲載有無は、危険度ではなく情報の流通経路で決まります。
実務上の意味は明快です。JVNやIPAの注意喚起だけを入口にしていると、OSSの修正の大部分は見えません。対象ソフトについては、GitHubのリリースノートとSecurity Advisories（https://github.com/<org>/<repo>/security/advisories）を直接見る運用を併用する必要があります。ウォッチ登録しておけば更新通知も受け取れます。
3年8か月ぶりの更新、という別の問題
リリース履歴を並べると、この更新の重さが見えてきます。
| バージョン | 公開日 | ダウンロード数（2026-08-24時点） |
|---|---|---|
| v2.4.1 | 2020年5月30日 | 約122万回 |
| v2.4.2 | 2022年12月10日 | 約254万回 |
| v2.4.3 | 2026年8月8日 | 約4.6万回 |
v2.4.2からv2.4.3までの差分は1,600コミット。「脆弱性を直しただけのパッチ」ではなく、実質的に大型アップデートです。実際、リリースノートの「仕様変更」欄には動作環境をWindows 10以降に変更（Windows 7 / 8.1のサポート終了）が入っており、ファイル読み込みのマルチスレッド化など挙動に影響しうる変更も含まれます。
セキュリティ修正が破壊的変更とセットで来る典型的な形です。「脆弱性対応だから即日展開」と単純に判断できず、動作検証の工数が乗ります。とくに古い端末が残っている環境や、マクロを業務手順に組み込んでいる環境では、そのまま入れ替えると止まる可能性があります。展開計画には検証期間を見込んでください。
ダウンロード数の対比も示唆的です。v2.4.2が3年8か月かけて約254万回に対し、v2.4.3は公開から16日で約4.6万回。母数も期間も違うので移行率そのものではありませんが、「入れ替えはこれから」という段階であることは間違いありません。自動更新の仕組みがないソフトは、情シスが動かない限り古いまま残ります。
自社に入っているかを確認する
資産管理ツールのソフトウェア一覧だけでは足りません。次の順で見てください。
- ファイル名で探す：端末・ファイルサーバ・共有フォルダを対象に
sakura.exeを検索します。zip版は任意の場所に置けるため、Program Files以外も対象にしてください。 - バージョンを確認する：実行ファイルのプロパティ（詳細タブ）、またはメニューの「ヘルプ」→「バージョン情報」で確認します。
- ビルド番号で判断しない：配布ファイル名を見ると、v2.4.2は
build4203、v2.4.3はbuild2916です。バージョンが上がったのにビルド番号は下がっています。数値の大小で新旧を判定する運用をしていると誤判定します。判断はv2.4.xの値で行ってください。 - 手順書・バッチを検索する：作業手順書やスクリプト内の「サクラエディタ」「sakura.exe」を全文検索すると、公式には配っていない導入経路が見つかります。
更新方法は入れ替えです。インストーラ版は上書きインストール、zip版は実行ファイルの差し替えになります。入手元は公式のリリースページに固定してください（配布版がすり替えられた事例もあります）。
対策の考え方は公的指針に沿わせる
個別ソフトごとの対応を積み上げるより、ソフトウェア資産の把握と更新の仕組み自体を整えるほうが結局は早く済みます。IPAの中小企業の情報セキュリティ対策ガイドラインは資産管理と更新運用の考え方を含めて整理されており、社内説明の下敷きにも使えます。利用者への啓発には対策のしおりが扱いやすいでしょう。
今回のケースで利用者に伝えるべきことは、ひとつに絞れます。「受け取ったzipや共有フォルダを開いた直後に、そのフォルダでターミナルを起動しない」。更新が行き渡るまでの暫定的な緩和策として、この一行だけでも周知しておく価値があります。
現場目線の所感
正直なところ、この手のソフトがいちばん困ります。全社に配ったわけでもなく、禁止しているわけでもなく、気づけばあちこちの端末に置かれている。しかも便利なので誰も手放したがらない。台帳に載っていないものを更新しろと言われても、まず「どこにあるか」から始めることになります。
もうひとつ実感するのは、「JVNに載った1件」と「実際に直った8項目」の差です。脆弱性管理の運用はどうしてもCVE番号を単位に回るため、番号がないものは台帳に起票されず、起票されないものは対応されません。今回のように開発側が自らHighと評価した問題がCVEなしで直されているケースは、その運用の外側で静かに積み上がります。とはいえ対象ソフトすべてのGitHubを見に行くのは非現実的なので、まずは「社内で広く使われている、自動更新のないソフト」を10本ほど選んでリリース通知を登録するあたりが、現場で続けられる落としどころだと思います。サクラエディタは、その10本に入る類のソフトです。
まとめ
- サクラエディタ v2.4.3未満にOSコマンドインジェクションの脆弱性（CVE-2026-59561、CVSS v4.0で8.4）。細工されたフォルダ名の場所で「ターミナルを起動」機能を使うと任意コマンドが実行されます。修正版はv2.4.3。
- v2.4.3が直したセキュリティ問題は8項目あり、CVE・JVNに載ったのは1件だけ。CVEの有無は危険度ではなく届出経路で決まります。OSSはリリースノートとGitHub Advisoryを直接見る運用が要ります。
- 3年8か月ぶり・1,600コミットの更新で、Windows 7/8.1のサポート終了を含みます。即日展開ではなく検証工数を見込みつつ、zip版が台帳外に置かれていないかをファイル名で洗い出してください。
出典
- JVN#74538868 サクラエディタにおけるOSコマンドインジェクションの脆弱性（2026年8月24日公開）
- JVNDB-2026-000115
- NVD – CVE-2026-59561
- sakura-editor/sakura Release v2.4.3（2026年8月8日公開）
- GHSA-6x2x-729r-wjh5 ほか、同リポジトリのSecurity Advisories
- IPA 中小企業の情報セキュリティ対策ガイドライン / 対策のしおり
