2026 OpenClaw セキュリティ硬化と脆弱性対応実践：CVE-2026-25253 事例、ファイアウォール规则、最小権限デプロイチェックリスト

CVE-2026-25253 事例：なぜ 135,000 インスタンスが露出したのか

2026 年 1 月中旬、OpenClaw セキュリティチームは CVE-2026-25253 を開示しました。Gateway がデフォルト設定（0.0.0.0 リッスン、認証なし）で動作している場合、細工された WebSocket ハンドシェイクによりリモートコード実行が可能になるという内容です。Shodan スキャンによると、当時135,000 以上のインスタンスが認証なしでアクセス可能であり、個人開発者、小規模チーム、トンネリング誤設定の企業環境まで含まれていました。

根本原因はコードのバグではなくデフォルトの緩すぎる設定にあります：

• Gateway のデフォルト bind アドレスは 0.0.0.0。ファイアウォールやリバースプロキシ認証がなければ、管理ポートがインターネット全体に公開されます。
• 初期インストーラは OPENCLAW_GATEWAY_TOKEN や TLS の設定を強制せず、平文チャネルが MITM 攻撃に晒されます。
• 多くのユーザは VPS で openclaw onboard を実行し「デプロイ完了」と判断し、その後の gateway.bind の締め付けや ufw 設定をスキップしました。

この事件を受けて、v2026.2.0 以降はデフォルト bind アドレスが 127.0.0.1 に変更され、インストーラにセキュリティチェックが組み込まれました。しかし既存インスタンスは手動での修正が必要——本記事がそのための実行可能チェックリストです。

3 つの核心セキュリティ原則（必須遵守）

デプロイ形態を問わず、以下の 3 つを同時に満たす必要があります：

1. 公網に直接露出しない：Gateway は loopback (127.0.0.1) またはプライベート IP のみに bind。アクセスは必ずリバースプロキシ (Nginx/Caddy) またはトンネル (Cloudflare Tunnel) を介し、エッジ層で強制認nals。
2. 強制認証：Gateway へのすべてのリクエストは有効な OPENCLAW_GATEWAY_TOKEN を帯びること（≥32 文字、90 日ごとにローテーション）。
3. 最小攻撃面：ホストは必要なポート（SSH 22、HTTPS 443）のみ開放。Gateway 内部ポート（デフォルト 18789）は 0.0.0.0 でリッスンしてはならない。

Docker デプロイセキュリティチェックリスト

Docker / Docker Compose で OpenClaw を運用する場合、以下を監査してください：

変更後、docker exec <container> netstat -tlnp で Gateway が 127.0.0.1:18789（またはリバプロポート）のみリッスンしていることを確認してください。

systemd / VPS (Ubuntu 24.04) 硬化チェックリスト

VPS 上で systemd サービスとして OpenClaw を常駐させる場合、以下のファイアウォールと OS レベル制御を適用してください：

4.1 ファイアウォール规则 (ufw)

1. デフォルトで incoming を拒否し、必要ポートのみ許可：

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp      # SSH
sudo ufw allow 443/tcp     # HTTPS (リバースプロキシ使用時)
sudo ufw allow 80/tcp      # HTTP (任意、HTTPS へリダイレクト)
sudo ufw enable

2. Gateway ポート (18789) が公網に開放されていないことを確認：

sudo ufw status numbered
# 18789/tcp の allow 規則が表示されないはず

4.2 sshd 強化

• パスワード認證を無効化、鍵のみ許可：PasswordAuthentication no
• デフォルトポートを変更 (22 以外) またはファイアウォールで送信元 IP 制限
• fail2ban を導入しブルートフォースを抑制 (推奨)

4.3 ログローテーション

OpenClaw ログはデフォルトで /tmp/openclaw/openclaw-YYYY-MM-DD.log に出力されます。logrotate を設定しディスク不足を防止：

