coturn CVE-2026-53450、django-haystack RCE、OpenSSL更新を安全に確認・適用する方法【2026年8月版】

初回公開: 2026年8月25日
最終確認: 2026年8月26日

対象: coturn、Python、Django、django-haystack、OpenSSL、Linuxパッケージ、Dockerイメージ、Docker Compose

冒頭文

2026年8月のセキュリティ監査では、coturn、django-haystack、OpenSSLなどに更新確認が必要な脆弱性が見つかりました。

ただし、パッケージがインストールされているだけで、すべての脆弱性が直ちに悪用可能になるわけではありません。

特に重要なのは、次の3点です。

• 影響バージョンに該当するか
• 攻撃に必要な機能を実際に使っているか
• 実行中バイナリが、修正済みイメージやパッケージへ切り替わっているか

本記事では、脆弱性の成立条件、確認方法、安全な更新手順、動作確認、再発防止まで説明します。

この記事の要点

• coturn 4.12.0以前はCVE-2026-53450の影響を受け、修正版は4.13.0以降です。
• CVE-2026-53450はIPv4-mapped IPv6形式の127.0.0.1によるloopback判定回避です。
• 明示的な127.0.0.0/8拒否はcoturn更新前の暫定対策になります。
• django-haystack 3.4.0未満には、特定条件下で任意コード実行につながる脆弱性があります。
• Python 3.14.7への移行は、現在のPython系列に対するマイクロ更新とは分けて実施します。
• OpenSSLは実行中系列とOSベンダーの修正済みパッケージ番号を照合します。
• Dockerの数値タグも変更可能なため、タグだけでは完全に固定できません。
• WAFはTURNリスナーを直接保護できず、修正版への更新やpeer制限の代わりにはなりません。

結論・対応の優先順位

次の優先度は、ベンダーが定めた深刻度ではなく、運用上の対応順です。

coturnの公式深刻度はHigh、CVSS 3.1は7.4です。django-haystackもHighですが、こちらは攻撃成立時にDjangoプロセス上で任意コードを実行できるため、成立条件を満たす環境では優先度を上げます。

この記事で分かること

• coturn CVE-2026-53450の正確な影響範囲
• django-haystack脆弱性の攻撃成立条件
• OpenSSLの修正版境界と確認方法
• Python 3.14へ急いで移行すべきか
• Dockerイメージを安全に更新する方法
• 更新後に確認すべき正常系と異常系
• WAF、IPS、EDRで補助できる範囲

対象読者・前提環境

本記事は、次のような環境を運用している管理者を対象とします。

• coturnをWebRTCや音声・映像通信に利用している
• DjangoアプリケーションをDocker Composeで運用している
• Python依存をrequirementsファイルやlockファイルで管理している
• Debian、Ubuntu、Oracle Linux、RHEL系OSを利用している
• nginx、PostgreSQL、Redisなどをコンテナで運用している

実際のOSリリース、Python系列、OpenSSL系列、Composeバージョンが提示されていない環境については、脆弱性への該当性を断定できません。最初にバージョンを収集してください。

用語と全体像

TURNとは

TURNは、直接通信できない2台の端末の間に入って、通信を中継するサーバーです。

宅配便に例えると、送信者と受信者が直接荷物を渡せない場合に使う中継所です。

正式には、NATやファイアウォールを越えて通信するためのリレー方式です。

Allocationとは

Allocationは、認証されたTURN利用者に中継用のIPアドレスとポートを割り当てる処理です。

peerとは

peerは、TURNサーバーが中継する相手側の接続先です。

IPv4-mapped IPv6とは

IPv4アドレスをIPv6形式で表したものです。

例えば、IPv4の127.0.0.1は次のように表現できます。

::ffff:127.0.0.1

CVE-2026-53450では、この表現が既定のloopback判定を回避します。

[認証済みTURNクライアント]
              |
              | peer = ::ffff:127.0.0.1
              v
        [coturn <= 4.12.0]
              |
              | 既定のloopback判定を回避
              v
   [coturnから見た127.0.0.1上のサービス]

Dockerの通常のbridgeネットワークでは、127.0.0.1はcoturnコンテナ自身です。network_mode: hostの場合は、ホストのネットワーク名前空間を共有します。影響対象を判断するにはComposeのネットワーク設定が必要です。

何が起きたか

coturn CVE-2026-53450

coturn 4.12.0以前では、::ffff:127.0.0.1を通常のloopbackとして正しく判定できない場合があります。

