Samba 4.23.8/4.24.3/4.22.10公開｜未認証RCE含む6件の脆弱性と優先度の考え方

3系統同時リリースが意味すること

2026年7月、Sambaプロジェクトは4.24.3・4.23.8・4.22.10の3バージョンを同日に公開しました。Sambaがサポート系統をまたいで同時リリースを行う場合、多くのケースで「深刻度Critical相当の脆弱性を少なくとも1件含む」というシグナルです。今回もその例に漏れず、未認証のリモートコード実行（RCE）が1件含まれており、ほかに5件の脆弱性が合わせて修正されています。

Sambaは多くの企業・研究機関のLinux環境でWindowsとのファイル共有・Active Directory（AD）ドメインコントローラ役として動いており、インターネット非公開の内部ネットワークにあっても被害影響は大きくなりえます。まず系統別のサポート状況を確認しておきます。

• 4.24系：現行最新安定版。新機能の取り込み対象。
• 4.23系：一世代前の安定版。多くのディストリビューションが採用中。
• 4.22系：セキュリティ修正のみ継続。新機能バックポートなし。

4.21以前はすでにサポート終了（EOL）です。もし本番環境で4.21以下を動かしている場合、今回の修正は提供されません。バージョン確認は smbd --version で即座にできるため、まず現状把握から始めることを推奨します。

公開された6件の脆弱性の概要と深刻度

未認証RCE：最も優先すべき1件

最も深刻な脆弱性は、SMBプロトコル処理内のメモリ破壊に起因する未認証のRCEです。認証フェーズが完了する前にトリガーできるため、有効なアカウントを持たない攻撃者からも悪用が可能であり、CVSSスコアはCritical（9.0以上）に分類されています。公式アドバイザリによれば、Samba をファイルサーバまたはADドメインコントローラとして動作させているすべての構成が対象範囲に入ります。

現時点でPoC（概念実証コード）の公開は確認されていませんが、SMBの仕様は公開されており解析のハードルは低いとされます。「内部ネットワークだから大丈夫」という判断は危険で、ラテラルムーブメント（横展開）の踏み台として内部サーバが狙われる事例は増加傾向にあります。

その他5件の分類と実務上の重みづけ

残る5件はHigh〜Mediumに分類されており、それぞれ以下のカテゴリに属します。

• 認証済みRCE（High）：有効なSamba/ADアカウントがあれば悪用可能。内部不正や侵害済みアカウントを起点とした攻撃を想定。
• 権限昇格（High）：winbindデーモンの処理に起因。ドメイン参加しているLinuxホストが対象で、一般ユーザからroot相当への昇格が可能とされる。
• Kerberos/LDAP認証バイパス（High）：ADドメインコントローラ構成のみに影響。特定の認証フローで資格情報検証がスキップされるケース。
• 情報漏洩（Medium）：匿名でアクセス可能な共有に設定上の意図以上の属性情報が返却される。単体では限定的だが、偵察フェーズで悪用されやすい。
• サービス拒否（Medium）：細工したSMBパケットによってsmbd/nmbdがクラッシュする。可用性への影響のみで、コード実行には至らない。

ADドメインコントローラとして運用しているホストは上記すべてが潜在的に対象になるため、ファイルサーバ専用機よりも優先度が上がります。

パッチ適用の優先度の考え方

脆弱性の深刻度だけでなく、自環境の構成と露出面を組み合わせて優先度を決めることが実務上の原則です。以下の観点で整理するとよいでしょう。

• インターネット直接露出の有無：445番ポートがグローバルIPから直接到達できる場合は即時対応。ファイアウォールで内部のみに制限されていても72時間以内を目安とする。
• ADドメインコントローラかどうか：DC構成はKerberos/LDAP脆弱性の影響を受けるため、ファイルサーバ専用よりも優先する。
• winbindの有効/無効：権限昇格はwinbindが動作しているホストが対象。systemctl is-active winbind で確認できる。
• SMB匿名共有の有無：情報漏洩はguest ok = yesの共有があると実害が出やすい。パッチ前にsmb.confを見直すことも有効。

未認証RCEは構成に関わらず全ホストで最優先です。その他の5件は上記チェックで自環境への該当有無を判断し、計画的に対応する運用が現実的です。

アップデート手順と検証

ディストリビューション経由でSambaを管理している場合は、ディストリビューションのセキュリティアドバイザリを確認してからパッケージ更新を行うのが基本です。ソースビルドで管理している環境は公式サイトからtarballを取得して再ビルドします。

パッケージ管理ディストリビューションでの手順（RHEL/Debian系共通概要）

# 現在のバージョンを記録しておく（切り戻し用）
smbd --version

# RHEL/AlmaLinux/Rocky系
sudo dnf update samba samba-common samba-client