# /etc/logrotate.d/openclaw
/tmp/openclaw/*.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    copytruncate
}

4.4 systemd unit 示例 (セキュリティオプション付き)

[Unit]
Description=OpenClaw Gateway
After=network.target

[Service]
Type=simple
User=node
Group=node
ExecStart=/usr/bin/openclaw gateway start
ExecStop=/usr/bin/openclaw gateway stop
Restart=on-failure
RestartSec=5
# セキュリティ強化
PrivateTmp=yes
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/home/node/.openclaw /var/log/openclaw
Environment="OPENCLAW_GATEWAY_TOKEN=${OPENCLAW_GATEWAY_TOKEN}"
# リソース制限 (任意)
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

npm グローバルインストール時のセキュリティ設定

本機 npm インストール（開発機や手動運用で共通）では、Gateway bind アドレスを必ず締め付けてください：

# Gateway を 127.0.0.1 のみリッスンさせる
openclaw config set gateway.bind 127.0.0.1

# 確認
openclaw config get gateway.bind
# 127.0.0.1 と出力されるべき

外部アクセスが必要な場合は、リバースプロキシ (Nginx/Caddy) と HTTP ベーシック認証または OAuth を併用：

location /openclaw/ {
    proxy_pass http://127.0.0.1:18789/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    # Basic auth (例)
    auth_basic "OpenClaw Admin";
    auth_basic_user_file /etc/nginx/.htpasswd;
    # または OAuth2 プロキシ統合

脆弱性対応プレイブック：5 段階 (検知 → 72 時間監視)

1. 段階 1 — 検知と影響評価：
   • バージョン確認：openclaw --version。もし < 2026.2.0 かつ Gateway がインターネットに露出していたら、直ちに高リスクと判定。
   • 露出スキャン：nmap -p 18789 <your-public-ip> でポートの到達性を確認。
2. 段階 2 — 設定とデータバックアップ：
   • ~/.openclaw/ 全体をアーカイブ：tar -czf openclaw-backup-$(date +%F).tar.gz ~/.openclaw
   • Gateway 状態をエクスポート（ペア、チャネル、トークン含む）：openclaw gateway export > gateway-state.json
3. 段階 3 — アップグレードと硬化：
   • CLI 更新：npm update -g openclaw または docker pull openclaw/openclaw:latest
   • gateway.bind を 127.0.0.1 にリセット；リバースプロキシ使用時は TLS と認証が有効であることを確認。
   • トークンローテーション：openclaw gateway token rotate；すべての CLI インスタンスと CI 環境変数を更新。
4. 段階 4 — 接続性検証：
   • Gateway 再起動：openclaw gateway restart
   • ローカル健全性：openclaw gateway status が "healthy" を示すこと。
   • 外部アクセステスト：別マシンから接続試行（プロキシでブロックされるか 401/403 が返る应当）。
5. 段階 5 — 72 時間監視ウィンドウ：
   • ログを監視：openclaw logs --follow | grep -i error
   • すべてのチャネル（Telegram/Slack 等）が正常に動作し、ペアリング喪失がないことを確認。
   • 72 時間経過後、硬化手順を runbook に記録し、次回トークンローテーション日を計画。

セキュリティベースライン自己チェックリスト (ポート / 認証 / ログ / 更新 / バックアップ)

以下 5 項目を月 1 回以上実行し、OpenClaw が設定ゆらぎやバージョン落后で再露出しないように維持：

技術リファレンス

• CVE-2026-25253 公式アドバイザリ：GHSA-2026-25253（影響バージョン：<2026.2.0、CVSS 9.8 重大）。
• OpenClaw Gateway デフォルトポート：18789（Control UI も同ポート、localhost のみ）。
• v2026.2.0 以降、デフォルト bind アドレスは 127.0.0.1 に変更（localhost と Docker bridge は依然アクセス可能、公網は不可）。
• 公式 Docker イメージタグ：openclaw/openclaw:latest、:2026.3.13、:stable。

なぜ「動けばよい」では本番で足りないか

多くのチームが PoC や一時デプロイの間、「とにかく動かす」姿勢で、ファイアウォール設定、トークンローテーション、ログローテーションを省略します。開発機では 15 分節約できるかもしれませんが、本番環境では 3 つの致命的リスクがあります：

• 攻击面の露出：公網からアクセス可能な Gateway は扉を開けたまま。CVE-2026-25253 は既知の一例に過ぎず、ゼロデイや将来のバグも同じ経路から侵入します。
• コンプライアンス違反：企業監査では全外部サービスが認證と最小権限レビューを経る必要があり、むき出しインスタンスは SOC2 / ISO27001 をパスできません。
• 回復不能な运维ダメージ：バックドアが仕込まれたりデータが改竄されたりした後、事後の硬化では完全にクリーンであることを保証できません。この場合、安全な選択肢は破棄して再構築のみです。

したがって、セキュリティ硬化は事後補丁ではなく第一步です。安定した長期間運用を求める本番 OpenClaw の場合、MACCOME のマネージド offering はすべてのベースラインを初期状態から組み込み（自動トークンローテーション、ファイアウォールホワイトリスト、24/7 侵入監視）——自己ホスティングのわずらわしさなしに利用できます。自ホスティングを選択する場合は、本記事のチェックリストを audit し、結果をチーム运维マニュアルに記録してください。