CVE-2026-4408を詳しく解説―Samba未認証RCEの影響条件・確認方法・対策

« ハブ記事「Linuxカーネル432件CVE公開ニュースから16件を洗い出した話」へ戻る

概要

CVE-2026-4408は、Sambaのパスワード検査機能に存在するOSコマンドインジェクション脆弱性です。

攻撃が成功すると、認証されていない遠隔の攻撃者が、Sambaサーバー上で任意のOSコマンドを実行する可能性があります。

ただし、Sambaをインストールしているだけで、直ちに攻撃を受ける脆弱性ではありません。

脆弱性が成立するには、次のような複数の非標準設定が必要です。

check password scriptを設定している
コマンドラインにユーザー名を展開する%uを使用している
rpc start on demand helpers = noに設定している
samba-dcerpcdを独立したシステムサービスとして常駐起動している
攻撃者からSAMR DCE/RPCサービスへ到達できる

Sambaプロジェクトは本脆弱性をCVSS 3.1で10.0、NVDは9.8、Red Hatは9.0と評価しています。したがって、「CVSS 9.8」とだけ書くより、評価機関によってスコアが異なることを併記するのが正確です。

結論・要点

CVE-2026-4408は、Sambaのcheck password scriptに、クライアントが指定できるユーザー名を%uで埋め込んだ場合に発生するOSコマンドインジェクション脆弱性です。

影響を受ける可能性があるのは、主に次の環境です。

Sambaファイルサーバー
Samba Classic Domain Controller
独立したsamba-dcerpcdを常駐起動している環境

一方で、次の環境は本脆弱性の直接的な影響を受けません。

Samba関連パッケージが入っていない
check password scriptを使用していない
設定に%uが含まれていない
samba-dcerpcdを独立起動していない
攻撃者からDCE/RPCへ到達できない

対応の優先順位は次のとおりです。

修正済みパッケージへ更新する
check password scriptから%uを削除する
rpc start on demand helpers = yesへ戻す
不要なsamba-dcerpcdの独立起動を停止する
SMBおよびDCE/RPCへの接続元を制限する

CVSS評価

評価元	CVSS	深刻度
Samba公式	10.0	Critical
NVD	9.8	Critical
Red Hat	9.0	Critical

CVE-2026-4408のCVSSスコアは、評価機関によって異なります。
評価差が生じる主な理由は、複数の非標準設定が必要である点を、攻撃条件の複雑さとしてどのように扱うかが異なるためです。
スコアに差はありますが、成立条件を満たす環境では、未認証の遠隔攻撃者による任意コマンド実行につながるため、緊急性の高い脆弱性です。

この記事で分かること

この記事では、次の内容を初心者にも分かるように解説します。

CVE-2026-4408で何が起きるのか
どのSamba構成が影響を受けるのか
check password scriptとは何か
%uがなぜ危険なのか
samba-dcerpcdとの関係
Linuxサーバーでの確認方法
修正パッケージへの更新方法
暫定対策
WAF・IPS・EDRで補助できる範囲
修正後の動作確認
再発防止

対象読者・前提環境

対象読者は次のとおりです。

LinuxでSambaファイルサーバーを運用している人
NASや社内ファイルサーバーを管理している人
RHEL、Oracle Linux、AlmaLinux、Rocky Linuxを使用している人
Ubuntu、Debian上でSambaを使用している人
脆弱性診断ツールでCVE-2026-4408を検出された人
Sambaの設定を詳しく把握していないサーバー管理者

確認コマンドは、原則として対象のSambaサーバー上で、管理者権限またはsudoを使用して実行します。

用語と全体像

Sambaとは

Sambaは、LinuxやUnix系OSからWindowsのファイル共有機能を提供するソフトウェアです。

簡単にたとえると、Linuxサーバーを「Windowsから開ける共有フォルダー」に変える仕組みです。

正式には、SMB/CIFSプロトコル、認証、プリンター共有、ドメイン関連機能などを提供するソフトウェア群です。

RCEとは

RCEはRemote Code Executionの略です。

簡単にたとえると、攻撃者がネットワーク越しに、管理対象サーバーのキーボードを勝手に操作できるような状態です。

実際には、攻撃者がサーバー上で任意のプログラムやOSコマンドを実行できる脆弱性を指します。

コマンドインジェクションとは

コマンドインジェクションは、入力データの中にOSコマンドとして解釈される文字を混入させ、予定していないコマンドを実行させる攻撃です。