その結果、認証済みTURNクライアントが、localhost限定で待ち受けている管理サービスなどへTURN経由で到達できる可能性があります。

公式アドバイザリでは、明示的な次の拒否範囲を設定している場合、この回避は成立しないとされています。

denied-peer-ip=127.0.0.0-127.255.255.255

ただし、allowed-peer-ipが同じ範囲に重なる場合は許可が優先されます。設定ファイルだけでなく、SQL、Redisなどに保存された動的ルールも確認します。

django-haystack GHSA-r3hx-x5rh-p9vv

攻撃が成立するには、少なくとも次の条件が関係します。

1. Elasticsearch backendを使用している
2. SearchFieldにindex_fieldnameの別名が設定されている
3. 攻撃者がインデックスへ入るデータを制御できる
4. 悪意ある値を含む検索結果がDjango側で復元される

脆弱な処理では、検索結果の値が安全な型へ変換されず、eval()へ渡る場合があります。成立すると、Djangoアプリケーションの権限で任意コードを実行される可能性があります。

OpenSSLの2026年8月25日更新

2026年8月25日、OpenSSLは複数系列の修正版を公開しました。

主な公開内容には、次のような脆弱性があります。

すべてのDjangoアプリケーションがQUIC、CMS、CMP、DTLSを使うわけではありません。そのため、攻撃成立条件は機能ごとに異なります。

ただし、共有ライブラリとしてOpenSSLを利用する他のプロセスもあるため、Pythonのssl.OPENSSL_VERSIONだけでホスト全体の該当性を判断してはいけません。

PythonとDjango

Django 5.2.17は2026年8月4日に公開されたセキュリティリリースです。5.2.16に存在したHigh 1件、Moderate 2件、Low 1件を修正しています。5.2.17を利用している場合は、その版を維持しながら次の5.2系修正版を追跡します。

Python 3.14.7は2026年8月5日に公開された3.14系列の保守リリースです。一方、Python 3.12.14は2026年8月12日に公開された3.12系列のセキュリティリリースです。

したがって、更新方針は次のように分けます。

• 緊急更新: 現在使用中の対応Python系列を最新マイクロバージョンへ更新する
• 機能系列移行: Python 3.14.7への移行を別PR、別イメージ、別検証工程で行う

Python 3.14への移行では、Djangoだけでなく、Gunicorn、Uvicorn、Pillow、psycopg、暗号ライブラリ、RustやCで実装された拡張モジュールも検証します。

原因

coturn

IPv4-mapped IPv6アドレスを判定する順番に問題がありました。

::ffff:127.0.0.1をIPv4へ正規化してからloopback判定すべきところ、別のIPv6判定分岐へ先に入るため、既定のloopback拒否が適用されませんでした。

django-haystack

Elasticsearchから返されたフィールド名が、Haystack内部で管理している論理名と一致しない場合があります。

その値が安全なフィールド変換処理を通らず、汎用的な復元処理へ流れ、最終的にeval()で評価されることが原因です。

Docker運用上の原因

コンテナ内で直接pip installやapt upgradeを実行しても、Dockerfileや依存定義は変更されません。

コンテナを再作成すると、以前の脆弱な状態へ戻ります。恒久対策は、Dockerfile、requirements、lockファイル、Composeのimage参照を更新して再ビルドまたは再取得することです。

確認方法

1. 実行中バージョンを確認する

目的: 実際に動作しているcoturn、Python、Django、Haystack、OpenSSLを確認する
実行場所: Composeファイルがあるディレクトリ
注意: 以下のwebとcoturnはComposeサービス名です。

docker compose version
docker compose exec -T coturn turnserver --version

docker compose exec -T web python - <<'PY'
import ssl
import sys
from importlib.metadata import PackageNotFoundError, version

print("Python:", sys.version.split()[0])
print("OpenSSL used by Python:", ssl.OPENSSL_VERSION)

for package in ("Django", "django-haystack"):
    try:
        print(f"{package}:", version(package))
    except PackageNotFoundError:
        print(f"{package}: not installed")
PY

2. coturnのネットワークモードを確認する

目的: 127.0.0.1がコンテナ自身かホストかを確認する
実行場所: Composeディレクトリ

CID="$(docker compose ps -q coturn)"

if [ -z "$CID" ]; then
    echo "coturn container not found" >&2
    exit 1
fi

docker inspect \
  --format 'network_mode={{.HostConfig.NetworkMode}} image_ref={{.Config.Image}} image_id={{.Image}}' \
  "$CID"

