LibVNCに重大脆弱性 CVE-2026-44988、悪意あるVNCサーバに接続するだけでPC乗っ取り

Linuxのリモートデスクトップソフトの多くが内部で使っているオープンソース基盤「LibVNCClient」に、CVSS 8.8（高）の重大脆弱性CVE-2026-44988が見つかりました。プロジェクトは2026年5月6日にGitHub Security Advisory（GHSA-jcc5-8wj4-7c58）として開示し、5月27日にNVDが正式登録しました。

これまでのVNC関連の脆弱性と決定的に違うのは「攻撃の方向」です。通常イメージされるのは「リモートデスクトップサーバ側に侵入される」リスクですが、今回の脆弱性は逆向き、つまり悪意ある側がVNCサーバを立て、そこに接続させたユーザーのクライアントPCを乗っ取るという構図です。被害を受けるのは「他人のPCをリモート操作しに行った側」、つまりIT管理者や保守担当者です。

影響を受ける可能性のあるソフトには、Linuxで定番のリモートデスクトップクライアントRemmina、KDEのKRDC、AndroidのAVNC、防犯カメラ録画システムのZoneMinderなどがあります。修正コードは既にmasterブランチに入っていますが、本記事執筆時点（2026年5月28日）で正式リリースタグはまだ出ておらず、対症療法的な運用対応が必要な状態です。

LibVNCとは何か

VNC（Virtual Network Computing）は、ネットワーク越しに別のパソコンの画面を見て操作する古典的な仕組みです。離れた拠点のサーバを管理する、家族のPCを直接見ながらサポートする、職場のPCに自宅から繋ぐ、といった用途で使われています。WindowsのリモートデスクトップやTeamViewerと似た役割ですが、VNCは仕様がオープンで、多くのフリーソフトが互換実装を出しています。

LibVNCServer/LibVNCClientは、その互換実装の「土台部品」です。VNCの通信プロトコル、画面圧縮、暗号化などをC言語のライブラリとしてまとめており、自分でVNCソフトを書きたい開発者が呼び出す形になっています。LibVNCServer側は「画面を配信する側」、LibVNCClient側は「画面を見に行く側」を担当します。

公式が把握しているだけでも、このライブラリを内部で使っているソフトはおよそ次の通りです。今回の脆弱性はクライアント側の処理に存在するため、影響を受けるのはLibVNCClientを組み込んでいる「画面を見に行く側」のソフトに限られます。

日本でも、社内サーバ運用、研究室の計算機管理、家庭内NASやRaspberry Piの遠隔操作などで、これらのソフトの利用は珍しくありません。特に Remmina は Ubuntu や Debian などで標準パッケージとして配布されており、Linuxユーザーが「最初に入れるリモートデスクトップソフト」の定番でもあります。

通常と逆の構図：「接続しに行った側」が攻撃される

VNCの脆弱性のニュースで多いのは「VNCサーバが攻撃されてサーバ内部に侵入される」パターンです。今回のCVE-2026-44988は逆方向で、攻撃者が用意したVNCサーバに接続したクライアントが、その接続だけでメモリ書き換えを受けるという構造になっています。

攻撃シナリオはたとえば次のようなものが想定されます。

• SNSやチャットで「うちのデモサーバに見に来てくれ」とURLを送り、クライアントを接続させる
• 正規のVNCサーバに偽装したフィッシングサイトでパスワードを公開し、接続を誘導する
• 社内ネットワーク内に侵入した攻撃者が、IT管理者のリモート保守接続を待ち伏せして偽サーバに誘導する（中間者攻撃）
• マルウェアに感染した別マシンが「いつものVNCサーバ」になりすますDNS書き換えで誘導する

CVSSベクトルの「UI:R」（User Interaction Required、ユーザー操作が必要）はこの「接続する」という操作を指します。攻撃成立にはユーザー側の能動的な接続が必要ですが、IT管理者が「いつものVNC接続」のつもりで作業した結果、自分のPCがやられる、という流れは普段の業務動作の中に紛れ込みます。

CVE-2026-44988の中身：Tightエンコーダの2048ピクセル固定バッファ

脆弱性の根本原因は、LibVNCClientのsrc/libvncclient/tight.cに存在します。NVDの分類はCWE-787（境界外書き込み）。VNCの画面圧縮方式の1つであるTightエンコーディングを処理する部分です。

Tightエンコーディングは、画面の各ブロックを「平面色」「JPEG画像」「Gradient（連続的な色変化）」などのサブエンコードに分けて圧縮する方式で、TightVNCチームが開発したものです。問題はGradientサブエンコードの処理にあります。LibVNCClientはこの処理用に、横幅2048ピクセル分の固定サイズのバッファを使っていました。

VNCサーバは、クライアントに対して「これから幅3000ピクセルの画像を送る」と申告できます。LibVNCClientは申告された幅rwを信用し、内部の固定2048ピクセルバッファに対してmemset(client->tightPrevRow, 0, rw * 3)のような書き込みを実行していました。rwが2048を超えていれば、確保したメモリ領域の境界を越えて書き換えが進みます。

境界を越えて書き換えられるメモリの先には、LibVNCClient内部のrfbClient構造体のコールバック関数ポインタ（プログラムが「次に呼び出す関数」を指す住所）が並んでいます。これを攻撃者の用意したコードのアドレスに書き換えられれば、その後の処理でLibVNCClientプロセスが攻撃者のコードを実行する流れになります。GitHubのアドバイザリでは「制限付きの読み書きプリミティブが実験室環境で実証されており、RCE級の影響が想定される」と評価されています。

