WebSAM WinShareの脆弱性3件：影響版の判定と修正モジュール適用の手順

NECのリモート操作ソフトWebSAM WinShareに、認証なしでSYSTEM権限のコマンド実行を許す脆弱性を含む3件が2026年11月9日に公表されました。CVE-2026-113362〜113364は影響を受ける版の範囲がそれぞれ異なるため、「7.7系だから全部該当」という読み方では判定を誤ります。この記事では、版ごとの対象CVEを判定するスクリプト、31300番ポートの棚卸しと通信元の制限、修正モジュールの扱い、侵害の点検までを実装者の目線で整理しました。記載内容は2026年11月10日時点の公開情報にもとづきます。

まとめ：WinShareは31300番の到達範囲の制限と修正モジュール適用が先決

CVE-2026-113363と113364はCVSS v3.0で9.8、認証もユーザーの操作も要りません。WinShareが動く端末に細工したパケットが届けば、SYSTEM権限で任意のコマンドやコードを実行されます。公告に回避策の記載はなく、対処はNECサポートポータルで配布される修正モジュールの適用です。

作業の順番は3段階に分かれます。最初に、WinShareの導入端末と版、31300番が届く範囲を洗い出す。次に、修正モジュールを当てるまでの間、操作元のIPアドレスだけに通信を絞る。最後に、モジュールの適用と適用記録の保存、侵害の点検へ進みます。

Ver7.8はどのCVEの対象にも掲載されていません。悪用の報告も2026年11月10日時点の公告には記載がありませんが、公表直後は攻撃側も修正内容を調べ始める時期なので、到達範囲の制限は当日中に進めてください。

CVE-2026-113362〜113364の中身とSYSTEM権限を奪われる条件

WebSAM WinShareは、サーバーやPC、POS端末を遠隔から操作するNECのソフトウェアです。操作する側をオペレーションPC、操作される側をリモートPCと呼びます。OS標準のリモートデスクトップと同じく端末の全操作を握る製品なので、乗っ取られたときの影響範囲は端末1台の管理者権限と同等です。

数値はJVN#89009783の掲載値です。スコアの読み方はCVSSv3の評価基準と計算式、CWEとの関係はCVEとCWEの違いで解説しています。

認証不要でSYSTEM実行に至るCVE-2026-113363と113364

CVE-2026-113363は通信処理の入力検証の不備で、細工したネットワークパケットにより任意のコマンドをSYSTEM権限で実行されます。CVE-2026-113364はデータ受信処理のヒープバッファオーバーフローです。CVEレコードによれば、プロトコルヘッダ内のデータサイズに不正な値を入れたパケットで発生します。

どちらもPR:N（権限不要）、UI:N（操作不要）の評価です。パケットを届けられるかどうかが、そのまま攻撃の成否を分けます。

プログラムフォルダの権限不備を突くCVE-2026-113362の前提

CVE-2026-113362は導入フォルダのアクセス権の不備です。一般ユーザーが細工したDLLを置くと、SYSTEM権限のプロセスがそれを読み込みます。外部から直接は狙えません。

ただ、共用端末やPOS端末のように一般ユーザーが日常的にログインする環境では、フィッシングなどで奪われた一般ユーザーの権限がSYSTEMまで引き上げられます。リモートPCの台数が多い組織ほど、対処の優先度を下げない方が安全です。

影響を受けるVerの範囲がCVEごとに異なる点と判定スクリプト

影響範囲はNECのセキュリティ情報NV26-006に、CVEごとに分けて掲載されています。CVEレコードは掲載外の版を unaffected としています。

Ver7.3.3とVer7.7.2で対象CVEが変わる公告上の範囲

公告の3つの範囲を版ごとに組み直すと、次の表になります。

見落としやすいのは7.3.3と7.7.2です。除外されているのは113362だけで、認証不要の2件は残ります。7.8は2026年4月13日に出荷された現行の版で、公告の対象に入っていません。

端末名と版のCSVから対象CVEを一覧にするPythonの判定処理

台数が多い場合は、棚卸しの結果をhost,versionの列を持つCSVにして、公告の範囲で機械的に振り分けます。Python標準ライブラリだけで動きます。

import csv
import sys

V = lambda s: tuple(int(x) for x in s.split("."))


def in_range(v, low, high):
    return V(low) <= v <= V(high)


