SonicWall SMA1000 のゼロデイ2件｜対処と侵害調査の手順

はじめに

2026 年 7 月 14 日、SonicWall は SMA1000 シリーズに影響する 2 件の脆弱性（CVE-2026-15409・CVE-2026-15410）を修正するセキュリティアドバイザリ（SNWLID-2026-0008）を公開しました。2 件はいずれもゼロデイ攻撃で悪用されていたことが確認されており、公開当日に CISA の悪用が確認された脆弱性カタログ（KEV）にも登録されています。米連邦政府機関に課された対応期限は 2026 年 7 月 17 日と、登録からわずか 3 日という異例の短さです。

SMA1000 シリーズはリモートアクセス（SSL-VPN）ゲートウェイとしてインターネットに直接露出する機器であり、境界機器の脆弱性の中でも特に初動の速さが求められるケースです。本記事では、影響の有無の切り分けから、修正版へのアップグレード、そしてアップグレード後に必須となる侵害有無の調査（IOC 確認）までを整理します。

先に結論をまとめます。SMA1000（6210・7210・8200v）を運用している場合、12.4.3-03453 または 12.5.0-02835 以降の platform-hotfix への早急なアップグレードを推奨します。ただし、すでに悪用が確認されているため、パッチ適用だけでは対応は完了しません。ログの IOC 確認までをワンセットとして実施し、侵害の痕跡が見つかった場合はアプライアンスの再イメージと認証情報のリセットが必要になります。

SonicWall SMA1000 の 2 つのゼロデイ脆弱性の概要

今回のアドバイザリには性質の異なる 2 件の脆弱性が含まれます。認証不要の SSRF（CVE-2026-15409）と、管理者認証後のコード注入（CVE-2026-15410）です。観測されている攻撃では、この 2 件が組み合わせて悪用されています。

参考: SonicWall Security Advisory（SNWLID-2026-0008）
“multiple cases indicating the active exploitation of the vulnerabilities described in this advisory”
（本アドバイザリに記載された脆弱性が実際に悪用されていることを示す複数の事例）
https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0008

CVE-2026-15409: WorkPlace の SSRF（CVSS 10.0・認証不要）

SMA1000 の WorkPlace インターフェースに存在する SSRF（Server-Side Request Forgery）の脆弱性です。リモートの認証されていない攻撃者が、アプライアンスに意図しない宛先へのリクエストを送信させることができます。

• CVSS v3 スコア: 10.0（Critical）
• CVSS ベクター: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
• CWE: CWE-918（Server-Side Request Forgery）

注目すべきはスコープが「変更あり（S:C）」と評価されている点です。SSRF 単体では「サーバーに代理リクエストを送らせる」動きにとどまりますが、SSL-VPN ゲートウェイという機器の性質上、インターネットからは到達できない内部セグメントや、アプライアンス自身の管理系エンドポイントへの到達点として悪用されることが想定されます。境界機器の SSRF が持つリスク構造については、関連記事『Cisco Unified CM の SSRF 脆弱性（CVE-2026-20230）への対処』も参考になります。

CVE-2026-15410: AMC のコード注入（CVSS 7.2・認証後 RCE）

管理コンソール（AMC: Appliance Management Console）に存在するコード注入（CWE-94）の脆弱性です。管理者として認証されたリモートの攻撃者が、特定の条件下で任意の OS コマンドを実行できます。

• CVSS v3 スコア: 7.2（High）
• CVSS ベクター: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
• CWE: CWE-94（Improper Control of Generation of Code）

単体で見れば「管理者権限が前提（PR:H）」であるため優先度を下げたくなる評価ですが、後述のとおり実際の攻撃では CVE-2026-15409 と組み合わせて使われており、「管理者認証が必要だから安全」という判断は成り立ちません。アプライアンスの OS レイヤーでコマンドが実行されると、設定改ざんや永続化（バックドア設置）に直結します。

攻撃チェーンと悪用状況（CISA KEV 登録・対応期限 7/17）

SonicWall PSIRT は、本アドバイザリの脆弱性が実際に悪用されている複数の事例を確認したと明記しています。また、SonicWall はアドバイザリ公開に先立って影響顧客へ事前通知を行い、公開前にホットフィックスを提供する対応を取っていました。ベンダーがこの段取りを踏むこと自体が、事態の深刻度を示すシグナルと言えます。