たとえば、アプリケーションが次のような文字列を作成するとします。

/usr/local/bin/check-user USERNAME

USERNAMEに通常のユーザー名が入る場合は問題ありません。

/usr/local/bin/check-user kururu

しかし、ユーザー名にシェルが特別な意味で処理する文字が含まれ、それが無害化されない場合、本来のコマンドとは別の処理が実行される可能性があります。

この問題は、正式にはCWE-78「OSコマンドで使用される特殊要素の不適切な無害化」に分類されています。

CVE-2026-4408で何が起きたのか

SambaのファイルサーバーとClassic Domain Controllerは、SAMRと呼ばれるDCE/RPCインターフェース上で、次のRPCサービスを提供する場合があります。

SamValidatePasswordChange
SamValidatePasswordReset

これらは、パスワードの変更やリセット時に、設定されたcheck password scriptへユーザー名とパスワードを渡します。

問題は、check password scriptの設定に%uが含まれていた場合です。

%uは、クライアントが指定したユーザー名へ置き換えられる置換文字です。

このクライアント制御可能なユーザー名が、シェルメタ文字を適切にエスケープされないままコマンドラインへ展開されました。その結果、攻撃者が細工したユーザー名によって、OSコマンドを実行できる可能性が生じました。

発生条件とメカニズム

NVDの記載によれば、本脆弱性は以下の非標準的な設定が揃った場合にのみ成立します。

Samba の設定ファイル smb.conf において check password script パラメータが有効化されている。
スクリプト引数として %u（クライアントが指定したユーザー名に置換されるマクロ）が使用されている。

クライアントが指定したユーザー名文字列が、シェルのメタ文字（; や | など）をエスケープしないまま check password script に渡されるため、ユーザー名の中に仕込んだコマンドが実行されてしまいます。

ローカル隔離Docker環境での再現検証

本脆弱性の中心となる問題は、外部から受け取った文字列を安全に処理せず、シェル経由で実行することです。

隔離Docker環境では、次の処理を再現できます。

外部入力
   ↓
コマンド文字列へ直接連結
   ↓
/bin/sh -cで実行
   ↓
シェル特殊文字が命令として解釈される

無害なマーカーファイルが作成された場合、OSコマンドインジェクションの基本的な仕組みを確認できたといえます。

ただし、実際のSamba本体を使用していない場合は、次のように表現するのが正確です。

CVE-2026-4408と同型のOSコマンドインジェクションメカニズムを、インターネットへ接続されていない隔離Docker環境で再現しました。

実際のCVE再現と表現するには、少なくとも次の条件を確認する必要があります。

影響を受けるSambaを使用した
問題のあるcheck password scriptを設定した
SAMR DCE/RPC経路を通過した
認証なしで対象処理へ到達した
Sambaプロセスの権限でコマンドが実行された

公開記事には、実環境へ転用可能な攻撃用ペイロードを掲載せず、無害なマーカーファイルなどで検証してください。

CVE-2026-4408 check password script インジェクション再現の実行ログ

検証後、コンテナ・隔離ネットワークは直ちに削除済みです。

攻撃が成立する流れ

全体の流れを図にすると、次のようになります。

┌──────────────────┐
│ 遠隔の攻撃者       │
│ Samba認証情報なし  │
└─────────┬────────┘
          │
          │ 細工したユーザー名
          ▼
┌────────────────────────────┐
│ SAMR DCE/RPC                │
│ PasswordChange / Reset      │
└─────────┬──────────────────┘
          │
          │ ユーザー名を%uへ展開
          ▼
┌────────────────────────────┐
│ check password script       │
│ /path/check-password %u     │
└─────────┬──────────────────┘
          │
          │ シェル特殊文字を未処理
          ▼
┌────────────────────────────┐
│ シェルが別の命令として解釈  │
└─────────┬──────────────────┘
          │
          ▼
┌────────────────────────────┐
│ Sambaサーバー上で           │
│ 任意のOSコマンドが実行      │
└────────────────────────────┘

攻撃者はSambaへの正規ログインを完了する必要がありません。

さらに、管理者や利用者がファイルを開くなどの操作も必要ありません。

このため、成立条件を満たした環境では深刻な問題になります。

すべてのSambaサーバーが危険なわけではない

CVE-2026-4408は、複数の条件がそろった場合に成立します。

