FlawOpen

flawopen.com/Teardowns/cve-2026-102255-sonicwall-sma1000-workplace-ssrf

● CVE-2026-102255 · CVSS 10.0[1] · 緊急
セキュリティ研究 · FlawOpen

CVE-2026-102255：SonicWall SMA1000 WorkPlace の SSRF

CVE-2026-102255 は SonicWall SMA1000 WorkPlace の CVSS 10.0 認証前 SSRF です。10月12日、MS-ISAC は同報告の4件について、現時点で実環境における悪用報告はないとしました。また、この SSRF を、認証済み管理者権限が必要な別のコマンドインジェクション CVE-2026-102256 と連鎖させた場合、リモートコード実行につながる可能性があると評価しています。報告には連鎖の仕組みや認証条件を満たす方法は記載されておらず、実証された攻撃チェーンではなく条件付きのリスク評価です。10月9日には本 CVE と整合するハニーポット試行が報告されましたが、侵害成功は確認されていません。修正版 platform hotfix を適用してください。[1], [2], [3], [4], [5], [6]

💡 わかりやすい解説 (ELI5)

装置を、部屋の間で伝言を運ぶ受付係だと考えてください。この欠陥では、見知らぬ人が受付係に、本人確認後でないと入れない部屋へ伝言を届けさせられます。SonicWall はこの経路を修正しましたが、公開情報には内部ルートやソースコードの修正差分はありません。[1]

主要な概念と専門用語

サーバーサイドリクエストフォージェリ（SSRF）
信頼できない利用者が選んだリクエストをサーバーに送らせる問題です。ここでは装置が要求元に代わって内部機能へ到達する可能性があります。[1], [3]

フレームワーク対応

  • このガイドで説明する弱点の CWE 参照： CWE-918

根本原因の分析 (Root Cause)

SonicWall は SMA1000 Appliance WorkPlace インターフェースに意図しない代替アクセス経路があると説明しています。未認証のリモート攻撃者が装置に自分の代わりにリクエストを送らせ、内部機能へ到達して不正操作を行う可能性があります。SonicWallの通知にはファームウェアのソース差分は掲載されていません。BleepingComputerは研究者Ryan Dewhurstの説明として、ハニーポットがWorkPlace Extrawebに対するOPTIONSリクエストを検知し、ローカルのCouchDBサービスを狙っていたと報じています。報道はシステム侵害の成功を確認していません。本記事では、確認済みの悪用ではなく、出典を明示した試行の報告として扱います。報告されたpayloadや認証情報は再掲しません。SonicWall は CVSS 10.0 Critical とし、CVE レコードは CWE-918 を記載しています。10月の脆弱性は他の報告済み SonicWall 脆弱性と無関係と説明しています。この CVE を過去の SMA1000 開示と一つの攻撃チェーンにまとめないでください。 SonicWall の10月6日の通知では、その時点で実環境の悪用を示す証拠はないとされていました。10月9日、BleepingComputer は研究者 Ryan Dewhurst の話として、Previdian のハニーポットが本 CVE と整合する試行を検知したと報じました。システム侵害の成功は確認されていません。 2026年10月12日更新：MS-ISAC は同報告の4件について、現時点で実環境における悪用報告はないとしています。これは10月9日にハニーポット試行が報告されたことと矛盾しません。試行は悪用成功の証拠ではなく、MS-ISAC は被害者を特定していません。同じ報告は、認証前 SSRF の CVE-2026-102255 を、認証済み管理者権限が必要な別の OS コマンドインジェクション CVE-2026-102256 と連鎖させた場合、リモートコード実行とシステム全体の侵害につながる可能性があると評価しています。認証要件をどう満たすかは説明されず、実証された手順も観測された攻撃チェーンの報告もありません。政府機関による条件付きのリスク評価として扱い、確認済みまたは再現可能な攻撃チェーンとは表現しないでください。SonicWall は修正版として 12.4.3-03670+ と 12.5.0-03082+ を提示しています。チェーンが実証されたかどうかにかかわらず更新してください。[1], [2], [3], [4], [6]

ステップ・バイ・ステップの攻撃フロー

ステップ 1

未認証リクエストが WorkPlace に到達

SonicWallは認証前の問題がSMA1000 WorkPlaceにあると説明しています。BleepingComputerはハニーポットがWorkPlace ExtrawebへのOPTIONS試行を検知したと報じていますが、侵害成功を示すものではありません。[1], [4]

ステップ 2

装置が要求元に代わって処理する

ベンダーによると、内部機能への到達や不正操作が可能です。BleepingComputerによれば、試行はローカルのCouchDBを狙っていましたが、研究者は侵害成功を確認していません。[1], [4]

ステップ 3

運用対応：パッチを適用して露出状況を調査する

SonicWall は 12.4.3-03670+ と 12.5.0-03082+ を修正済みビルドとして示しています。パッチ適用が遅れる場合は、暫定措置として WorkPlace の公開範囲を制限し、ログを保全して調査してください。報告された試行は、侵害の成功を立証するものではありません。[1], [4], [5]

ソースコード比較：脆弱 vs 堅牢化

ファームウェアのソースコードと修正差分は公開されていません。この汎用 Python 例では呼び出し元は固定サービス ID だけを選び、接続先とパスはアプリケーションが管理し、リダイレクトを無効にします。SonicWall のコードでも CVE の再現でもなく、完全な SSRF 対策でもありません。製品には SonicWall hotfix を適用してください。[1]

ソース抜粋: Generic SSRF defense illustration; not SonicWall source

脆弱な実装
# 一般化した例であり、SonicWall のソースコードでも脆弱性の再現でもありません。
def fetch_health(user_supplied_url, session):
    return session.get(user_supplied_url, timeout=3)
堅牢化されたセキュアパッチ
# 一般的な SSRF 防御パターンであり、SonicWall のソースコードや完全なパッチではありません。
from urllib.parse import urljoin

SERVICE_PATHS = {"status": "/health"}
BASE_URLS = {"status": "https://status.example.internal"}

def fetch_health(service_id, session):
    base = BASE_URLS.get(service_id)
    path = SERVICE_PATHS.get(service_id)
    if base is None or path is None:
        raise ValueError("unknown service")
    # ユーザー入力で選べるのは固定された機能であり、URL やホストではありません。
    return session.get(urljoin(base, path), timeout=(2, 3), allow_redirects=False)

エンジニアリング＆システム堅牢化チェックリスト

参考資料