なお、2 件が具体的にどのような手順でチェーンされたのか、詳細な攻撃手法は本記事執筆時点（2026 年 7 月 15 日）で公開されていません。CISA が同日に両方を KEV へ登録したことから 2 件のチェーンが強く示唆されるものの、確認済みのエクスプロイトチェーンは公開されていない状況です。報道ベースでは「2 件が連携して悪用されている」とされており、認証不要の SSRF で足がかりを得て、何らかの方法で管理者権限のセッションまたは認証情報を確保した後、コード注入で OS コマンド実行（RCE）に至る流れが推定されます。

CISA KEV への登録状況は以下のとおりです。

通常、KEV 登録から対応期限までは 3 週間程度が設定されることが多く、3 日という期限は「即時対応が必要」という CISA の判断を反映したものと受け取るべきです。また、同日には Microsoft AD FS と SharePoint Server のゼロデイ 2 件も KEV に追加されており、7 月のパッチサイクルは境界機器と認証基盤の両面で対応負荷が高くなっています。日本国内の組織に KEV の期限が直接適用されるわけではありませんが、優先度判断の基準として活用する価値があります。

参考: CISA Known Exploited Vulnerabilities Catalog
“Apply mitigations in accordance with vendor instructions”
（ベンダーの指示に従って緩和策を適用すること）
https://www.cisa.gov/known-exploited-vulnerabilities-catalog

影響を受ける製品とバージョン

対応の初動は「自分の環境が対象かどうか」の切り分けです。今回の 2 件は SMA1000 シリーズのみが対象であり、SonicWall ファイアウォールの SSL-VPN 機能や SMA100 シリーズは影響を受けません。

対象モデルと影響バージョン（6210・7210・8200v）

アドバイザリに記載された影響対象は以下のとおりです。

現在のバージョンは、AMC（Appliance Management Console）にログインした際のシステム情報、または System Configuration > Maintenance 画面で確認できます。

なお、影響バージョンとして列挙されているのは特定のホットフィックスビルドですが、悪用が確認されている状況を踏まえると、修正版（後述）より前のビルドで稼働している SMA1000 はすべて要対応と判断することを推奨します。列挙されたビルド以外だから安全、という解釈はリスクが残ります。

対象外の製品（SMA100 シリーズ・ファイアウォールの SSL-VPN）

アドバイザリには対象外の製品が明記されています。切り分けの根拠として引用します。

参考: SonicWall Security Advisory（SNWLID-2026-0008）
“These vulnerabilities do not affect SSL-VPN running on SonicWall firewalls or the SMA 100 Series product line.”
（これらの脆弱性は、SonicWall ファイアウォール上で動作する SSL-VPN および SMA 100 シリーズ製品ラインには影響しません）
https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0008

つまり、以下の環境は今回の 2 件に関しては対応不要です。

• TZ・NSa・NSsp 等の SonicWall ファイアウォールで SSL-VPN を有効化している環境。
• SMA 100 シリーズ（SMA 210・410・500v 等）を運用している環境。

ただし、SMA100 シリーズや SonicWall ファイアウォールも過去に別の脆弱性で悪用の標的となってきた製品群です。今回が対象外であることは「SonicWall 製品全般が安全」という意味ではない点に留意が必要です。

対処手順: platform-hotfix へのアップグレード

修正版は以下のとおりです。公式に回避策（Workaround）は提供されていないため、アップグレードが唯一の根本対処となります。

以下、AMC を使用した標準的な適用手順を、公式ドキュメントに基づいて整理します。

事前準備: 構成のバックアップ

アップグレード前に、AMC のエクスポート機能で現在の構成を保存しておくことを推奨します。

1. AMC のメインナビゲーションから System Configuration > Maintenance に移動します。
2. Import or export エリアの Import/Export... をクリックします。
3. Export Configuration セクションで Export... をクリックし、.aea ファイルをローカルに保存します。

ホットフィックスの入手（mysonicwall.com）

1. https://www.mysonicwall.com にログインします。
2. Resources & Support > My Downloads ページで、対象のアプライアンスモデルを選択します。
3. 該当する platform-hotfix ファイルをダウンロードします。
4. ダウンロード後、MySonicWall に表示されるチェックサムとローカルファイルのチェックサムを比較し、ファイルが破損していないことを確認します。