def affected(version):
    v = V(version)
    hits = []
    # CVE-2026-113362: 7.5.0以前(7.3.3を除く)、7.6.0、7.7.0-7.7.1
    if (v <= V("7.5.0") and v != V("7.3.3")) or v == V("7.6.0") or in_range(v, "7.7.0", "7.7.1"):
        hits.append("113362")
    # CVE-2026-113363: 7.2.0-7.5.0、7.6.0、7.7.0-7.7.2
    if in_range(v, "7.2.0", "7.5.0") or v == V("7.6.0") or in_range(v, "7.7.0", "7.7.2"):
        hits.append("113363")
    # CVE-2026-113364: 7.5.0以前、7.6.0、7.7.0-7.7.2
    if v <= V("7.5.0") or v == V("7.6.0") or in_range(v, "7.7.0", "7.7.2"):
        hits.append("113364")
    return hits


with open(sys.argv[1], encoding="utf-8-sig", newline="") as f:
    for row in csv.DictReader(f):
        hits = affected(row["version"])
        print(row["host"], row["version"], " ".join(hits) if hits else "掲載なし")

「掲載なし」と出た版は、対象外と決めつけず公告と突き合わせます。たとえば7.6.1のように公告に現れない番号が出たら、製品のバージョン情報の表示を見直し、NECの窓口へ確認してください。

WinShareの導入端末と31300番の待ち受けを棚卸しするコマンド

WinShare Ver7.8のセットアップカードによれば、オペレーションPCとリモートPCがともにV6.1以降なら、操作元からリモートPCへの31300/TCPだけでリモート操作とファイル転送を行います。ポートは変更できるため、既定値を前提にせず実機で確かめましょう。Ver7.7で追加されたHTTPS接続の待ち受けポートは、セットアップカードの一覧では確認できませんでした。HTTPS接続を使う環境では、下のコマンドの31300を実際の設定値に置き換えてください。

PowerShellで版・サービス・待ち受けポートをまとめて確認

次のコマンドは読み取りのみで、設定を変更しません。リモートPCごとに管理者権限のPowerShellで実行します。

$keys = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
Get-ItemProperty -Path $keys -ErrorAction SilentlyContinue |
  Where-Object { $_.DisplayName -match 'WinShare|ClientManager' } |
  Select-Object DisplayName, DisplayVersion

Get-Service -DisplayName 'WinShare*', 'ESMPRO/CM CMIT*' -ErrorAction SilentlyContinue

Get-NetTCPConnection -LocalPort 31300 -State Listen -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

待ち受けの確認にはGet-NetTCPConnectionを使っています。レジストリに記録されたバージョン表示用の値は、公告の表記と形式が一致しない場合があります。マニュアルでも「V7.01」のような書き方が混在するので、判定に回す前に製品のバージョン情報の画面と1台は照合してください。

ClientManager同梱のWinShareリモートも対象に含める棚卸し

セットアップカードの注意事項には、WebSAM ClientManagerのクライアントにWinShareリモートが同梱されていると書かれています。上のコマンドでClientManagerも拾っているのはこのためです。

ClientManagerに同梱された版がNV26-006の対象かどうかは、公告に個別の記載がありません。資産管理の用途で入れた端末がリモート操作の台帳から漏れやすいので、該当があれば同梱版の番号を控えてNECへ確認します。

修正モジュール適用までの間に入れるファイアウォール制限の設定手順

NECの公告に回避策の記載はありません。ここで挙げる通信の制限は、CVSSの前提がネットワーク到達のみである点から導いた暫定の防御で、修正モジュールの代わりにはなりません。

Windowsファイアウォールで操作元IPだけに31300番を許可

セットアップ時に「Windows ファイアウォール経由の通信を許可するアプリに WinShare を追加する」を選ぶと、WinShareという名前の許可が登録されます。別に許可ルールを足しても、既存のルールが広いままなら絞れません。既存ルールの範囲をSet-NetFirewallRuleで狭めます。

# 現在の許可範囲を確認
Get-NetFirewallRule -DisplayName '*WinShare*' | Get-NetFirewallAddressFilter |
  Select-Object InstanceID, RemoteAddress

# 操作元の管理セグメントだけに絞る（10.0.10.0/24 は自社の値へ置き換える）
Get-NetFirewallRule -DisplayName '*WinShare*' |
  Set-NetFirewallRule -RemoteAddress 10.0.10.0/24

変更の前に、操作元のIPアドレスを必ず確定させてください。範囲を誤ると遠隔からの操作ができなくなり、拠点へ出向いて戻す作業が発生します。通信経路上のファイアウォールでも、同じ範囲に揃える必要がありますので確認してください。社外から入る経路にVPN機器を挟んでいる場合は、機器側の版の確認も同時に進めると手戻りが減ります。

WinShareのユーザ認証とアクセスホスト制御を緩和策に数えない理由

WinShareにはユーザー認証とアクセスホスト制御があり、登録外の端末からの接続を拒否できます。しかし2件のCVSSはPR:Nで、NECもこれらの設定で防げるとは書いていません。