3. coturnのpeer制限を確認する

目的: loopback許可、明示的拒否、重複する許可ルールを確認する
実行場所: coturnコンテナ
注意: 設定ファイルのパスは環境に合わせて変更してください。

docker compose exec -T coturn sh -ec '
conf=/etc/coturn/turnserver.conf

if [ ! -r "$conf" ]; then
    echo "configuration file is not readable: $conf" >&2
    exit 2
fi

grep -E "^[[:space:]]*(allow-loopback-peers|allowed-peer-ip|denied-peer-ip|no-multicast-peers)([[:space:]]|=|$)" \
  "$conf" || true
'

正常な状態では、少なくとも次を確認します。

• allow-loopback-peersが有効になっていない
• 127.0.0.0-127.255.255.255が拒否されている
• 同じ範囲を許可するallowed-peer-ipがない
• SQLやRedisに重複する許可ルールがない

allow-loopback-peersは、coturn公式ドキュメントでも開発環境だけで使用するよう警告されています。

設定ファイル全体をチケットやチャットへ貼り付けないでください。static-auth-secret、証明書秘密鍵のパス、データベース接続情報が含まれる可能性があります。

4. Haystackの利用経路を確認する

目的: 脆弱なElasticsearch復元経路が存在するか確認する
実行場所: Djangoソースコードのルート

git grep -n -E \
  'HAYSTACK_CONNECTIONS|ElasticsearchSearchEngine|Elasticsearch7SearchEngine|index_fieldname' \
  -- '*.py' || true

実行時設定も確認します。

docker compose exec -T web python manage.py shell -c '
from django.conf import settings

connections = getattr(settings, "HAYSTACK_CONNECTIONS", {})
for alias, config in connections.items():
    print(alias, config.get("ENGINE", "<ENGINE not set>"))
'

5. OSとOpenSSLパッケージを確認する

Debian・Ubuntu系コンテナ

docker compose exec -T web sh -c '
cat /etc/os-release
dpkg-query -W -f="${Package}\t${Version}\n" "openssl" "libssl*" 2>/dev/null || true
'

更新候補の確認は、本番コンテナを直接変更するのではなく、使い捨ての検証コンテナまたはCIで行います。

apt-get update
apt-get -s upgrade

Oracle Linux・RHEL系ホスト

注意: 実更新前にバックアップ、空き容量、稼働中カーネル、コンテナ状態、メンテナンス時間を確認してください。

cat /etc/os-release
rpm -q openssl openssl-libs curl

sudo dnf updateinfo list --security
sudo dnf upgrade --security

if command -v needs-restarting >/dev/null 2>&1; then
    sudo needs-restarting -r
fi

ssl.OPENSSL_VERSION、openssl version、RPMやDEBの版番号は、それぞれ別の情報です。

Linuxディストリビューションはセキュリティ修正を古い上流版へバックポートすることがあります。上流OpenSSLの数字だけで脆弱と断定せず、OSベンダーのadvisoryと修正済みパッケージ番号を照合します。

対処方法

1. 更新前の状態を記録する

docker compose config -q
docker compose ps

CID="$(docker compose ps -q coturn)"
docker inspect \
  --format 'image_ref={{.Config.Image}} image_id={{.Image}} created={{.Created}}' \
  "$CID"

IMAGE_ID="$(docker inspect --format '{{.Image}}' "$CID")"
docker image inspect \
  --format 'id={{.Id}} repo_digests={{json .RepoDigests}}' \
  "$IMAGE_ID"

docker compose config -qは構文確認だけを行います。

docker compose configを引数なしで実行すると、環境変数で展開された値が表示される場合があります。出力をチケットやチャットへ転載しないでください。

2. coturnを更新する

更新版の選び方

CVE-2026-53450の最小修正版は4.13.0です。

2026年8月26日時点では、公式リポジトリに4.17.2と公式Dockerタグ4.17.2-r0などが公開されています。ただし、4.17.2はCVEの「修正境界」ではなく、その後に公開された新しいリリースです。

再現性が必要な環境では、検証したmanifest digestへ固定します。

services:
  coturn:
    # <検証済みのmanifest digest>は実際の値へ置き換える
    image: coturn/coturn:4.17.2-r0@sha256:<検証済みのmanifest digest>

タグは変更可能です。digestを固定した場合は、自動的にセキュリティ修正版へ追従しなくなるため、digest更新PRを定期的に作成します。