成立条件1：対象のSamba動作モードである

対象となるのは、主に次の環境です。

Sambaファイルサーバー
Classic Domain Controller
非AD型の従来ドメインコントローラー

SambaのActive Directory Domain Controllerは、%uを同じ方法では展開しないため、Samba公式は対象外と説明しています。

ただし、「AD DCだから何も確認しなくてよい」という意味ではありません。

同じサーバーでファイルサーバー機能や別のSambaプロセスを動かしている場合は、実際の設定とプロセスを確認してください。

成立条件2：check password scriptを使用している

次のような設定が存在する必要があります。

[global]
check password script = /usr/local/sbin/check-password %u

check password scriptは標準構成で必須となる機能ではありません。

組織独自のパスワードポリシー確認、外部認証システムとの連携、古い社内システムとの連携などで設定されている可能性があります。

成立条件3：設定値に%uが含まれている

%uはユーザー名へ置き換えられます。

次の設定は、本脆弱性の影響を受ける可能性があります。

check password script = /usr/local/sbin/check-password %u

次のようにシングルクォートを付けても、完全な対策にはなりません。

check password script = /usr/local/sbin/check-password '%u'

Samba公式は、シングルクォートで囲むと危険性は低下するものの、コマンドラインオプションを注入される可能性は残ると説明しています。

したがって、'%u'への変更だけで修正完了としてはいけません。

成立条件4：rpc start on demand helpersがnoである

通常、rpc start on demand helpersのデフォルト値はyesです。

rpc start on demand helpers = yes

yesの場合、samba-dcerpcdは必要に応じてsmbdなどから起動されます。

本脆弱性の影響を受ける標準的なファイルサーバー構成では、次の非デフォルト設定が必要です。

rpc start on demand helpers = no

さらに、samba-dcerpcdがsystemdなどから独立したデーモンとして起動されている必要があります。Samba公式ドキュメントでも、samba-dcerpcdを独立起動する場合は、このパラメーターをnoにする必要があると説明されています。

成立条件5：SAMR DCE/RPCへネットワーク到達できる

本脆弱性は、単純な共有フォルダーへのアクセスだけではなく、NCACN_IP_TCP上のSAMR DCE/RPCサービスを経由します。

そのため、TCP 139番と445番だけを見て、「CVE-2026-4408の経路は完全に閉じている」と断定しない方が安全です。

RPC over TCPの標準では、TCP 135番のエンドポイントマッパーと、選択されたRPCエンドポイントが使用される場合があります。実際の待受ポートとプロセスをssなどで確認してください。

影響判定フロー

次の順番で確認すると、効率的に判定できます。

Sambaパッケージが存在するか
        │
        ├─ いいえ → 本CVEの直接影響なし
        │
        ▼
Sambaサーバープロセスが動作しているか
        │
        ├─ いいえ → 現時点の攻撃経路なし
        │
        ▼
check password scriptが設定されているか
        │
        ├─ いいえ → 本CVEの成立条件を満たさない
        │
        ▼
設定に%uが含まれるか
        │
        ├─ いいえ → コマンドインジェクション条件なし
        │
        ▼
rpc start on demand helpers = no か
        │
        ├─ いいえ → 公式記載の成立条件を満たさない
        │
        ▼
samba-dcerpcdが独立サービスとして動作しているか
        │
        ├─ いいえ → 公式記載の成立条件を満たさない
        │
        ▼
外部または信頼できないネットワークから到達できるか
        │
        ├─ いいえ → 外部からの悪用可能性は大幅に低下
        │
        ▼
優先度「緊急」でアップデートと設定修正

確認方法1：Sambaがインストールされているか

RHEL・Oracle Linux・AlmaLinux・Rocky Linux

目的

Samba関連のRPMパッケージが存在するか確認します。

実行場所

調査対象のLinuxサーバー上です。

コマンド

rpm -qa | grep -Ei '^samba($|-)'

正常例：Sambaを使用していないサーバー

出力なし

要確認例

samba-4.23.5-107.el10_2.x86_64
samba-common-4.23.5-107.el10_2.noarch
samba-dcerpc-4.23.5-107.el10_2.x86_64

判断方法

出力がなければ、RPMとしてSamba関連パッケージがインストールされていない可能性が高い状態です。

出力がある場合は、パッケージの存在だけで脆弱と断定せず、設定とプロセスを続けて確認します。

Ubuntu・Debian