認証より手前の受信処理に欠陥があれば、アプリ側の許可リストは役に立たない可能性があります。効くと確認できていない設定を根拠に対応を遅らせる判断は、ここでは取りません。OSかネットワークの層で止めます。

中継サーバ経由の構成で31300番を外部へ公開している場合の扱い

中継サーバを使う構成では、オペレーションPCとリモートPCの両方が中継サーバの31300/TCP（プロキシ経由の設定では443/TCP）へ接続します。ファイアウォールの内側にある端末を外から操作するための仕組みなので、中継サーバは外部に面して置かれがちです。

公告は中継サーバ単体の影響に触れていません。導入ファイルは同じwsdelivery.exeが通信許可の対象になっているため、確認が取れるまではリモートPCと同じ扱いで、接続元の固定IP以外を遮断します。

修正モジュールの適用手順と適用済みを版番号だけで判断しない記録

JVNは「最新版へのアップデート」、NECは修正モジュールの適用を対策として挙げています。配布はいずれもNV26-006からリンクされたNECサポートポータルで、閲覧にはログインが必要です。

Ver7.6用とVer7.7用モジュールの選び方と7.5.0以下の扱い

モジュールはVer7.6用とVer7.7用の2種類です。公告には、いずれも7.5.0以下の下位バージョンにも適用できると記されています。7.5.0以下でどちらを使うかは、ポータルの適用条件で確かめてください。

ポータルの本文は公開されていないため、適用手順、再起動の要否、適用後の版の表示は本記事では確認できていません。作業手順書を作る前にログインして、対象の版と前提条件を読み込むところから始めます。

リモートPCへの適用順を段階に分ける検証台数と業務影響の切り分け基準

リモート操作の経路そのものを更新するので、失敗すると直せる手段も失います。ローカルでの操作手段がある端末を数台選んで先に適用し、次の3点を確かめてから全体へ広げます。

1. サービス「WinShare Delivery Service」「WinShare Remote Service」が起動している
2. オペレーションPCから接続とファイル転送ができる
3. 中継サーバ経由の接続を使う環境では、その経路でも接続できる

適用済みの管理は、版番号だけに頼らないでください。モジュールを当てても版の表示が変わらない可能性を公開情報では否定できないからです。台帳に端末名、モジュールの種類、適用日、担当者を残します。全社の更新の回し方はパッチ管理の手順が参考になります。

侵害の有無を確かめる権限・DLL・プロセス起動履歴の点検手順

NECとJVNは侵害の痕跡（IoC）を公表していません。以下はCVEの記述から組み立てた点検で、異常が出なくても侵害がなかった証明にはなりません。

icaclsとAuthenticodeで見るプログラムフォルダの改変

既定の導入先は64bit環境でC:\Program Files (x86)\WinShareです。113362の前提であるフォルダの権限と、見慣れないDLLの有無を確かめます。

icacls "C:\Program Files (x86)\WinShare"

Get-ChildItem 'C:\Program Files (x86)\WinShare' -Recurse -Filter *.dll |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 30 FullName, LastWriteTime

Get-ChildItem 'C:\Program Files (x86)\WinShare' -Recurse -Filter *.dll |
  Get-AuthenticodeSignature |
  Where-Object Status -ne 'Valid' |
  Select-Object Path, Status

BUILTIN\UsersやEveryoneに(F)、(M)、(W)が付いていれば、一般ユーザーが書き込める状態です。Get-AuthenticodeSignatureで署名が無効と出ても、製品の正規ファイルの可能性があります。同じ版の別端末とハッシュを比べ、1台だけ違うファイルを調べるのが確実です。

イベントID 4688で追うwsdelivery.exe配下のプロセス起動

セットアップカードでリモートPCの通信許可の対象になっているのはwsdelivery.exeです。WindowsのイベントID 4688を記録している環境なら、作成元がWinShare関連のプロセスで、新しいプロセスがcmd.exeやpowershell.exeになっている行を抽出します。

この監査は既定では無効です。記録がない期間は判定できないので、その旨を調査結果に残してください。あわせて、WinShare自体の接続履歴、操作履歴、ファイル転送履歴を、作業予定のない時間帯に絞って見ます。

パッチか停止かVer7.8移行かを分ける到達範囲と保守契約の判断基準

悪用の情報が出ていない段階でも、判断を先送りしない基準を決めておくと現場が迷いません。CISAのKEVカタログの2026.11.09版に3件の掲載はありませんでしたが、掲載がないことは悪用がないことを意味しません。

修正前でもその日のうちに遮断する端末と週内の更新で足りる端末の線引き