peer制限を設定する

# CVE-2026-53450の暫定対策および恒久的な防御
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=::1

# 以下は業務上、プライベートネットワークをpeerとして使わない場合だけ設定
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
denied-peer-ip=192.168.0.0-192.168.255.255

RFC1918拒否を追加する前に、WebRTC、VPN、社内会議システムなどがプライベートアドレスを正規のpeerとして使っていないことを確認してください。

また、次の設定がないことを確認します。

allow-loopback-peers

allowed-peer-ipが拒否範囲に重なっていないことも確認します。

サービスを更新する

docker compose config -q
docker compose pull coturn

docker image inspect \
  coturn/coturn:4.17.2-r0 \
  --format 'candidate_id={{.Id}} repo_digests={{json .RepoDigests}}'

docker compose up -d --no-deps --force-recreate coturn
docker compose exec -T coturn turnserver --version

更新や暫定対策を検証できない場合は、TURNリスナーを停止します。Webサイトのメンテナンス画面だけではTURNリスナーは停止しません。

3. TURN認証秘密値を扱う

共有秘密値は、次の場所へ直接書かないでください。

• コマンドライン引数
• Git管理対象のComposeファイル
• CIログ
• チケット
• チャット
• プロセス一覧を含む診断ログ

CVE-2026-53450の修正だけを理由に、必ず秘密値を変更する必要はありません。

次のいずれかに該当する場合は、漏えいとして扱いローテーションします。

• 秘密値をGitへcommitした
• docker inspectで見える環境変数へ平文保存した
• プロセス引数やログへ出力した
• 不審なTURN認証や異常なAllocationが見つかった
• 第三者へ設定ファイル全体を共有した

4. django-haystackを更新または削除する

依存定義の正本を修正します。

django-haystack>=3.4.0,<4

厳密な再現性が必要な環境では、プロジェクトのlock方式に従って3.4.0以上へ固定します。

仮想環境または使い捨てビルド環境で実行します。

python -m pip install -r requirements.txt
python -m pip_audit -r requirements.txt

python manage.py check
python manage.py migrate --check
python manage.py test

Haystackを使っていない場合は、更新するだけでなく依存から削除する方法もあります。

これは脆弱性の必須対策というより、未使用機能が将来の設定変更で復活することを避ける運用上の判断です。

5. Pythonを更新する

現在3.12系の場合

まず3.12系列の最新セキュリティリリースへ更新します。2026年8月26日時点では3.12.14が公開されています。

FROM python:3.12.14-slim@sha256:<検証済みのmanifest digest>

Python 3.14へ移行する場合

3.14.7への変更は、緊急パッチとは別の互換性移行として扱います。

FROM python:3.14.7-slim@sha256:<検証済みのmanifest digest>

次を確認します。

• 全依存がPython 3.14をサポートする
• wheelが提供される
• C、C++、Rust拡張がビルドできる
• Gunicorn、Uvicorn、Channels、Celeryなどが起動する
• Pillowや暗号関連処理が正常
• マイグレーション生成差分が出ない
• 負荷試験でレイテンシやメモリが悪化しない

Django 5.2は5.2.8以降でPython 3.14をサポートしていますが、サードパーティ依存の互換性は個別確認が必要です。

6. OpenSSLとOSパッケージを更新する

コンテナ内で直接apt upgradeを行うだけでは、再作成時に元へ戻ります。

Dockerfileのベースイメージを更新し、新しいベースを取得してビルドします。

# Composeサービスにbuild:がある場合
docker compose build --pull web

# Composeサービスがimage:だけの場合
docker compose pull web

docker compose up -d --no-deps --force-recreate web

Dockerの--pullは、キャッシュ済みのベースイメージだけを使わず、新しいベースイメージがないか確認します。--no-cacheとは役割が異なります。

OpenSSLの修正済み境界は上流版だけで判断せず、次の組み合わせで確認します。

実行プロセスが使うOpenSSL
        +
コンテナまたはホストのパッケージ版
        +
OSベンダーのsecurity advisory

7. Docker Composeを更新した場合

Docker Compose v5.5.0では、image digest reconciliationが変更されています。

アップグレード後、最初のdocker compose upで既存コンテナが再作成される可能性があります。

更新直後に全サービスをまとめて操作せず、次の順番で進めます。

docker compose version
docker compose config -q
docker compose ps

docker compose pull coturn
docker compose up -d --no-deps --force-recreate coturn