# Debian/Ubuntu系
sudo apt update && sudo apt install --only-upgrade samba

# 更新後のバージョン確認
smbd --version

パッケージ更新後、サービスの再起動が必要です。systemdを使用している環境では以下のように行います。

sudo systemctl restart smbd nmbd
# winbindを使用している場合
sudo systemctl restart winbind

# 起動状態の確認
systemctl status smbd nmbd

ADドメインコントローラ構成（samba-adとして動作）の場合はサービス名が異なります。

sudo systemctl restart samba-ad-dc
systemctl status samba-ad-dc

再起動後の動作確認ポイント

アップデート後は最低限以下を確認します。単にプロセスが起動しているだけでなく、実際の共有アクセスとKerberos認証が正常に機能しているかを確かめることが重要です。

• smbclient -L localhost -U% で匿名リストが返るか（返らない設定であればエラーが正常）。
• smbclient //localhost/共有名 -U ユーザ名 で実際のログインと読み書きを確認。
• ADドメインコントローラ構成の場合は samba-tool domain info 127.0.0.1 でドメイン情報が取得できるか確認。
• WindowsクライアントからのSMBマウント・ドメインログオンが正常に機能するかをテストユーザで確認。

切り戻しと注意点

Sambaのアップデートは、特にメジャーバイナリプロトコルの変更を含まない同系統内のセキュリティリリースであれば、通常は切り戻しが比較的容易です。ただし以下の点に注意が必要です。

パッケージ管理環境での切り戻しは、ディストリビューションのダウングレード機能を使います。dnf系であれば dnf downgrade samba、apt系であれば特定バージョン指定でのインストール（apt install samba=旧バージョン）が基本手順です。ただし、旧バージョンがリポジトリに残っているかどうかはディストリビューションとリポジトリ設定によります。本番適用前にステージング環境でアップデートを検証しておくことで、切り戻しの必要性そのものを下げられます。

TDBファイル（Sambaの内部データベース）は通常アップデートの前後で互換性が保たれますが、4.xのメジャーバージョンをまたぐアップグレードを行う場合は事前にバックアップを取得しておくことを推奨します。

# TDB/設定ファイルのバックアップ（アップデート前）
sudo tar czf /root/samba-backup-$(date +%Y%m%d).tar.gz \
  /etc/samba/smb.conf \
  /var/lib/samba/

smb.confはアップデートで上書きされることは基本ありませんが、パッケージ管理によっては設定ファイルの差分確認ダイアログが出ることがあります。自動化スクリプトで運用している環境では、debconf設定や %config(noreplace)の挙動を事前に把握しておく必要があります。

2026年現行環境での差分ポイント

Samba 4.x系の運用は2026年時点でいくつかの重要な環境変化があります。以前の手法との差分として把握しておくべき点を整理します。

NTLMの段階的廃止と影響：Windows 11 24H2以降ではNTLMv1が既定で無効化されており、SambaでNTLMv1を許容する設定を残している環境はすでに接続断が発生しているはずです。今回のKerberos/LDAP脆弱性修正はこの文脈でも重要で、NTLM代替としてKerberosを適切に設定していない環境は修正の恩恵を受けにくいだけでなく、設定の見直しも必要です。

SELinux/AppArmorとの組み合わせ：近年のRHEL9系・Ubuntu 24.04 LTSはSELinux・AppArmorのデフォルト有効化が進んでおり、Sambaのアップデートに伴いバイナリパスが変わる場合にポリシー違反でサービスが起動しないケースが報告されています。更新後にサービスが起動しない場合は ausearch -c smbd（SELinux）や journalctl -xe でポリシー拒否ログを確認します。

コンテナ・仮想化環境での注意：DockerやPodmanでSambaをコンテナとして動かしている場合、ベースイメージのタグを固定している構成では自動でパッチが当たりません。コンテナイメージのリビルドとレジストリへのプッシュを含めたパッチ適用フローを別途定義しておく必要があります。野良イメージではなく公式またはディストリビューションが提供するベースイメージを使用していれば、イメージの再プルで対応できます。

クラウドマーケットプレイスのAMI/イメージ：AWSやAzureのマーケットプレイスで提供されているイメージにSambaが含まれている場合、プロバイダ側のイメージ更新を待つよりもOSパッケージマネージャで個別に更新するほうが迅速です。インスタンスのOSバージョンとSambaパッケージバージョンを資産管理に含めていない場合は、この機会に棚卸しすることを推奨します。

Sambaのセキュリティリリースは年に数回のペースで行われており、今回のような未認証RCEを含む大規模修正は頻度こそ低いものの、対応体制が整っていない環境ほど被害が拡大しやすいという実態があります。定期的なバージョン確認とアップデート手順のドキュメント化を、日常運用のサイクルに組み込んでおくことが長期的なリスク低減につながります。