AISLE、数か月間TLS検証を無効化していたTraefikのバグを発見

新たに発見された脆弱性により、Traefik の実験的な ingress-nginx プロバイダにおいて、オペレーターが設定で有効化していたにもかかわらず、5か月もの間、TLS証明書検証が密かに無効化されていました。 

この欠陥は重要なセキュリティアノテーションの意味を反転させてしまい、Kubernetes 環境全体で下流の HTTPS サービスを中間者攻撃にさらす結果となりました。

この脆弱性により「… HTTPS バックエンドが中間者（adversary-in-the-middle）攻撃にさらされる」ことになったと、AISLE の研究者は述べています。

小さな設定ミスがもたらした大きな影響

Traefik は世界で最も広く利用されているクラウドネイティブな Ingress コントローラの1つであり、GitHub で6万以上のスター、30億回以上のダウンロードを誇ります。 

金融サービス、SaaS プラットフォーム、ヘルスケアシステム、そして AWS、Azure、GCP、オンプレミス環境にまたがるエンタープライズ Kubernetes クラスタのトラフィックをルーティングしています。

Kubernetes におけるアノテーションはスケールしたポリシーとして機能するため、1つのセキュリティ設定の反転が、数千のルートにわたって防御を弱める可能性があります。 

多くのチームは、バックエンド証明書検証を含む NGINX 形式のセキュリティ設定を維持する目的で、Traefik の ingress-nginx プロバイダを導入していました。しかし実際には、検証は警告なしにオフにされていました。

Traefik の TLS 検証バグはどのように発生したか

この脆弱性（CVE-2025-66491）は、NGINX の proxy-ssl-verify アノテーションと Go の InsecureSkipVerify フィールドとの間にある意味的な不整合に起因していました。 

NGINX では、proxy-ssl-verify: “on” と設定するとバックエンド証明書検証が有効になりますが、Go の TLS 実装では、InsecureSkipVerify: true と設定すると検証が無効になります。 

Traefik の ingress-nginx プロバイダはこれらの挙動を誤ってマッピングし、次のようなロジックを使用していました：InsecureSkipVerify: strings.ToLower(ptr.Deref(cfg.ProxySSLVerify, “off”)) == “on”。 

その結果、アノテーションを “on” に設定すると意図せず検証が無効化され、“off” に設定すると検証が有効になるという逆転が起きていました。 

ユニットテストスイートも、この反転した挙動を期待される結果として定義していたため、欠陥は CI を通過しても検出されませんでした。 

この問題は、攻撃者が ARP スプーフィング、侵害されたサイドカー、あるいは誤設定されたネットワークポリシーなどを通じて、Traefik とバックエンドサービスの間のネットワーク経路上に位置できる場合に危険性を増します。 

検証がスキップされると、攻撃者は偽造証明書を提示し、トラフィックを傍受・復号し、認証情報やセッショントークンを盗み、レスポンスを改ざんしたり、サービストラフィックを迂回させたりすることが可能になりますが、暗号化された接続はオペレーターからは正常に見えてしまいます。 

これは特に、マルチテナントクラスタ、ハイブリッド環境、あるいは一貫した mTLS 強制が行われていないアーキテクチャにおいて大きなリスクとなります。 

このバグは Traefik v3.5.0 から v3.6.2 までのバージョンに影響し、v3.6.3 で修正されました。

Traefik TLS 検証バグによるリスクの軽減

この脆弱性に対処するには、修正版の Traefik へのアップグレードに加え、環境全体で TLS ポリシーの適用・検証・監視の方法を強化する必要があります。

• 完全な修正のために Traefik v3.6.3 へアップグレードするか、一時的な対策として proxy-ssl-verify: “off” を設定するかアノテーションを削除し、正しい TLS 検証を維持します。
• Ingress リソースとアノテーションを監査し、反転した設定や安全でない TLS 設定がないか確認するとともに、より厳格な RBAC 制御によって Ingress 設定を変更できる人物を制限します。
• OPA/Gatekeeper や Kyverno のようなアドミッションコントローラまたはポリシーエンジンを使用して、安全な TLS 設定を強制し、安全でないアノテーション値をブロックします。
• mTLS などの強力なサービス間暗号化を強制し、Ingress レベルの TLS 検証のみに依存しないようにします。
• バックエンドトラフィックを監視し、予期しない証明書チェーン、ルーティングの変更、不規則なサービス間通信パターンなどの異常を検知します。
• CI テストおよび構成パイプラインを見直し、意味的な不整合がないか確認するとともに、ドリフト検知を実装して、安全でない TLS 設定が再び現れないようにします。

これらの対策を講じることで、組織はより信頼性の高い TLS 保護を維持し、設定上の問題が見逃される可能性を低減できます。

クラウドネイティブアーキテクチャにおける「見えない」設定ミス

CVE-2025-66491 は、クラウドネイティブシステムにおけるより広範な課題、すなわちセキュリティポリシーを実施するさまざまなコンポーネント間で、設定の意図を正確に伝達することの難しさを浮き彫りにしています。 

根本的なバグはわずか数文字の問題でしたが、広く利用されているインフラに存在し、オペレーターが期待していたものとは異なる挙動を引き起こしていました。 

この種の問題は、NGINX アノテーションのようにあるシステムで定義された設定を、Go の TLS 設定のような別のシステムにマッピングしなければならない、複雑で多層的なアーキテクチャにおいて発生し得ます。 

こうした不整合は、CI テストを通過してしまったり、従来型のスキャンツールでは検出されなかったりするため、より綿密でシステム認識的な分析を行って初めて可視化されることがあります。

環境がより相互接続されていく中で、このような問題は、各レイヤーでの明示的な検証を重視するゼロトラストのようなアプローチの重要性を改めて示しています。