--- title: "Snort 3の脆弱性CVE-2026-76524と3.12.4.0：版確認・制御ソケット点検・更新手順" url: "https://www.issoh.co.jp/tech/details/18811/" published: 2026-10-23 updated: 2026-10-23 categories: ["セキュリティ"] publisher: "株式会社一創" --- # Snort 3の脆弱性CVE-2026-76524と3.12.4.0：版確認・制御ソケット点検・更新手順 Ciscoは2026年10月21日、Snort 3に関するセキュリティアドバイザリを7本まとめて公表しました。CVSS 9.0を含む強化リリースの4件、ローカルの低権限ユーザーが任意のコマンドを実行できる制御チャネルソケットのCVE-2026-76524、検知エンジンを再起動させるDoS系5本です。この記事では、オープンソース版・Secure Firewall Threat Defense（FTD）・IOS XEのUTD・Merakiで異なる修正経路、`snort -V`での版確認とlibdaqを含む3.12.4.0への更新、制御ソケットの露出を点検するスクリプトまでを、自前でSnort 3を運用する実装者の目線で整理しました。内容は2026年10月23日時点の公開情報にもとづきます。 ## まとめ：OSS版は3.12.4.0へ更新しCisco製品は製品別の修正版を確認 オープンソース版Snort 3は、3.x系のすべてが対象で、修正版は3.12.4.0です。回避策は示されていないため、版を上げる以外に塞ぐ方法はありません。Cisco製品では、FTDは系列ごとの修正版へ、IOS XEのUTDは3.12.4.0を含むUTDイメージへ更新します。MerakiのMXとCloud-delivered Firewall、Secure Accessは10月21日までに自動更新済みで、利用者の作業は不要です。 急ぐべきなのは、複数の人がログインするLinuxホストでSnort 3を`--shell`付きで動かし、制御チャネルを開けている構成です。CVE-2026-76524はネットワーク越しには届きませんが、同じホストの一般ユーザーからSnortの実行ユーザー権限を奪えます。2026年10月21日にSnort 2のサポートも終わったため、旧版で止まっているIDSは移行と更新を一度に計画する対象です。自社で運用しているIDSやサーバー群の版と露出をまとめて洗い出したい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)で棚卸しすると抜けを減らせます。 ## 2026年10月21日のSnort 3関連アドバイザリ7本：CVEと深刻度の整理 今回の公表は、Ciscoが月2回の定例日にまとめて出す方式の一部です。[10月21日分の事前通知](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-notice-QGwHnJ6k)には、Snort 3の欄だけで7本のアドバイザリが並んでいます。いずれもCisco PSIRTは悪用や公開情報を把握していないとしています。 | アドバイザリ | CVE | 深刻度・CVSS | | ------------- | ------------------- | ------------ | | 強化リリース（10月） | CVE-2026-20043ほか計4件 | Critical・9.0 | | 制御チャネルソケット | CVE-2026-76524 | High・7.8 | | DoS（複数） | CVE-2026-76489ほか計4件 | Medium・5.8 | | GREのDoS | CVE-2026-20221 | Medium・5.8 | | SMTP MIMEのDoS | CVE-2026-20011 | Medium・5.8 | | VBA展開のDoS | CVE-2026-20218 | Medium・5.8 | | GTP拡張ヘッダのDoS | CVE-2026-76445 | Medium・5.3 | OSS版の修正はすべて3.12.4.0に入っています。1本ずつ対応を分ける必要はなく、版を上げれば7本とも閉じる関係です。 ### 強化リリースの4CVEをCWE単位で束ねた方式と最大CVSS 9.0の読み方 [強化リリースのアドバイザリ](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-hardening-snort3-ybgmhTQe)は、社内の静的解析やファジング、AIモデルを使った検査で見つかった多数の欠陥を、弱点の分類（CWE）ごとに1つのCVEへまとめています。CVE-2026-20236が計算誤り（CWE-682）、CVE-2026-20043が範囲外書き込み（CWE-787）、CVE-2026-20291が不適切な権限管理（CWE-269）、CVE-2026-20356が資源の過剰消費（CWE-400）です。表のCVSSは、各分類に含まれる欠陥のうち最も重いものの値だと説明されています。 注意したいのは数値の食い違いです。本文の表ではCVE-2026-20236も9.0ですが、同じアドバイザリの[機械可読のCSAF JSON](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-hardening-snort3-ybgmhTQe/csaf/cisco-sa-hardening-snort3-ybgmhTQe.json)では7.5（可用性のみHigh）になっています。2026年10月23日時点の取得結果で、9.0のベクトル `AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H` を持つのはCVE-2026-20043だけでした。脆弱性管理ツールに取り込んだ値が画面の表と合わない場合は、この差が原因です。スコアの各指標の意味は[CVSSv3の計算式とスコアの目安](https://www.issoh.co.jp/tech/details/5094/)で確認できます。 ### 制御チャネルソケットのCVE-2026-76524：低権限ユーザーから任意コマンド [CVE-2026-76524のアドバイザリ](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-opensrc-snort3-2fXGJPfe)によると、Snort 3の制御チャネルソケットには、ローカルユーザーが接続するときの認証がありませんでした。同じホストにログインできる低権限の攻撃者がこのソケットへつなぐと、Snort 3プロセスのユーザー権限で任意のコマンドを実行でき、プロセスのメモリも読み書きできます。CVSSは7.8で、ベクトルは `AV:L/AC:L/PR:L` から始まるローカル攻撃の評価です。 対象はオープンソース版Snort 3だけで、Cisco製品の欄はありません。アドバイザリは「設定を問わず影響」と書いていますが、制御チャネルの待ち受けがどこに作られるかはビルドと起動オプションで変わります。具体的な確かめ方を示すのは、後半にある制御チャネルの点検の章です。Snort 2は影響を受けないとCiscoが確認しています。 ### DoS系5本の対象機能と既定で無効のVBA展開を止める回避策 残る5本は、細工したパケットで検知エンジンを再起動させるDoSです。対象はNetFlow、ネストしたGRE、SMTPのMIMEヘッダ、VBAマクロの展開、GTPの拡張ヘッダと、プロトコル解析の部品ごとに分かれています。GREの件は、構成によってはDoSではなく検査の素通り（バイパス）になると書かれており、インラインで遮断に使っている環境ほど影響が出ます。 回避策が示されているのはVBAの1件だけです。[VBAのアドバイザリ](https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-snort3-vba-bufdos-jAuFdvn9)は、VBAの展開はどのインスペクタでも既定で無効で、無効のままなら影響を受けないとしています。OSS版の設定では、`http_inspect`・`smtp`・`pop`・`imap`の各モジュールにある`decompress_vba`（既定false）がこれに当たります。`snort.lua`を`grep -n decompress_vba`で検索し、trueにしている箇所が無ければこの1件は対象外です。 ## 影響製品の切り分け：OSS版・FTD・IOS XE UTD・Merakiの修正経路 強化リリースは7つの製品に影響します。Cloud-delivered Firewall（CDFW）、Cyber Vision、Meraki MX、Secure Access（CSA）、Secure FTD、オープンソース版Snort 3、IOS XEのUnified Threat Defense（UTD）です。修正の届け方が製品ごとに違うため、自社の利用形態から先に確かめます。 ### Secure FTDの7.0系から10.1系までの修正版とSnort 2で動く機器 FTDの修正版は系列ごとに決まっています。強化リリースのアドバイザリに載っている対応は次のとおりです。 | FTDの系列 | 最初の修正版 | | ------ | ------ | | 7.0以前 | 7.0.10 | | 7.2 | 7.2.12 | | 7.4 | 7.4.8 | | 7.6 | 7.6.6 | | 7.7 | 7.7.13 | | 10.0 | 10.0.2 | | 10.1 | 10.1.0 | 見落としやすいのは検知エンジンの種類です。DoS系のアドバイザリによれば、7.0.0以降を新規に入れたFTDは既定でSnort 3が動きますが、6.7.0以前から上げてきた機器は既定でSnort 2のままです。Snort 3が動いていなければDoS系の多くは成立しません。ただしSnort 2は7.7.0以降で非推奨になっており、版を上げるついでにSnort 3へ切り替える計画を立てる機会でもあります。動いているエンジンの確かめ方は、Ciscoの文書「Determine the Active Snort Version that Runs on Firepower Threat Defense (FTD)」に手順があります。 ### IOS XE UTDのイメージ名に含まれるSV3.12.4.0の見方と対象ルーター ISRやCatalyst 8000系などで使うUTDは、IOS XE本体とは別のUTDイメージにSnortが入っています。アドバイザリは10月22日の1.1版で修正版の表を改訂し、17.12系は17.12.8、17.15系は17.15.6、17.18系は17.18.5、26.1系は26.1.2、26.2系は26.2.1を示しました。 確かめるときはUTDイメージのファイル名を見ます。たとえば17.12.8向けは `secapp-utd.17.12.08.1.2.8_SV3.12.4.0_XE17.12` で、`SV`の後ろがSnortの版です。ここが3.12.4.0になっていれば、修正済みの版だと判断できます。UTDは既定ではインストールされていないため、UTDファイルを入れていないルーターは対象外です。 ### MerakiとCDFW・Secure Accessが自動更新済みで作業不要な理由 MerakiのMXは、Snortを脅威防御の機能として内蔵し、Meraki Dashboardから自動で管理しています。アドバイザリでは、10月21日時点でDashboardにつながっていた対象機種はすべてSnort 3のパッケージが自動更新済みとされました。CDFWとSecure Accessもクラウド側で同日までに更新済みです。 例外はオフラインの機器です。Dashboardに接続していなかったMXは更新が届いていない可能性があるので、接続状態を確かめてから作業不要と判断します。Cyber Visionは5.6未満なら修正版への移行、5.6系は5.6.0が修正版です。 ## OSS版Snort 3の版確認と3.12.4.0へのソースビルド更新手順 オープンソース版を自前でビルドして使っている場合は、版の確認から入れ替えまで自分で行います。[snort.orgのダウンロードページ](https://www.snort.org/downloads)では、2026年10月23日時点でsnort3-3.12.4.0とlibdaq-3.0.28が配布されています。 ### snort -Vで4桁の版を確かめlibdaq 3.0.28を先に入れる順序 稼働中のバイナリで`snort -V`を実行し、表示される4桁の版番号を見ます。3.12.4.0より前なら更新対象です。複数のパスにSnortが入っている環境では、systemdのユニットファイルの`ExecStart`が指すバイナリで確かめないと、別の版を見て安心することになります。ユニットファイルの読み方は[systemdのユニットファイルの基本](https://www.issoh.co.jp/tech/details/8160/)で整理しています。 依存先を先にそろえるのが、更新の順序に関する決まりです。[3.12.4.0のリリースノート](https://github.com/snort3/snort3/releases/tag/3.12.4.0)は依存先としてLibdaq v3.0.28とLibML v2.0.0を挙げています。3.12.2.0の依存はLibdaq v3.0.27だったため、春の版から上げる場合は[libdaq v3.0.28](https://github.com/snort3/libdaq/releases/tag/v3.0.28)を先に入れ直します。LibMLは2.0.0のまま変わっていません。 ### configure\_cmake.shでの再ビルドと設定検証を挟んだ入れ替え ビルドの手順は[公式のチュートリアル](https://github.com/snort3/snort3/blob/master/doc/user/tutorial.txt)に沿います。次の例は、旧版を残したまま版ごとのディレクトリへ入れ、設定を検証してから切り替える流れです。パスや設定ファイルの場所は自社の環境に合わせて変えてください。 ``` # 1. 先に libdaq 3.0.28 を入れる（3.12.4.0 の依存） curl -LO https://github.com/snort3/libdaq/archive/refs/tags/v3.0.28.tar.gz tar xzf v3.0.28.tar.gz cd libdaq-3.0.28 ./bootstrap && ./configure && make && sudo make install sudo ldconfig cd .. # 2. Snort 3.12.4.0 を版ごとのディレクトリへビルド curl -LO https://github.com/snort3/snort3/archive/refs/tags/3.12.4.0.tar.gz tar xzf 3.12.4.0.tar.gz cd snort3-3.12.4.0 export my_path=/opt/snort3-3.12.4.0 ./configure_cmake.sh --prefix=$my_path cd build && make -j $(nproc) && sudo make install # 3. 版と設定を確かめてから切り替える $my_path/bin/snort -V $my_path/bin/snort -c /etc/snort/snort.lua --warn-all ``` 3つ目の`-c`だけを付けた実行は、パケットを読まずに設定ファイルを検証して終わります。ここでエラーが出なければ、systemdのユニットが指すパスを新しいディレクトリへ向け直して再起動してください。旧版のディレクトリを消さずに残しておけば、検知に異常が出たときにパスを戻すだけで切り戻せます。 `configure_cmake.sh`に`--enable-shell`を付けていない点も意図したものです。対話シェルと制御チャネルはこのオプションで組み込まれる機能で、使っていないなら外したままビルドするのが安全側の選択です。 ## 制御チャネルソケットの露出を点検する：-jと–control-socketの確認 CVE-2026-76524は3.12.4.0で直りますが、すぐに更新できないホストもあります。その間に、どのホストで制御チャネルが開いているかを把握しておくと、更新の優先順位を決められます。 ### –enable-shellのビルドかを–help-optionsの一覧で判定する方法 制御チャネルは、ビルド時に対話シェルを有効にした場合だけ組み込まれます。[CMakeのオプション定義](https://github.com/snort3/snort3/blob/master/cmake/create%5Foptions.cmake)では`ENABLE_SHELL`の既定値はOFFです。[公式の使い方文書](https://github.com/snort3/snort3/blob/master/doc/user/usage.txt)も、シェルを使うには`--enable-shell`付きのビルドが必要と書いています。 ソースでは`--shell`・`-j`・`--control-socket`の3つのオプションが、シェルを有効にしたビルドでだけ定義されます。そのため`snort --help-options | grep -E 'control-socket|shell'`を実行して何も出なければ、そのバイナリには制御チャネルがありません。ディストリビューションのパッケージで入れたSnortは、ビルドの設定を自分で決めていないので、この確認が早道です。 ### 稼働中プロセスの起動引数とソケット権限を一覧するPythonスクリプト シェル付きのビルドでも、待ち受けを作るのは`-j <ポート>`か`--control-socket <ファイル>`を指定したときです。[制御チャネルの実装](https://github.com/snort3/snort3/blob/master/src/control/control%5Fmgmt.cc)を読むと、`-j`は127.0.0.1のTCPポート、`--control-socket`はUNIXドメインソケットで待ち受けます。どちらも外部からは届きませんが、TCPの場合は同じホストの全ユーザーが接続できる状態です。UNIXドメインソケットの仕組みは[TCP・UDP・UNIXドメインのソケット実装入門](https://www.issoh.co.jp/tech/details/17511/)で解説しています。次のスクリプトは、Linuxの`/proc`から稼働中のsnortプロセスを探し、制御チャネルの指定とソケットファイルの権限を表示します。 ``` import os import stat from pathlib import Path def control_options(argv): # 起動引数から制御チャネルの指定（-j と --control-socket）を取り出す found = [] for i, arg in enumerate(argv[:-1]): if arg in ("-j", "--control-socket"): found.append((arg, argv[i + 1])) return found for proc in Path("/proc").glob("[0-9]*"): try: raw = (proc / "cmdline").read_bytes() owner = proc.stat().st_uid except OSError: continue argv = [a.decode(errors="replace") for a in raw.split(b"\0") if a] if not argv or Path(argv[0]).name != "snort": continue print(f"pid={proc.name} uid={owner} shell={'--shell' in argv}") for opt, value in control_options(argv): if opt == "-j": print(f" TCP 127.0.0.1:{value} 同じホストの全ユーザーが接続できる") continue sock = Path(value) if not sock.is_absolute(): print(f" UNIXソケット {value} 相対指定のためログディレクトリ配下を確認") continue try: st = os.stat(sock) except OSError: print(f" UNIXソケット {sock} ファイルが見つからない") continue mode = stat.S_IMODE(st.st_mode) risk = "その他ユーザーが書き込み可" if mode & 0o002 else "所有者とグループに限定" print(f" UNIXソケット {sock} mode={oct(mode)} uid={st.st_uid} {risk}") ``` rootで実行すると、全ユーザーのプロセスを確認できます。何も表示されなければ、そのホストではsnortが制御チャネルを開いていません。`shell=True`で`-j`の行が出たホストと、`その他ユーザーが書き込み可`と出たホストが、更新を最優先にする対象です。修正前の版では認証が無いため、ソケットの権限を絞ることは更新までのつなぎにしかなりません。一般ユーザーのいない専用機でも、Snortをrootで動かしていれば奪われる権限が大きくなるので、systemdの`User=`で専用ユーザーに下げておく価値があります。 ## 更新を急ぐ環境と後回しにできる環境：Snort 3運用者の判断基準 悪用は確認されていないものの、IDSは監視の要です。検知エンジンが止まるか素通りすると、その間の攻撃は記録に残りません。どの順で手を付けるかを、構成から決めておきます。 ### 共用Linuxホストで制御チャネルを開く構成を当日中に更新すべき理由 最優先は、開発者や運用者が複数ログインするホストで、シェル付きのSnort 3が`-j`か権限の広い`--control-socket`で動いている構成です。CVE-2026-76524の前提である「ローカルの低権限ユーザー」が最初から存在するため、条件はすでにそろっています。Snortはパケットを取り込むために高い権限で動かすことが多く、奪われたときの被害も大きくなります。この構成は、当日中に3.12.4.0へ上げるか、上げるまで制御チャネルを外して再起動してください。 次はインラインで遮断に使っているSnortです。GREのDoSが素通りにつながるため、境界の防御に穴が開く時間を作らないよう、保守時間を待たずに更新します。 逆に、シェル無しのビルドで、pcapの解析だけに使っている分析用のSnortは、定例のパッチ日に回してかまいません。外部からパケットを受けず、制御チャネルも無いため、今回の7本のうち成立しうるのは解析対象のpcapに細工があった場合のDoSに限られます。Meraki MXやCDFWのように自動更新済みの製品で、個別の検証作業を積み増すのも過剰です。 ### Snort 2のEOLで移行を先送りしてきたIDS環境の進め方 同じ10月21日、[Snort公式ブログ](https://blog.snort.org/2026/10/end-of-life-announcement-for-open.html)はオープンソース版Snort 2のすべての版がサポート終了に達したと告知しました。2.9.20を含むSnort 2の開発と保守リリースは終わり、Talosのルール提供も止まります。今回の7本はSnort 2に影響しませんが、それは安全という意味ではありません。今後見つかる欠陥も、新しい攻撃を検知するルールも、もう届かないということです。 移行には、Snort 2の設定とルールをSnort 3の文法へ変換する`snort2lua`が用意されています。変換した設定は前の章と同じく`-c`で検証し、旧環境と並べて同じpcapを流して、アラートの差を比べてから切り替えると安全です。エンジン自体を見直す場合は、別のOSSである[Suricataの導入とIPSモード運用](https://www.issoh.co.jp/tech/details/9989/)も比較の候補になります。IDSとIPSの役割の違いや、WAFとの使い分けを整理し直したい場合は[IDS・IPSの違いとファイアウォール/WAFとの使い分け](https://www.issoh.co.jp/column/details/13258/)が参考になります。 ## Snort 3の脆弱性対応でよく受ける質問と一次情報にもとづく回答 今回のSnort 3の脆弱性対応で出てきやすい疑問に、2026年10月23日時点で公開されている一次情報の範囲で答えます。 ### Snort 3.12.4.0に上げればルールの更新も必要になりますか？ 3.12.4.0のリリースノートには、ルールパッケージの版を指定する記載はありません。3.12.0.0や3.11.0.0ではAPIの変更に合わせてTalosのLightSPDパッケージの版指定があったため、3.11系より前から一気に上げる場合は、途中の版のリリースノートも確かめてください。3.12系の中での更新なら、追加で求められるルールの版指定は公表されていません。 ### Cisco Secure FTDを使っていればOSS版の作業は不要ですか？ 不要です。FTDのSnort 3はFTDのソフトウェア更新で入れ替わるため、FTDの系列に応じた修正版（7.4系なら7.4.8、7.6系なら7.6.6など）を適用します。逆に、制御チャネルのCVE-2026-76524はOSS版だけの欠陥で、FTDは対象に挙がっていません。同じSnort 3という名前でも、確認先のアドバイザリの表が違う点に注意が要ります。 ### 制御チャネルを使っていなければCVE-2026-76524は無視してよいですか？ シェル無しでビルドしたバイナリであれば、制御チャネルのコード自体が入っていません。ただしCiscoはOSS版を「設定を問わず影響」としているため、無視するのではなく3.12.4.0への更新計画には含めておきます。強化リリースの4件とDoS系5本は制御チャネルと無関係なので、どのみち同じ更新で閉じることになります。 ### 同じ時期に出たCiscoのほかの製品の脆弱性も確認すべきですか？ 10月21日の事前通知には、Snort 3のほかにExpresswayのCVSS 9.8の欠陥やUnified Communications製品の強化リリースも並んでいます。Cisco製品を複数使っている場合は、通知ページの一覧で自社の製品を一度に確かめるのが効率的です。10月14日に悪用が公表された[Cisco Secure Email GatewayのCVE-2026-76519](https://www.issoh.co.jp/tech/details/18783/)は別の日に公表された件で、こちらは悪用が確認済みのため優先度が上です。 ### Snort 3の脆弱性で検知エンジンが落ちたかはどこで分かりますか？ DoS系のアドバイザリは、細工したパケットで検知エンジンが予期せず再起動すると説明しています。OSS版で再起動した時刻と回数を追う手段は、systemdの`journalctl -u`に対象ユニット名を渡す方法です。GREのアドバイザリは、エンジンは自動で再起動し手動の操作は要らないとしています。短い間隔で再起動が続いていれば、修正版への更新を急ぐ合図です。 ## 関連記事 - [脆弱性とは？種類・CVE/CVSSの仕組みと発見から修正までの実務を解説](https://www.issoh.co.jp/tech/details/13546/)：脆弱性が公表から修正に至る流れの基礎を確認できます。 - [CVE（共通脆弱性識別子）とは？仕組み・CVSS/CWE/NVDとの違いと2026年の運営体制変化](https://www.issoh.co.jp/tech/details/5092/)：CWE単位でCVEを束ねた今回の採番を読む前提になります。 - [VPN 脆弱性：機器の版確認コマンドとKEV照合スクリプト・パッチと移行の判断【2026年10月】](https://www.issoh.co.jp/tech/details/18740/)：境界機器の版を照合する考え方をVPN機器で解説しています。 - [BIG-IPの脆弱性CVE-2026-94127とは？APMのOAuth構成の確認コマンドと侵害調査の手順](https://www.issoh.co.jp/tech/details/17979/)：入口機器の脆弱性を構成条件から切り分ける手順の比較に使えます。 - [CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説](https://www.issoh.co.jp/tech/details/13277/)：単発の緊急対応から、露出を継続的に管理する運用へ移す考え方です。 --- 出典: [Snort 3の脆弱性CVE-2026-76524と3.12.4.0：版確認・制御ソケット点検・更新手順]()（株式会社一創）