dpkg-query -W -f='${binary:Package}\t${Version}\n' 'samba*' 2>/dev/null

install ok installedの状態をより厳密に確認する場合は、次も使用できます。

dpkg-query -W -f='${db:Status-Abbrev}\t${binary:Package}\t${Version}\n' \
  'samba*' 2>/dev/null

確認方法2：Sambaのバージョンを確認する

コマンド

smbd --version

正常例

Version 4.24.3

要確認例

Version 4.24.2

ただし、Linuxディストリビューションでは、上流のバージョン番号を大きく変更せず、セキュリティ修正だけをバックポートする場合があります。

そのため、4.24.3未満だから必ず未修正とは判断できません。

RHEL系では、RPMのリリース番号とベンダーアドバイザリを確認します。

rpm -q samba

Oracle Linux 10向けのELSA-2026-22963では、samba-4.23.5-109.el10_2が更新パッケージとして公開されています。

確認方法3：check password scriptを確認する

目的

実際に読み込まれるSamba設定で、check password scriptが有効か確認します。

推奨コマンド

sudo testparm -s \
  --parameter-name='check password script'

testparmは、Sambaの設定ファイルを読み込み、構文や有効な設定値を確認する公式ツールです。

影響を受けない例

出力なし

または、空の値が表示されます。

危険性がある例

/usr/local/sbin/check-password %u

判断方法

次の両方に該当する場合は、調査を継続します。

check password scriptが空ではない
設定値に%uが含まれる

直接設定ファイルを検索する場合は、次のコマンドも使用できます。

sudo grep -RniE \
  '^[[:space:]]*check[[:space:]]+password[[:space:]]+script[[:space:]]*=' \
  /etc/samba 2>/dev/null

ただし、includeや動的設定が使用されている環境では、単純なgrepだけでは有効設定を取りこぼす可能性があります。

最終判断にはtestparmの結果を使用してください。

確認方法4：rpc start on demand helpersを確認する

コマンド

sudo testparm -s \
  --parameter-name='rpc start on demand helpers'

通常の設定

yes

yesはデフォルト値です。

本脆弱性の成立条件に近づく設定

no

noが表示された場合は、なぜ独立起動へ変更したのか、設定変更の履歴を確認してください。

確認方法5：samba-dcerpcdの起動状態を確認する

systemdサービスの確認

sudo systemctl list-unit-files --type=service |
  grep -Ei 'samba-dcerpcd|samba|smb|nmb'

実行中プロセスの確認

pgrep -a samba-dcerpcd

影響条件を満たさない例

出力なし

要確認例

1234 /usr/sbin/samba-dcerpcd --foreground

さらにsystemdから常駐起動されているか確認します。

sudo systemctl status samba-dcerpcd.service

環境によってはサービス名が異なったり、独立したunitが存在しなかったりします。

pgrep、ps、systemctlを組み合わせて判断してください。

確認方法6：待受ポートを確認する

コマンド

sudo ss -lntup |
  grep -Ei 'samba|smbd|dcerpc|:(135|139|445)\b'

確認ポイント

TCP 139番
TCP 445番
TCP 135番
samba-dcerpcdが使用しているその他のTCPポート
0.0.0.0や[::]で待ち受けていないか
インターネット側インターフェースで待ち受けていないか

比較的安全な例

LISTEN 0 50 192.168.10.20:445 0.0.0.0:* users:(("smbd",pid=1234,fd=45))

社内ネットワークのIPだけで待ち受けています。

危険性が高い例

LISTEN 0 50 0.0.0.0:445 0.0.0.0:* users:(("smbd",pid=1234,fd=45))

すべてのIPv4インターフェースで待ち受けています。

ただし、0.0.0.0で待ち受けていても、ファイアウォールで外部通信を遮断している場合があります。待受状態とファイアウォール設定の両方を確認してください。

確認方法7：ファイアウォールを確認する

firewalld

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all
sudo firewall-cmd --list-all-zones

nftables

sudo nft list ruleset

外部公開の確認

別の管理端末から、許可されたネットワーク範囲について確認します。

nmap -Pn -sT -p 135,139,445 SERVER_IP

第三者が管理するサーバーや、許可を得ていないシステムに対して実行してはいけません。

正常例

135/tcp filtered
139/tcp filtered
445/tcp filtered

要確認例

135/tcp open
139/tcp open
445/tcp open