AMC からの適用手順

1. AMC のメインナビゲーションから System Configuration > Maintenance に移動します。
2. System Software Updates セクションの Update エリアで Update をクリックします。
3. Choose File でダウンロードしたホットフィックスファイルを指定します。
4. すぐに適用しない場合は、Advanced セクションを展開して適用スケジュールを設定できます。
5. Install update をクリックします。ファイルのアップロード完了後、インストールは自動で実行され、この段階でのキャンセルはできません。
6. インストール完了後、アプライアンスは自動的に再起動します。

参考: SonicWall KB – How can I upgrade firmware in SMA 1000 series appliance?
“The appliance will automatically restart when the installation of the update or hotfix is completed.”
（アップデートまたはホットフィックスのインストールが完了すると、アプライアンスは自動的に再起動します）
https://www.sonicwall.com/support/knowledge-base/how-can-i-upgrade-firmware-in-sma-1000-series-appliance/kA1VN0000000KIA0A2

適用時の注意点

再起動によるサービス断が発生

SSL-VPN の全ユーザーセッションが切断されるため、適用タイミングは利用の少ない時間帯を選ぶことを推奨します。ただし、今回は悪用進行中のゼロデイであり、KEV の期限設定（登録から 3 日）が示すとおり、計画メンテナンスを待つよりも臨時メンテナンスとして前倒しする判断が妥当なケースです。

CMS（Central Management System）で複数台を管理している環境

CMC（Central Management Console）からマネージドアプライアンスへの適用を行います。

HA 構成・DR 用の待機系も対象

プライマリーのみ適用して待機系が旧バージョンのまま残るケースは典型的な対応漏れです。台帳上のすべての SMA1000（休止中の仮想アプライアンス 8200v を含む）を洗い出して適用してください。

適用後、System Configuration > Maintenance 画面で新しいバージョン番号が反映されていることを確認します。

重要な点として、アップグレードの完了は今回の対応のゴールではありません。すでに悪用が確認されている以上、パッチ適用前に侵害されていた可能性を排除できないためです。SonicWall も「パッチ適用だけでは不十分であり、適用後もログの IOC 確認を行うべき」という趣旨の注意喚起を行っています。次のセクションで、侵害調査の具体的な手順を解説します。

侵害調査: IOC の確認と検出時の対応

今回の対応で最も重要なのがこのセクションです。アップグレードは「これ以降の侵入を防ぐ」対処であり、適用前にすでに侵入されていた場合、その痕跡はアップグレード後も残り続けます。SonicWall の広報担当者も、パッチ適用だけでは十分ではないと明言しています。

参考: Help Net Security – SonicWall SMA appliances targeted in zero-day attacks
“patching alone is not sufficient”
（パッチ適用だけでは不十分である）
https://www.helpnetsecurity.com/2026/07/14/sonicwall-sma-attacks-via-cve-2026-15409-cve-2026-15410/

アドバイザリ記載の 4 つの IOC と確認方法

アドバイザリには 4 つの IOC（Indicators of Compromise: 侵害の痕跡）が記載されています。それぞれ「どこを」「何を基準に」確認するかを整理します。

判定基準として特に明確なのが #1 と #4 です。アドバイザリには、/__api__/login と /__api__/logout という URI は正規の構成には存在しないと明記されています。つまり、これらへの成功応答（HTTP 200）や、構成ファイル内のルート定義が見つかった時点で、グレーではなく黒に近い判定ができます。

参考: SonicWall Security Advisory（SNWLID-2026-0008）
“these URIs do not exist in legitimate configuration”
（これらの URI は正規の構成には存在しません）
https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0008

ログの確認方法（AMC）

extraweb_access.log は Web プロキシサービスの現行ログファイルで、extraweb_access.log1 〜 log7 としてローテーション世代が保持されます。確認は現行ファイルだけでなく、保持されている全世代を対象に行ってください。攻撃活動が数週間前に行われていた場合、痕跡は世代ファイル側にあります。

# エクスポートしたログに対する確認例
grep -E "/__api__/(login|logout)" extraweb_access.log*
grep "/wsproxy" extraweb_access.log* | grep " 101 "

