Notepad++、v8.9.7で5件の脆弱性を修正(CVE-2026-54758,CVE-2026-52886)過去の中国系APT乗っ取り事件を踏まえ要注意|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年07月17日更新日時: 2026年07月17日

無料のテキスト/コードエディタ「Notepad++」の開発元は2026年7月、最新版v8.9.7(コードネーム「Slava Ukraini」)を公開し、スタックバッファオーバーフローから自動更新機能(WinGUp)のパストラバーサルまで、5件のセキュリティ脆弱性を修正しました。当サイトで既報の通り、Notepad++の更新機能は2025年6月から12月にかけて、中国系とみられる国家支援型ハッカーによって実際に乗っ取られた経緯があり、今回修正された5件のうち2件が更新機構に直接関わる点は、この経緯を踏まえると特に注意が必要です。

サマリー

Notepad++の開発元は2026年7月、世界中の開発者・IT管理者を含む数百万人のWindowsユーザーが利用するオープンソースのテキストエディタの最新版v8.9.7を公開し、5件のセキュリティ脆弱性を修正した
最も深刻とされるのはCVE-2026-54758で、expandNppEnvironmentStrs関数におけるスタックバッファオーバーフローの脆弱性。境界チェックが不十分な環境変数文字列を細工して渡すことで、メモリ破損や条件によっては任意コード実行につながる恐れがある
設定ファイルの取り扱いに関する脆弱性としては、CVE-2026-52886(session.xmlのbackupFilePathフィールドにおけるstarts_with検証の回避によるパス検証の迂回)と、CVE番号未採番のshortcuts.xmlにおけるマクロのHMAC検証回避(悪意あるマクロ定義の改ざんを検知できなくなる)の2件がある
企業環境にとって特に懸念されるのは、Notepad++の自動更新コンポーネント「WinGUp」におけるZip Slip(パストラバーサル)脆弱性CVE-2026-57233。アーカイブ展開時のパス検証が不十分な場合、細工されたZIPファイルによって意図しないファイルシステム上の場所へファイルが書き込まれる可能性があり、更新パッケージの傍受・偽装が可能な攻撃者によって、更新プロセスの権限でコードが実行される恐れがある
このほか、CVE番号未採番のインストーラーにおけるPowerShellコマンドインジェクションの脆弱性も修正されている。インストール時のスクリプト処理における入力のサニタイズが不十分な場合、注入されたコマンドがインストーラーの権限で実行される可能性がある
開発元は、5件のうち2件が更新機構自体に直接関わる点を踏まえ、自動更新を待たず手動での更新適用を、特にエディタが高い権限で動作している環境や機微な設定ファイルを扱う環境では優先するよう推奨している
Notepad++の自動更新機能は、大きな不具合(リグレッション)が見つからなければ、2週間以内に自動的にこのリリースをユーザーへ配信する予定とされている

CVE ID	脆弱性	対象コンポーネント
CVE-2026-54758	expandNppEnvironmentStrsにおけるスタックバッファオーバーフロー	環境変数文字列の展開処理
CVE-2026-52886	session.xmlのbackupFilePath starts_with検証回避	セッションファイル処理
CVE-2026-57233	Zip Slip(パストラバーサル)	自動更新機能WinGUp
未採番(GHSA-f4rj-vqq4-wvg4)	shortcuts.xmlのマクロHMAC検証回避	マクロ整合性検証
未採番(GHSA-gp2r-262h-9hgf)	PowerShellコマンドインジェクション	インストーラー

1 何が起きたか
2 企業環境で特に注意すべき更新機構(WinGUp)の脆弱性
3 過去の乗っ取り事件との関連
4 情報システム部門への示唆
5 出典

何が起きたか

Notepad++の開発元が公開したv8.9.7には、5件のセキュリティ修正が含まれています。最も深刻とされるCVE-2026-54758は、expandNppEnvironmentStrs関数におけるスタックバッファオーバーフローの脆弱性です。アプリケーションがスタック上のメモリバッファに割り当てられた容量を超える入力を適切に検証しないまま処理してしまうことに起因し、条件次第ではアプリケーションのクラッシュ、メモリ破損、さらには任意コード実行につながる可能性があります。実際の悪用のしやすさは、攻撃者が脆弱な環境変数展開処理へどれだけ容易に到達できるかに左右されます。