docker compose pull web
docker compose up -d --no-deps --force-recreate web

Compose環境ではコンテナ名を固定文字列として仮定せず、サービス名を使って確認します。docker inspectが必要な場合だけ、docker compose ps -qで実コンテナIDを解決します。

docker compose exec -T coturn turnserver --version

cid="$(docker compose ps -q coturn)"
test -n "$cid"
docker inspect --format '{{.HostConfig.NetworkMode}} {{.Config.Image}} {{.Image}}' "$cid"

確認結果の実際のバージョン番号やイメージIDは環境ごとに記録し、この記事には本番環境の実測値を掲載しません。

PostgreSQL、Redisなどの状態を持つサービスは、アプリコンテナと同じ感覚で強制再作成しないでください。バックアップ、データディレクトリ、互換性、停止時間を個別に確認します。

動作確認

coturn

正常系と異常系の両方を確認します。

loopbackの否定テストは、隔離した検証環境、短命な合成認証情報、テスト専用loopbackサービスで実施します。

公開ホスト上の管理サービスを直接標的にした試験は行いません。

Django

docker compose exec -T web python --version

docker compose exec -T web python -c \
  "import django, ssl; print('Django:', django.get_version()); print('OpenSSL:', ssl.OPENSSL_VERSION)"

docker compose exec -T web python manage.py check --deploy
docker compose exec -T web python manage.py migrate --check

さらに次を確認します。

• ログイン
• 主要URL
• 静的ファイル
• ファイルアップロード
• 検索機能
• WebSocket
• バックグラウンドworker
• 定期処理
• PostgreSQL接続
• Redis接続

check --deployの警告は、ゼロでなければ即失敗という意味ではありません。各警告が意図した構成か確認し、受容理由を記録します。

イメージIDとdigest

for service in coturn web; do
    CID="$(docker compose ps -q "$service")"

    if [ -z "$CID" ]; then
        echo "$service: container not found" >&2
        continue
    fi

    IMAGE_ID="$(docker inspect --format '{{.Image}}' "$CID")"

    docker inspect \
      --format "$service ref={{.Config.Image}} id={{.Image}}" \
      "$CID"

    docker image inspect \
      --format "$service repo_digests={{json .RepoDigests}}" \
      "$IMAGE_ID"
done

Composeに書かれた参照、実行中コンテナのイメージID、記録したdigestが一致していることを確認します。

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

WAFでWebサイトを保護していても、TURNリスナーは別の通信経路です。

WAFやCloudflareのプロキシ対象になっているWebドメインをメンテナンス表示へ切り替えただけでは、外部公開中のTURNポートは閉じません。

再発防止

1. 最低安全版をCIで検査する

少なくとも次の条件をポリシー化します。

coturn >= 4.13.0
django-haystack >= 3.4.0
Django >= 5.2.17   # 5.2 LTSを使う場合

文字列比較ではなく、パッケージ管理ツールやバージョン比較ライブラリを使います。

2. SBOMとイメージ情報を保存する

リリースごとに次を記録します。

• Git revision
• Python依存のlockファイル
• OSリリース
• イメージID
• RepoDigest
• SBOM
• マイグレーション状態
• 適用したセキュリティアドバイザリ
• 動作確認結果

3. digest更新を自動化する

digest固定は再現性を高めますが、自動的なセキュリティ更新を停止させます。

新しいdigestが公開されたときに、更新PR、イメージスキャン、テスト、段階デプロイを実行する仕組みを用意します。Dockerも、digest固定と更新ワークフローの併用を案内しています。

4. TURNの否定テストを定期実行する

リリース前または定期監査で次を確認します。

• 127.0.0.1の拒否
• ::1の拒否
• ::ffff:127.0.0.1の拒否
• 禁止したRFC1918範囲の拒否
• 許可対象peerの正常通信
• 認証なしAllocationの拒否
• 短命認証情報の期限切れ

5. 未使用依存を削除する

「現在は使っていないがrequirementsには残っている」という状態は避けます。

未使用依存は次の問題を生みます。

• 脆弱性アラートが増える
• 将来の設定変更で攻撃経路が復活する
• ビルド時間とイメージ容量が増える
• 依存競合が増える
• 監査対象が広がる

注意点・よくある誤解

誤解1: Webサイトをメンテナンス表示にすればTURNも止まる

止まりません。

WebアプリケーションとTURNリスナーは別の待受です。TURNサービスまたは該当ポートを明示的に停止します。