IOC 検出時の対応（再イメージ・認証情報リセット）

IOC が 1 つでも検出された場合、アドバイザリは以下の対応を求めています。

ハードウェアアプライアンス（6210・7210）は再イメージ、仮想アプライアンス（8200v）は再デプロイ

攻撃者が OS レイヤーで永続化している可能性があるため、「不審なファイルの削除」や「設定の巻き戻し」では不十分です。クリーンな状態からの再構築が前提となります。

全ユーザーおよび管理者のパスワードを変更

アプライアンス経由で認証情報が窃取されている前提で対応します。

TOTP トークンをリセット

多要素認証を設定していても、TOTP のシード情報がアプライアンス側に保存されている場合は再発行が必要です。

補足として、再イメージの前に必ずスナップショット（ログ・構成一式）を証跡として保全してください。再イメージは侵害の痕跡を消去する操作でもあるため、原因調査や影響範囲の特定（アプライアンスを踏み台にどこへアクセスされたか）に必要な情報を先に確保しておく必要があります。また、SMA1000 は認証基盤（AD・SAML IdP 等）と連携しているケースが大半です。アプライアンス単体の復旧で完結させず、連携先の認証基盤側でも不審なログオン記録の確認を行うことを推奨します。

再発防止: 管理インターフェースの露出制限

今回のアドバイザリでは公式の回避策（Workaround）が「None」とされています。しかし、恒久的なリスク低減策として実施できることはあります。ポイントは、2 つの脆弱性の入口が異なることです。

• CVE-2026-15409 の入口は WorkPlace インターフェース。リモートアクセス製品の性質上、ユーザー向けの公開は避けられません。
• CVE-2026-15410 の入口は管理コンソール AMC。こちらは本来、インターネットに公開する必要のないインターフェースです。

この構造を踏まえた緩和策を整理します。

AMC への到達性を管理セグメントに限定

AMC（デフォルトは内部インターフェースの TCP 8443）へのアクセスを、上流ファイアウォールの ACL または経路設計で管理端末・踏み台サーバーのみに制限します。管理者認証後のコード注入（CVE-2026-15410 相当の脆弱性）は今後も発見され得ますが、AMC に到達できる送信元を絞っておけば、脆弱性が公開されてからパッチ適用までの間のリスクを構造的に下げられます。

ログの外部転送を構成

今回の IOC 確認はアプライアンス内のログが前提ですが、攻撃者に OS レイヤーまで侵入された場合、ローカルログは改ざん・消去され得ます。syslog による SIEM への転送を構成しておくと、アプライアンス外に改ざん困難な証跡を確保できます。ネットワーク側での異常検知という観点は、関連記事『NDR の導入ポイント』も参考になります。

PSIRT アドバイザリの定期確認を運用に組み込み

SonicWall 製品は近年、境界機器を狙う攻撃キャンペーンの標的となる頻度が高く、2026 年に入ってからも SMA1000 では別の脆弱性群（CVE-2026-4112 ほか）が修正されています。ベンダーの PSIRT ページの定期確認と通知登録を推奨します。FortiGate 向けに解説した PSIRT チェック手順の考え方は SonicWall にもそのまま応用できます。

まとめ

SonicWall SMA1000 の 2 件のゼロデイ脆弱性は、すでに悪用が確認された状態で公開されており、修正版へのアップグレードだけで対応を完了させるべきではありません。IOC の確認までを一連の対応として実施することが重要です。

• CVE-2026-15409（SSRF・CVSS 10.0・認証不要）と CVE-2026-15410（コード注入・CVSS 7.2・認証後）が組み合わせて悪用されている
• 対象は SMA1000（6210・7210・8200v）のみで SMA100 シリーズとファイアウォールの SSL-VPN は対象外
• 修正版は 12.4.3-03453 または 12.5.0-02835 以降の platform-hotfix
• 公式の回避策は「なし」でアップグレードが唯一の根本対処
• HA・DR 用の待機系を含むすべての SMA1000 が適用対象
• アップグレード後は 4 つの IOC をログ全世代と conf.json で確認
• IOC 検出時は再イメージ・パスワード変更・TOTP リセットまで実施
• AMC の到達性を管理セグメントに限定する構成が恒久的なリスク低減につながる

以上、最後までお読みいただきありがとうございました。