Windows 版のVNCビューアー（TightVNC 1.3.10 と、影響を受ける UltraVNC）に、ヒープベースのバッファオーバーフローの脆弱性（CVE-2026-128321）があると、CERT/CC が2026年11月13日に VU#644655 として公開しました。同じ日に JVN も JVNVU#92656681 として公開しています。VNC で別の PC に接続して操作する側、つまり「ビューアー」の脆弱性で、接続される側（VNC サーバー）の話ではありません。
結論から言うと、CERT/CC の勧めは UltraVNC は修正を含む現在サポートされている版へ更新し、TightVNC 1.3.10 の Windows 版ビューアーは、保守されている版か修正が確認された別の手段に置き換える、というものです。
VNCビューアーの脆弱性で何が起きるか
CERT/CC によると、問題があるのは、Windows 版のVNCビューアーで Tight JPEG をデコードする部分です。悪意のある VNC サーバーを操る攻撃者が、細工した画面の更新を送ると、ビューアーの中でメモリ破壊を起こせます。
- 成功すると、ビューアーが強制終了します
- 任意のコード実行を許すおそれがあります（CERT/CC の表現は may allow）
- コードが実行された場合は、ビューアーを動かしているユーザーの権限で実行されうる、とされています
ただし、検証で実際に示されたのはサービス拒否（強制終了）だけです。コード実行は「おそれ」の段階として読んでおくのが正確です。
原因は関数 DecompressJpegRect() にあります。最大の行幅を 8,192 ピクセルに固定してバッファを確保する一方で、変換はサーバーが送ってくる矩形の幅で行うため、幅が大きいとバッファの外に書き込んでしまいます。検証では、256 バイトの余白を含む割り当てで、幅 8,257 ピクセルから範囲外の書き込みが始まりました。
影響を受ける版と対処
CERT/CC の記載をもとに、ビューアーごとに整理するとこうなります。
| ビューアー（Windows 版） | CERT/CC の記載 | おすすめの対処 |
|---|---|---|
| TightVNC 1.3.10 | 影響を受ける。CERT/CC は TightVNC と連絡が取れず、修正の調整ができなかった | 保守されている版か、修正が確認された別の手段に置き換える |
| UltraVNC | CERT/CC によると、UltraVNC のリリースノートでは 1.8.2.8 で修正された | 修正を含む現在サポートされている版（CERT/CC の例は 1.8.3.1）へ更新する |
なお、CERT/CC のベンダー情報の欄では UltraVNC の状態が Not Affected と表示されていますが、概要では影響を受ける UltraVNC の Windows 版ビューアーとされ、対処の欄では、UltraVNC のリリースノートによると 1.8.2.8 で修正されたと書かれています。
UltraVNC の GitHub には、バッファを実際の幅に合わせて確保し、0 以下や範囲外の矩形サイズを拒否するようにした修正コミット（d9a22c8、2026年9月20日 UTC）があります。UltraVNC の公式ダウンロードページでは、最新のリリース版は UltraVNC 1.8.3.2 と案内されています（2026年11月14日時点）。
TightVNC については、CERT/CC は2026年9月21日に Glavsoft（TightVNC）へ通知しましたが、TightVNC と連絡が取れず、修正の調整ができなかったとしています。CERT/CC のベンダー情報の欄では Glavsoft（TightVNC）の状態は Unknown で、CERT/CC はベンダーから声明を受け取っていないとしています。TightVNC の公式ダウンロードページでは、1.3.10 は v.1（Legacy）の区分で、これとは別に v.4（Current、Windows 版 4.0.2）と v.2（Supported）があります。
注意したいのは、TightVNC 2.x・4.x のビューアーが影響を受けるかどうかは、CERT/CC の発表には書かれていない点です（対象として明記されたのは 1.3.10 の Windows 版ビューアーだけ）。深刻度（CVSS のスコア）も、CERT/CC・JVN とも示されていません。
悪意のあるサーバーからの悪用は認証や暗号化で防げない
悪用には、脆弱なビューアーが、攻撃者の用意した VNC サーバーか、乗っ取られた VNC サーバーに接続し、細工された更新を処理する必要があります。逆に言えば、つないだ先のサーバーが悪意を持っていれば、認証や通信の暗号化があっても防げません。CERT/CC も、セッションに参加している悪意のあるサーバーによる悪用は、認証・暗号化では防げないとしています。
修正版を入れるまでの間は、信頼できる VNC サーバーにだけ接続するよう CERT/CC は求めています。ただしこれは露出を減らすだけで、信頼しているサーバーが乗っ取られた場合は防げません。いつもの店だから安心、と思っていても、厨房ごと乗っ取られていたら出てくる料理は選べない、というのと同じです。
VNCビューアーでやっておきたいこと
おすすめの順に並べます。
- 使っているVNCビューアーと版を確かめる: Windows で TightVNC 1.3.10 や UltraVNC のビューアーを使っていないかを見ます。接続する側の PC が対象です
- UltraVNC は更新する: 修正を含む現在サポートされている版へ上げます。CERT/CC は例として 1.8.3.1 を挙げており、公式ダウンロードページの最新のリリース版は 1.8.3.2 です
- TightVNC 1.3.10 は置き換える: 保守されている版か、修正が確認された別の手段へ移ります。TightVNC 2.x・4.x が影響を受けるかは上のとおり発表に書かれていないので、置き換え先はその点も踏まえて選びます
- 置き換えまでは接続先を絞る: 信頼できる VNC サーバーにだけ接続します。露出を減らす手段で、乗っ取られたサーバーは防げない点は頭に入れておきます
まとめ：VNCビューアーは接続する側を見直す
- CVE-2026-128321 は、Windows 版のVNCビューアー（TightVNC 1.3.10 と、影響を受ける UltraVNC）の脆弱性で、CERT/CC と JVN が2026年11月13日に公開しました
- 悪意のある VNC サーバーに接続すると、強制終了が起き、任意のコード実行を許すおそれがあります（検証で示されたのは強制終了だけ）
- 接続先が悪意のあるサーバーなら、認証や暗号化では防げません。UltraVNC は更新、TightVNC 1.3.10 は置き換え、が CERT/CC の勧めです
サーバー側ばかり気にしがちですが、今回はつなぎに行く側のVNCビューアーの話です。腹八分目で、まずは自分の PC に入っているビューアーの版を確かめておきましょう。
ほかの技術ネタは、技術ネタの記事一覧からどうぞ。
2026年11月14日時点の、CERT/CC と JVN（どちらも2026年11月13日公開）の情報にもとづきます。
ITもごはんも、腹八分目が長続きのコツ！
コメント