設定ファイルの取り扱いに関する脆弱性も2件修正されています。CVE-2026-52886は、session.xml内のbackupFilePathフィールドに対するstarts_with検証を回避できる脆弱性です。パスが承認済みディレクトリから始まっているように見えても、正規化やトラバーサル処理を経た後に別の場所を指してしまう場合、この検証方式は安全とはいえません。悪意あるセッションファイルを用いることで、意図されたパス制限を回避できる可能性があります。開発元は、ファイルパスの正規化を強化することでこの問題に対処したとしています。もう1件、CVE番号がまだ割り当てられていないshortcuts.xmlにおけるマクロのHMAC検証回避の脆弱性もあり、悪意あるマクロ定義の改ざんを、本来の整合性検証の仕組みをすり抜けて検知されないまま行える可能性があります。

企業環境で特に注意すべき更新機構(WinGUp)の脆弱性

今回の5件のうち、企業環境にとって特に懸念されるのは、Notepad++の自動更新コンポーネントである「WinGUp」に関する2件です。1件目のCVE-2026-57233は、Zip Slip(パストラバーサル)と呼ばれる種類の脆弱性で、アーカイブ展開時のエントリパスに対する検証が不十分な場合に発生します。攻撃者はアーカイブのエントリ名に「../」のようなトラバーサルシーケンスを埋め込むことで、悪意あるZIPファイルを通じ、意図された展開先ディレクトリの外側にあるファイル(アプリケーションの設定パスや起動関連ディレクトリを含む)を上書きできる可能性があります。更新パッケージを傍受または偽装できる攻撃者がいた場合、この脆弱性は更新プロセスの権限でのコード実行につながりかねません。もう1件は、CVE番号がまだ割り当てられていない、インストーラーにおけるPowerShellコマンドインジェクションの脆弱性です。インストール時のスクリプト処理における入力のサニタイズが不十分な場合、注入されたコマンドがインストーラーの権限で実行される可能性があります。

過去の乗っ取り事件との関連

当サイトで既報の通り、Notepad++の更新機能を巡っては、2025年6月から同年12月にかけて、中国系とみられる国家支援型のハッカーグループによって、更新トラフィックが実際に乗っ取られる深刻な事件が発生していました。この事件では、Notepad++本体のコードではなく、更新配布インフラ(ホスティング環境)側が侵害され、特定の標的となったユーザーだけが選択的に悪意あるサーバーへリダイレクトされるという、高度に選別的な攻撃が行われていたことが2026年2月に公表されています。セキュリティ企業Rapid7は、この事件を中国系APTグループLotus Blossomによる作戦と分析し、「Chrysalis」と名付けた未文書化のバックドアの存在を報告していました。この事件を受け、開発元は同年2月にv8.9.2を公開し、更新情報(XML)と配布物(インストーラー)をそれぞれ別系統で検証する「二重ロック」方式を導入するなど、更新経路の堅牢化を進めてきた経緯があります。

今回のv8.9.7で修正された2件の更新機構関連の脆弱性(WinGUpのZip SlipとインストーラーのPowerShellコマンドインジェクション)は、直接この過去の乗っ取り事件と関連付けられているわけではありません。しかし、まさにこの更新機構こそが過去に国家支援型ハッカーの標的となった実績がある以上、同じコンポーネントに新たな脆弱性が見つかったという事実は、通常のオープンソースソフトウエアの脆弱性以上に注意を払うべき理由になります。

情報システム部門への示唆

Notepad++の開発元自身が指摘している通り、5件のうち2件が更新機構自体に直接関わる以上、セキュリティチーム・IT管理者は自動更新のロールアウトを待つのではなく、手動での更新適用を優先することをお勧めします。特に、エディタが昇格した権限で動作している環境や、機微な設定ファイルを取り扱う環境では、この対応がより重要になります。

自組織でNotepad++を組織全体に展開している場合は、今回のv8.9.7への更新に加え、過去の乗っ取り事件を踏まえた恒久的な対策として、gup.exe(Notepad++のアップデータ)がnotepad-plus-plus.org、github.com、release-assets.githubusercontent.com以外のドメインへ通信していないかを監視することをお勧めします。パッケージ管理ツールで社内展開・更新を行っている大規模組織では、notepad-plus-plus.orgへの通信自体をブロックするか、gup.exeプロセスのインターネットアクセスを制限したうえで、パッケージ管理側で明示的にバージョンを制御する運用も選択肢になります。あわせて、当サイトで以前紹介した二重ロック機構(v8.9.2以降で導入)が有効になっているか、そして今回のv8.9.7がその機構を経て正しく検証済みのソースから配布されているかを確認することも、サプライチェーンリスクを軽減するうえで重要です。