openが表示された場合でも、それだけで脆弱性の存在を証明するものではありません。

設定条件とバージョンを併せて確認します。

対処方法1：Sambaをアップデートする

最優先の恒久対策は、ベンダーが提供する修正パッケージへのアップデートです。

Sambaプロジェクトは、次のバージョンを修正版として公開しています。

Samba 4.22.10
Samba 4.23.8
Samba 4.24.3

その後に公開された同一系列の新しいバージョンにも修正が含まれます。

アップデート前のバックアップ

Samba設定を変更する前に、設定ファイルを保存します。

sudo cp -a /etc/samba \
  "/root/samba-backup-$(date +%Y%m%d-%H%M%S)"

共有データについても、別ストレージやスナップショットへバックアップしてください。

特に、ドメインコントローラーや認証連携を行っている環境では、設定ファイルだけのバックアップでは不十分です。

RHEL系・Oracle Linux系

まず、CVEに対応するアップデート情報を確認します。

sudo dnf updateinfo info --cves CVE-2026-4408

Samba関連パッケージを更新します。

sudo dnf update 'samba*'

更新後にバージョンを確認します。

rpm -q samba samba-dcerpc

Oracle Linux 10では、ELSA-2026-22963が2026年7月16日に公開され、4.23.5-109.el10_2系列の更新パッケージが提供されています。ELSAはOracle Linux向けのセキュリティアドバイザリであり、Sambaプロジェクト全体のアドバイザリ名ではありません。

Ubuntu・Debian系

sudo apt update
sudo apt install --only-upgrade \
  samba samba-common samba-common-bin

利用しているディストリビューションのセキュリティトラッカーで、CVE-2026-4408の修正状態を確認してください。

対処方法2：%uをcheck password scriptから削除する

アップデートをすぐに実施できない場合でも、%uを削除します。

修正前

[global]
check password script = /usr/local/sbin/check-password %u

修正後の考え方

[global]
check password script = /usr/local/sbin/check-password

ユーザー名は、コマンドライン引数の%uではなく、Sambaが提供する次の環境変数から取得します。

SAMBA_CPS_ACCOUNT_NAME

Samba公式も、%uを削除し、SAMBA_CPS_ACCOUNT_NAME環境変数からユーザー名を取得する方法を回避策として案内しています。

シェルスクリプトでは、たとえば次のように値を取得します。

#!/bin/sh

account_name="${SAMBA_CPS_ACCOUNT_NAME:?account name is not set}"

# 以降は既存のパスワード検査処理を行う
# ユーザー入力をevalや文字列連結で実行しない

既存のスクリプトへ値を渡す場合は、次の原則を守ります。

evalを使わない
sh -cへ文字列を渡さない
コマンドを文字列連結しない
固定された実行ファイルを直接呼び出す
オプション終端を表す--を使用する
許可するユーザー名の文字種と長さを制限する

対処方法3：rpc start on demand helpersをyesに戻す

暫定対策として、次の設定を使用します。

[global]
rpc start on demand helpers = yes

yesはデフォルト値です。

この設定では、標準的な構成において、脆弱なコード経路へ外部から到達できなくなるとSamba公式は説明しています。

変更前に、samba-dcerpcdを独立起動する必要が本当にあるのか確認してください。

独立起動を前提としたシステムで、理由を確認せず設定だけを変更すると、必要なRPCサービスが起動しなくなる可能性があります。

対処方法4：不要なSambaサービスを停止する

Sambaを使用していないサーバーでは、サービスを停止・無効化します。

sudo systemctl disable --now smb.service
sudo systemctl disable --now nmb.service
sudo systemctl disable --now samba-dcerpcd.service

実際に存在するunitだけを対象にしてください。

先に次のコマンドで確認します。

sudo systemctl list-unit-files |
  grep -Ei 'smb|nmb|samba|dcerpc'

Samba自体が不要であれば、依存関係と利用状況を確認したうえでアンインストールします。

sudo dnf remove samba

アンインストールは共有機能や認証機能を停止させます。

実行前に、Sambaがどの業務で使用されているか確認してください。

対処方法5：ネットワークから隔離する

SambaやDCE/RPCをインターネットへ直接公開しない構成を推奨します。

Internet
   │
   X 直接接続を拒否
   │
Firewall／VPN／ZTNA
   │
社内管理ネットワーク
   │
Sambaサーバー

許可する通信元は、次の範囲へ限定します。