誤解2: 4.17.2-r0は固定タグなので内容が変わらない

数値タグも変更可能です。

完全な再現性が必要ならdigestを使います。

誤解3: digestを固定すればセキュリティ対策は完了する

digest固定は同じイメージを再利用するための仕組みです。

新しい修正版へ自動的には移りません。更新監視と更新PRが必要です。

誤解4: PythonのOpenSSL版が新しければnginxやcoturnも安全

Pythonのssl.OPENSSL_VERSIONは、Pythonプロセスが利用するOpenSSLを示します。

nginx、coturn、curlなどが別のOpenSSLやlibsslへリンクしている可能性があります。

誤解5: coturnを更新したら共有秘密値も必ず変更する

CVE-2026-53450だけを理由にしたローテーションは必須ではありません。

秘密値の露出、不審な認証、ログへの出力などが確認された場合に変更します。

誤解6: RFC1918をすべて拒否すれば常に安全

プライベートネットワークを正規peerとして使う構成では、必要な通信まで停止します。

業務要件とネットワーク設計を確認してから適用します。

ロールバック

セキュリティ更新のロールバックは、脆弱な旧版を外部公開状態へ戻すことではありません。

新版に機能回帰が見つかった場合は、次の順番で対応します。

1. 対象サービスを停止する
2. 外部公開を閉じる
3. 修正版系列内で設定や依存を調整する
4. 正常系と異常系を再検証する
5. 安全性を確認してから再公開する

アプリケーションコンテナでは、次の情報を一組として管理します。

Git revision
+ image ID
+ image digest
+ Python lock file
+ migration状態
+ 設定revision

コードだけ、イメージだけ、データベースだけを過去へ戻すと、不整合が発生します。

PostgreSQLなどのデータを伴うサービスは、更新前バックアップだけでなく、復元テストも必要です。

まとめ

公開中のcoturnが4.12.0以前であれば、CVE-2026-53450への対応を優先します。

最小修正版は4.13.0です。更新前の暫定対策として、明示的な127.0.0.0/8拒否が利用できます。ただし、重複するallowed-peer-ipやデータベース上の動的ルールまで確認しなければなりません。

django-haystackは3.4.0未満が影響対象です。Elasticsearch backend、フィールド別名、攻撃者制御データ、検索結果復元という条件を確認し、該当しなくても更新または削除します。

Python 3.14.7への移行は、緊急のマイクロ更新とは分けます。現在の対応系列を安全なマイクロバージョンへ更新したうえで、3.14は互換性試験を経て導入します。

OpenSSLは上流版番号だけでは判断できません。各プロセスが利用するライブラリ、OSパッケージ、ベンダーadvisoryを照合します。

Dockerでは、コンテナ内だけを更新しても恒久対策になりません。Dockerfile、依存定義、Composeの参照を更新し、イメージIDとdigestを記録したうえで再作成します。

FAQ

Q1. coturnを直ちに停止する必要がありますか

公開中の4.12.0以前で、明示的な127.0.0.0/8拒否を確認できない場合は、更新または検証が終わるまで停止する判断が安全です。

明示的拒否、重複許可ルールなし、正常系と異常系の試験まで確認できる場合は、暫定運用が可能です。

Q2. coturn 4.13.0へ上げれば十分ですか

CVE-2026-53450の修正版境界は4.13.0です。

ただし、運用では4.13.0以降の検証済みリリースを選び、loopback拒否も多層防御として維持します。

Q3. Python 3.14.7へ必ず上げる必要がありますか

必須とは断定できません。

現在3.12系であれば、3.12.14へのセキュリティ更新という選択肢があります。3.14.7は、依存互換性を確認したうえで別工程として導入します。

Q4. WAFでCVE-2026-53450を防げますか

通常のWAFではTURNリスナーを直接防御できません。

TURN認証情報を発行するHTTP APIの保護には役立ちますが、coturnの更新、peer拒否、ネットワーク分離の代わりにはなりません。

Q5. 秘密値は必ずローテーションしますか

CVEの修正だけなら必須ではありません。

秘密値をプロセス引数、Git、ログ、チケットなどへ出した場合や、不審なTURN利用が見つかった場合はローテーションします。

Q6. pip-auditで問題がなければ安全ですか

Pythonパッケージについて既知の脆弱性を確認する補助手段です。

OSパッケージ、OpenSSL、nginx、coturn、未公開脆弱性、設定不備までは保証しません。