🕳️

MongoBleed（CVE-2025-14847）

に公開
MongoDB
Security
CVE
tech

1. MongoBleed（CVE-2025-14847）とは

MongoDB Server のネットワーク圧縮（OP_COMPRESSED、特に zlib）処理に起因し、未認証のリモート攻撃者が細工した通信を送ることで、未初期化ヒープメモリが読み出され得る（情報漏えい）脆弱性です。漏えい内容は状況依存ですが、プロセス内に残っていた認証情報・トークン・キー等の断片が混入し得ます。

運用上のポイント：

  • 認証前（pre-auth）に成立し得るため、外部到達の構成だとリスクが高い
  • ネットワーク圧縮が有効だと条件が揃いやすい
  • 恒久対策は修正版へのアップデート。上げられない間は暫定回避＋露出低減＋監視を組み合わせる

2. 影響範囲と「修正版の目安」の読み方（ここが一番大事）

2.1 まず結論

あなたの現行バージョンが属する「系統（X.Y）」の修正版以上に上げればOKです。
この脆弱性の修正は、MongoDBの系統（8.2 / 8.0 / 7.0 …）ごとに提供されています。

2.2 読み方（1行）

現行が X.Y.Z なら、同じ X.Y の修正版以上に上げれば修正済み。

2.3 系統 → 修正が入った最初のバージョン

  • 現行が 8.2.x → 8.2.3 以上
  • 現行が 8.0.x → 8.0.17 以上
  • 現行が 7.0.x → 7.0.28 以上
  • 現行が 6.0.x → 6.0.27 以上
  • 現行が 5.0.x → 5.0.32 以上
  • 現行が 4.4.x → 4.4.30 以上

2.4 具体例（現行との関連が一発で分かる）

  • 現行が 8.0.8 の場合：系統は 8.0
    → 目標は 8.0.17 以上（8.0.17 / 8.0.18 …）
    → 8.2.3 に上げる必要はありません（8.2系へ移行するのは別のアップグレード方針）

補足：さらに古い系統（例：3.6 / 4.0 / 4.2 など）では「その系統内に修正版がない（全バージョン影響）」扱いになるケースがあるため、その場合は **修正版のある系統へ“系統ごと移行”**が必要です。

3. 影響するか確認（読み取りのみ）

次のコマンド群は「バージョン」「構成（standalone/RS/mongos）」「起動方法」「圧縮設定」「露出」「事前認証の異常兆候（ネットワーク＋ログ＋統計）」をまとめて確認します。

set -eu

echo "=== [1] Version (binary) ==="
mongod --version || true

echo "=== [2] Version (running server) ==="
mongosh --quiet --eval 'db.runCommand({buildInfo: 1}).version' || true

echo "=== [3] Topology (standalone / replset / mongos) ==="
mongosh --quiet --eval 'db.hello()' || true

echo "=== [4] systemd status & unit (find config path via -f) ==="
systemctl status mongod --no-pager || true
systemctl cat mongod 2>/dev/null | sed -n '1,220p' || true

echo "=== [5] Compression settings (edit path if your config differs) ==="
# 設定ファイルの実パスは [4] の ExecStart の -f を優先。
for f in /etc/mongod.conf /etc/mongodb.conf; do
  if [ -r "$f" ]; then
    echo "--- file: $f ---"
    grep -nE 'compression|compressors|zlib|networkMessageCompressors' "$f" || true
  fi
done

echo "=== [6] Exposure: listening on 27017 ==="
ss -lntp 2>/dev/null | grep -E ':(27017)\b' || true

echo "=== [7] Pre-auth-ish signals (network): current connections to 27017 ==="
# 出力には送信元IPが出る。共有時はマスクすること。
ss -Htan '( sport = :27017 )' 2>/dev/null | awk '{print $1,$2,$4,$5}' || true

echo "=== [8] Pre-auth-ish signals (logs): last 10 minutes suspicious keywords ==="
# journald利用環境向け。ファイルログ運用の場合は tail + grep に置き換える。
journalctl -u mongod --since "10 min ago" --no-pager 2>/dev/null \
 | grep -iE 'auth|authenticate|scram|sasl|zlib|decompress|compressed|invalid|corrupt|network|socket|exception' \
 || true

echo "=== [9] Pre-auth-ish signals (metrics): connections stats ==="
mongosh --quiet --eval 'db.serverStatus().connections' || true

echo "=== [10] Pre-auth-ish signals (metrics): command line opts (may show compressors) ==="
mongosh --quiet --eval 'db.adminCommand({getCmdLineOpts: 1})' 2>/dev/null | grep -iE 'compress|zlib' || true

4. 対策（優先順）

4.1 恒久対策（最優先）：修正版へアップデート

  • まずは自分の現行系統（例：8.0.x）に対応する修正版（例：8.0.17+）へ上げる
  • 同一メジャー内のパッチ更新は、一般に作業の複雑度は低めだが、standalone構成では再起動停止を伴うことが多い（メンテ枠前提）

4.2 暫定回避：zlib を無効化（パッチまでの時間稼ぎ）

この脆弱性は圧縮経路（特に zlib）に関連するため、修正版へ上げるまでの暫定回避として次を検討します。

  • zlib を compressors から外す（例：snappy,zstd のみ）
  • 圧縮自体を disabled にする

これは通常、設定ファイル変更と再起動が必要です。メンテ枠とロールバック手順を用意して実施してください。

4.3 露出低減（並行で必須）

  • MongoDB を外部到達可能にしない
  • 許可ネットワーク（allowlist）からのみ 27017 に到達可能にする

5. 「異常な事前認証接続」の異常検知（実務の要点）

「事前認証の探索/スキャン」は MongoDB ログだけだと取りこぼすことがあるため、次の二段構えが現実的です。

(A) ネットワーク到達（推奨：ログ文言に依存しない）

  • allowlist 外から 27017 に到達した時点で異常
  • 送信元ユニークIPの急増もシグナル

(B) MongoDBログ/統計（補強）

  • 認証失敗（SCRAM/SASL/Auth failed）の急増
  • decompress/zlib/invalid/corrupt などの例外ログ増加
  • connections.totalCreated の短時間急増（ベースライン必須）

自動化する場合は、5分ごとに

  • allowlist外の27017到達があるか
  • 認証失敗・例外ログが増えているか
  • connections.totalCreated が急増していないか
    をチェックし、しきい値超過で通知（logger/journald→既存監視基盤）とするのが最小構成です。

6. まとめ（最短ルート）

  1. 稼働中のバージョンと構成を確認（buildInfo / hello）
  2. 自分の現行系統に対応する修正版へアップデート計画（最優先）
  3. それまでの暫定として zlib 無効化を検討
  4. 露出を潰す（allowlist/FW/SG/ACL）
  5. 異常検知は「ネットワーク到達＋ログ/統計」で自動化する

免責

本記事は一般的な整理です。環境（レプリカセット/シャーディング/コンテナ/マネージド等）により手順は変わります。変更は必ずメンテ計画・ロールバック手順・バックアップとセットで実施してください。

Discussion