社内LAN
管理用VLAN
VPN接続元
バックアップサーバー
必要なアプリケーションサーバー

「どこからでも接続可能」にするのではなく、送信元IPアドレスを許可リスト方式で制御します。

WAF・IPS・EDRによる補助対策

WAF

一般的なWeb Application Firewallは、HTTPやHTTPSを検査します。

CVE-2026-4408はSambaのSAMR DCE/RPC経路に存在するため、Cloudflare WAFやWebサーバー向けWAFだけでは直接防御できません。

WAFを導入済みでも、Samba用ポートやRPCポートが別経路で公開されていれば保護対象外です。

IPS

IPSがDCE/RPCプロトコルを解析し、CVE-2026-4408に対応したシグネチャを持っている場合は、攻撃通信を検知・遮断できる可能性があります。

ただし、次の理由から恒久対策の代わりにはなりません。

シグネチャ公開前は検知できない
暗号化や断片化によって検知が難しくなる場合がある
亜種や回避手法を見逃す可能性がある
内部ネットワークからの攻撃を監視していない場合がある

優先順位は次のとおりです。

アップデート
   ↓
危険な設定の削除
   ↓
ネットワーク制限
   ↓
IPSによる補助検知

EDR

EDRでは、次のようなプロセス関係を高い優先度で監視します。

samba-dcerpcd
   └─ /bin/sh
       ├─ curl
       ├─ wget
       ├─ python
       ├─ bash
       └─ その他の管理コマンド

通常の運用で、samba-dcerpcdからシェルやダウンロードツールが起動する必要がない場合、この親子関係は重要な検知条件になります。

ただし、EDRはコマンド実行後に検知する仕組みです。

脆弱性を修正せず、EDRだけに依存してはいけません。

設定変更後の構文確認

設定を変更したら、サービスを再起動する前に構文を確認します。

sudo testparm -s

正常例

Loaded services file OK.

異常例

Error loading services.

異常が表示された場合は、Sambaを再起動しないでください。

バックアップした設定と比較し、構文エラーを修正します。

サービスの再起動

構文確認が正常だった場合だけ再起動します。

RHEL系では、一般的に次のようなサービス名が使用されます。

sudo systemctl restart smb.service

winbindや独立したnmbを使用している場合は、対象サービスも確認します。

sudo systemctl restart winbind.service
sudo systemctl restart nmb.service

独立したsystemd unitの構成はディストリビューションや役割によって異なります。

存在しないサービス名を推測で操作せず、次の結果を確認してください。

sudo systemctl list-units --type=service |
  grep -Ei 'samba|smb|nmb|winbind|dcerpc'

動作確認

1. 設定値を再確認する

sudo testparm -s \
  --parameter-name='check password script'

sudo testparm -s \
  --parameter-name='rpc start on demand helpers'

期待する結果は次のとおりです。

check password script:
%uが含まれていない

rpc start on demand helpers:
yes

2. パッケージを再確認する

rpm -q samba samba-dcerpc

またはUbuntu・Debianでは次を使用します。

dpkg-query -W samba samba-common samba-common-bin

3. サービス状態を確認する

sudo systemctl --no-pager --full status smb.service

正常例

Active: active (running)

異常例

Active: failed

4. ログを確認する

sudo journalctl -u smb.service \
  --since '-15 minutes' \
  --no-pager

failed、error、panic、invalidなどが記録されていないか確認します。

5. 共有フォルダーへの接続を確認する

許可されたクライアントから、既存の共有へ接続します。

smbclient -L //SERVER_NAME -U USER_NAME

次を確認します。

正常に認証できる
共有一覧が表示される
読み取り権限が維持されている
書き込み権限が過剰になっていない
パスワード変更処理が必要な場合は正常に動作する

再発防止

1. 外部入力をコマンドラインに直接展開しない

%uのように、利用者が指定できる値をコマンド文字列へ直接埋め込まない設計にします。

次の構造を避けます。

固定コマンド + 空白 + 利用者入力

代わりに、次の方法を使用します。

環境変数
標準入力
固定されたAPI
配列形式の引数
許可リストによる入力検証

2. 非デフォルト設定を台帳化する

次のような設定は、変更理由を記録します。

rpc start on demand helpers = no

最低限、次の情報を残します。