インターネットから31300番に届く端末と中継サーバは、当日中に遮断します。修正モジュールの検証を待つ理由にはなりません。

社内LANだけで届く端末は、操作元のIP制限を当日に入れ、モジュールの適用は週内を目安にします。VPNの内側だから安全という判断は採りません。社内の1台が侵入されれば、横から届くからです。

Ver7.8だけで構成された環境は、緊急の作業は不要です。棚卸しで全台が7.8だと確かめるところまでで止めて構いません。侵害の兆候がない端末まで一律に再構築するのは過剰です。

保守切れで修正モジュールを入手できない端末を使い続けない条件

モジュールの入手にはサポートポータルへのログインが必要です。保守契約が切れて入手できない端末では、WinShareを停止してアンインストールします。通信制限だけで使い続ける運用は採用しません。ローカル側の113362も、認証不要の2件も残るためです。

Ver7.8への移行は、ライセンスと保守の条件を販売元に確認したうえで決めます。7.7系をモジュールで塞げる環境では、移行を緊急作業に組み込む必要はありません。次の定期更新の議題で十分です。

自社開発の通信処理へ持ち帰るパケット長検証と外部診断の依頼範囲

113364の原因は、ヘッダのデータサイズという外部入力を信用したことでした。自社開発のサーバーやエージェントが独自プロトコルを受ける場合、長さの上限検査を認証より前の層に置いているかを点検してください。APIであればAPI不正アクセス対策の実装手順の観点が流用できます。

自社の担当者だけで全端末の到達範囲を検証できないときは、外部の脆弱性診断・セキュリティ診断で、開いているポートと接続元の棚卸しから依頼すると抜けを減らせます。診断の種類と費用の見方は脆弱性診断の進め方にまとめました。

よくある質問

WebSAM WinShareの脆弱性対応で、確認が多くなる点をまとめました。

WebSAM WinShare Ver7.8は今回の脆弱性の対象ですか？

NECのNV26-006に掲載された影響範囲は、最も新しいもので7.7.2までです。Ver7.8はどのCVEにも掲載されておらず、CVEレコードも掲載外の版を影響なしとして扱っています。ただし、古い版のオペレーションPCやリモートPCが1台でも混ざると、その端末は対象のままです。全台の版を確かめてから判断してください。

修正モジュールはどこから入手できますか？

NV26-006にリンクされたNECサポートポータルから、Ver7.6用とVer7.7用を入手できます。閲覧にはポータルへのログインが必要です。公告には、どちらも7.5.0以下の下位バージョンに適用可能とあります。7.5.0以下の環境でどちらを選ぶかは、ポータルの適用条件で確認し、判断がつかない場合は販売元かNECの窓口に問い合わせてください。

Ver7.3.3やVer7.7.2なら修正不要ですか？

修正は必要です。7.3.3と7.7.2が対象外なのはCVE-2026-113362だけで、認証なしでSYSTEM権限の実行を許すCVE-2026-113363と113364の対象には入っています。公告の除外条件はCVEごとに違うため、版の番号だけを見て「除外」と判断せず、3件それぞれの範囲と照合する必要があります。

アクセスホスト制御を有効にしていれば攻撃を防げますか？

防げるとは言えません。アクセスホスト制御は登録外の端末の接続を拒否する機能ですが、NECの公告で回避策として挙げられている設定に、アクセスホスト制御は含まれていない状況です。2件のCVSSは権限不要の評価であり、受信処理のどの段階で欠陥が発動するかも公開されていません。Windowsファイアウォールなど、パケットが製品に届く前の層で通信元を絞ってください。

すでに悪用されている脆弱性ですか？

2026年11月10日時点で、NECの公告とJVNに悪用の記載はなく、CISAのKEVカタログ2026.11.09版にも掲載されていません。これは確認された悪用がまだ公表されていないという意味にとどまります。公表後は修正内容の解析が進むので、最新の状況はNV26-006とJVN#89009783の更新で追ってください。

関連記事

• 脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説：公表から修正までの流れの基礎を確認できます。
• パッチ管理とは：KEVで優先度を決め、Patch Managerとapt・dnfで自動適用する手順：Windows端末を含む更新の仕組みづくりを扱っています。
• VPN 脆弱性：機器の版確認コマンドとKEV照合スクリプト・パッチと移行の判断【2026年10月】：社外から社内へ入る経路の版確認と併せて読めます。
• リモートデスクトップとは？仕組み・VPN/VDIとの違いと設定手順・企業導入の判断【2026年版】：リモート操作の方式を比較するときの基礎です。
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説：端末と通信経路の点検を外部へ依頼する際の進め方です。