修正はコミット5b27054で入っており、TIGHT_GRADIENT_MAX_WIDTHマクロ定数を新設して、幅が2048を超えるリクエストを受け取った時点で処理を中断する、シンプルな入口チェックの追加です。

修正リリースはまだ出ていない（2026年5月28日時点）

CVE-2026-44988の最大の難しさは、修正コードはmasterブランチに入っているのに、リリースタグが付いた正式版がまだ公開されていない点です。LibVNCServerのリリースページを見ると、現行の最新版は v0.9.15 のままで、修正コミットを含むタグはまだ切られていません。

これが何を意味するかというと、Ubuntu や Debian、Arch Linux などのディストリビューションが配布している Remmina や KRDC は、しばらくの間「脆弱なLibVNCClientを内部に含んだまま」になります。各ディストリのセキュリティチームが個別パッチを当てて配布するか、LibVNC側が新バージョンをタグ付けするのを待つ必要があります。

同じく、Windows / macOS版の Remmina や AVNC （Android）も、各プロジェクトが新しい LibVNCClient を取り込んでビルドし直すまで、利用者側は脆弱なバイナリを使い続けることになります。コンテナイメージや家庭用NAS（Synology、QNAP など）に同梱されているVNC関連の機能も、ベンダー側の対応待ちになる場合があります。

いますぐやるべきこと

修正版が降りてくるまでの間、運用側でできる対症療法は次の通りです。

1. 信頼できないVNCサーバへの接続を避ける。 業務で使うVNC接続先は、自社が管理しているサーバや、契約先の検証済みサーバに限定します。SNS経由・チャット経由で「ちょっと見てくれ」と渡されたVNC接続URLには、しばらくの間はアクセスを控えるのが安全です。

2. 接続経路を限定する（VPN/SSHトンネル）。 VNCはそもそも認証や暗号化が弱いプロトコルとして長年知られており、生のVNC接続をインターネット越しに行うこと自体を避け、VPN内、または SSH ポートフォワーディング経由で接続する運用に切り替えるのが望ましい状態です。中間者攻撃で偽サーバに誘導されるリスクも、この段階で大きく下げられます。

3. ディストリビューションのセキュリティ更新を毎日確認。 Ubuntu/Debian系なら apt list --upgradable | grep -E "vnc|remmina|krdc" 程度の簡易チェックでも、関連パッケージの更新有無を確認できます。各ディストリのセキュリティアドバイザリ（USN、DSA等）でLibVNCに関するアナウンスを優先的にウォッチします。

4. リモート保守のオペレーションを見直す。 「いつものVNCサーバに接続するだけ」が攻撃面になっている以上、保守担当者向けに「未知のサーバへの新規接続は二段階確認」「初回接続時のフィンガープリント検証」など、運用ルール側で守る仕掛けが有効です。社内のIT保守用VNCサーバが外部から接続可能なネットワーク設計になっていないかも、この機会に点検する価値があります。

5. LibVNCClientを組み込んでいる自社プロダクトの棚卸し。 自社製品が内部でLibVNCClientを使っている場合（リモートサポートツールや組み込み機器のリモート画面確認機能など）、修正コミットを取り込んだフォーク版をビルドして配布する、もしくは正式リリースを待ってからアップデートを案内する判断が必要になります。

VNCはなぜ繰り返し脆弱性が出るのか

VNCは1998年にAT&T研究所で開発された古いプロトコルで、設計当時は社内LANでの利用を前提としていました。プロトコル仕様には認証や暗号化の強い仕組みがなく、画像圧縮処理もC言語で書かれた歴史の長いコードベースに依存しています。

過去にも、2019年にKaspersky ICS CERTがLibVNCServer、LibVNCClient、TightVNC、TurboVNC、UltraVNCの計4製品に37件のCVEを見つけて開示しています。共通する問題は「画面更新パケットの長さやサイズフィールドを信用しすぎる」古典的なバッファ管理の甘さで、CVE-2026-44988もその系譜の上にあります。

攻撃者の関心は、VNCを使うエンタープライズ環境やIT管理者の作業端末への足場確保にあります。CISA KEVダッシュボードでも過去に複数のVNC関連CVEがランサムウェアグループに使われた記録があり、今回のCVE-2026-44988も今後数か月以内に悪用観測が出る可能性は十分にあります。

同種の「OSS依存先に潜む未パッチCVE」を継続的に追うには、自社の使っているライブラリ群を依存関係ごとスキャンする仕組みが必要です。本サイトのOSSサプライチェーン・スキャナーからは、LibVNCを含むOSSパッケージの最新CVE状況をまとめて確認できます。今回のように修正リリースが出るまでに時間がかかる脆弱性については、影響範囲の早期把握が運用判断の鍵になります。

参照元

• ▸ NVD - CVE-2026-44988 Detail（2026年5月27日登録）
• ▸ GitHub Security Advisory - GHSA-jcc5-8wj4-7c58（2026年5月6日公開）
• ▸ GitHub commit 5b27054 - libvncclient: fix Tight gradient decoding overflow
• ▸ LibVNCServer/LibVNCClient 公式ページ（下流プロジェクト一覧含む）
• ▸ GitHub - LibVNC/libvncserver Releases
• ▸ Kaspersky ICS CERT - VNC vulnerability research（過去のVNC関連37件CVE）
• ▸ Remmina 公式サイト
• ▸ CISA - Known Exploited Vulnerabilities Catalog