項目	記録内容
設定名	rpc start on demand helpers
変更前	yes
変更後	no
変更日	YYYY-MM-DD
変更者	担当者名
目的	独立RPCサービス起動のため
影響	samba-dcerpcdが常駐
承認者	責任者
廃止条件	対象システム廃止時

3. Samba設定を定期的に監査する

次のコマンドを定期監査へ組み込みます。

sudo testparm -s
sudo testparm -s --parameter-name='check password script'
sudo testparm -s --parameter-name='rpc start on demand helpers'
pgrep -a samba-dcerpcd
sudo ss -lntup

4. 設定ファイルをGitなどで差分管理する

秘密情報を除外したうえで、smb.confの変更履歴を管理します。

次のような危険な変更を早期に検知できます。

- rpc start on demand helpers = yes
+ rpc start on demand helpers = no

+ check password script = /usr/local/bin/check-password %u

5. 脆弱性情報とディストリビューション情報を分けて管理する

上流Sambaの修正版と、各Linuxディストリビューションの修正版は一致しない場合があります。

次の3点を分けて記録します。

上流Sambaの修正版
OSベンダーの修正RPMまたはDEB
実機にインストールされているパッケージ

単純に4.24.3より小さいという条件だけで、脆弱と判定しないようにします。

ローカル隔離Docker検証をどう評価するか

今回の隔離Docker環境で行った検証は、次の仕組みを確認するものです。

外部入力
  ↓
エスケープせずコマンド文字列へ連結
  ↓
シェル経由で実行
  ↓
入力に含まれる特殊文字が命令として解釈される

実際のCVE再現と断定するには、少なくとも次を確認する必要があります。

影響を受けるSamba実装を使用した
問題のあるcheck password scriptを設定した
SAMR DCE/RPC経路を通過した
認証なしで該当RPC処理へ到達した
Sambaプロセスの権限で処理が実行された

公開記事では、悪用可能なペイロードや外部サーバーへの接続方法を掲載せず、無害な動作確認に限定するのが適切です。

kurutann.comにおける影響評価

実機確認で、次の状態が確認できているとします。

Samba関連パッケージがインストールされていない
smbdが存在しない
samba-dcerpcdが存在しない
Samba関連プロセスが起動していない
TCP 139番と445番が遮断されている

この場合、CVE-2026-4408の実行主体となるSambaコンポーネント自体が存在しません。

したがって、確認時点のkurutann.com本番VPSは、CVE-2026-4408の直接的な影響対象ではないと判断できます。

ただし、「リスクは完全にゼロ」という絶対表現より、次の表現の方が技術的に正確です。

実機調査時点では、Samba関連パッケージおよび対象プロセスが存在しないため、CVE-2026-4408の成立条件を満たしておらず、本脆弱性による直接的な影響はありません。

また、139番と445番の遮断は有効な防御ですが、本件はDCE/RPC over TCPに関係します。

影響判定の主な根拠は「139/445が閉じていること」ではなく、次の事実です。

Sambaパッケージがない
        ＋
samba-dcerpcdがない
        ＋
脆弱な設定がない

確認証跡として、次の結果を保存しておくとよいでしょう。

rpm -qa | grep -Ei '^samba($|-)'
command -v smbd
command -v samba-dcerpcd
pgrep -a samba-dcerpcd
sudo ss -lntup
sudo firewall-cmd --list-all-zones

注意点・よくある誤解

誤解1：Sambaが入っていれば全台が未認証RCEになる

違います。

複数の非標準設定が必要です。

特に重要なのは次の組み合わせです。

check password scriptに%u
        ＋
rpc start on demand helpers = no
        ＋
samba-dcerpcdの独立常駐

誤解2：%uをシングルクォートで囲めば安全

完全な対策ではありません。

シェルによる命令分割の危険性は低下しますが、オプションインジェクションの可能性が残ります。

%u自体を削除してください。

誤解3：Samba 4.23.5だから必ず脆弱

ディストリビューションのバックポート状況によります。

Oracle Linux 10では、上流の4.23.8ではなく、4.23.5-109.el10_2として修正が提供されています。

誤解4：TCP 445番を閉じれば確認完了

本件はSAMR DCE/RPC over TCPに関係します。

445番だけでなく、実際にどのプロセスがどのTCPポートを待ち受けているか確認します。

誤解5：CVSSは9.8で確定している

評価機関によって異なります。

評価元	スコア	主な差
Samba公式	10.0	AC:L、S:C
NVD	9.8	AC:L、S:U
Red Hat	9.0	AC:H、S:C
Amazon Linux	8.1	AC:H、S:U

主な違いは、複数の非標準設定が必要なことを「攻撃条件の複雑さ」に含めるか、脆弱な環境が既に構成されている前提で評価するかです。

CVSSの違いを理由に対応を先送りするのではなく、成立条件を満たすサーバーを優先して修正します。

悪用状況

2026年7月27日時点で確認したSamba公式アドバイザリ、NVD、主要OSベンダーの一次情報からは、CVE-2026-4408が実環境で大規模に悪用されていることを裏付ける明確な情報は確認できませんでした。

ただし、次の理由から放置は推奨できません。

技術情報が公開されている
原因がOSコマンドインジェクションである
認証を必要としない
成功時の機密性・完全性・可用性への影響が大きい
修正パッケージが既に提供されている

「悪用情報がない」ことは、「攻撃できない」ことを意味しません。

まとめ

CVE-2026-4408は、Sambaのcheck password scriptにクライアント制御可能なユーザー名を展開する%uが含まれていた場合に、OSコマンドインジェクションが発生する脆弱性です。

ただし、成立には次の条件が必要です。

SambaファイルサーバーまたはClassic DC
        ＋
check password scriptを使用
        ＋
%uを使用
        ＋
rpc start on demand helpers = no
        ＋
samba-dcerpcdを独立常駐
        ＋
攻撃者からDCE/RPCへ到達可能

対応は次の順番で行います。

Sambaパッケージの有無を確認する
有効なcheck password scriptを確認する
%uが含まれていないか確認する
rpc start on demand helpersを確認する
samba-dcerpcdの独立起動を確認する
ベンダーの修正パッケージへ更新する
%uを削除する
必要がなければオンデマンド起動へ戻す
外部からのRPC・SMB通信を制限する
EDRとIPSで異常なプロセス起動を補助監視する

kurutann.comについては、Samba関連パッケージと対象プロセスが存在しないことが確認できているため、CVE-2026-4408の成立条件を満たしておらず、直接的な影響はありません。

FAQ

Q1. Sambaクライアントライブラリだけ入っている場合も危険ですか？

クライアントライブラリが存在するだけでは、本件のサーバー側攻撃経路は成立しません。

smbdやsamba-dcerpcdがサーバーとして動作しているか確認してください。

Q2. Samba AD DCは影響を受けますか？

Samba公式は、Active Directory Domain Controllerでは%uを同じ方法で展開しないため、本脆弱性の対象外と説明しています。

ただし、同じホストで別のファイルサーバー構成を動かしている場合は、その設定を確認してください。

Q3. check password scriptを使用していなければアップデート不要ですか？

本脆弱性の緊急度は下がりますが、Sambaのセキュリティリリースには複数のCVE修正が含まれています。

本件の成立条件を満たさなくても、通常の保守計画に従ってアップデートしてください。

Q4. `%u`を入力チェックすれば使い続けられますか？

推奨されません。

Samba公式の回避策どおり、%uを設定から削除し、SAMBA_CPS_ACCOUNT_NAME環境変数を使用してください。

Q5. ファイアウォールで防げますか？

信頼できないネットワークから関連ポートへ到達できないようにすれば、遠隔悪用の可能性を大幅に下げられます。

ただし、内部ネットワークからの攻撃や設定ミスに備え、アップデートと設定修正を併せて行ってください。

Q6. 脆弱性スキャナーで検出されましたが、設定は安全です

バージョン番号だけを見て検出するスキャナーでは、実際の成立条件を確認せず警告する場合があります。

次の証跡を添えて評価してください。

testparmの出力
samba-dcerpcdの起動状態
rpm -qまたはdpkg-queryの結果
ベンダーアドバイザリ
ファイアウォール設定
待受ポート一覧

参考情報

Samba Security Announcement：CVE-2026-4408
NVD：CVE-2026-4408
Samba公式ドキュメント：smb.conf
Samba公式ドキュメント：testparm
Oracle Linux：CVE-2026-4408
Oracle Linux：ELSA-2026-22963
Red Hat：CVE-2026-4408

出典・最終確認（2026年7月31日）

CVE-2026-4408のNVD記録

影響製品、深刻度、修正版は更新される可能性があります。導入環境のSambaバージョンとベンダー配布情報を確認し、NVDの参照情報と照合してください。

NVD CVE-2026-4408