Log4j「Socket Appender」でTLSのホスト名検証が効かない脆弱性(CVE-2025-68161)

セキュリティニュース

投稿日時: 更新日時:

Log4j「Socket Appender」でTLSのホスト名検証が効かない脆弱性(CVE-2025-68161)

Apache Logging Services は、Log4j(Apache Log4j Core)の「Socket Appender」に関する脆弱性 CVE-2025-68161 を公開し、修正版をリリースしました。本件は、ログ転送をTLSで暗号化していても、接続先サーバの証明書がそのホスト名のものかを検証しないという不具合が原因で、条件次第でログが盗聴・すり替えされるおそれがあります。

影響を受けるバージョンと対策バージョン

Apache の案内によれば、影響を受けるのは Apache Log4j Core の 2.0-beta9 から 2.25.2 までで、2.25.3 で修正されています。
また、CVSS 4.x は 6.3(MEDIUM) と位置付けられています。

どう悪用されるのか:暗号化されていても“途中で”拾われる可能性

この問題がそのまま危険につながるのは、攻撃者がいわゆる 中間者攻撃(MitM) を成立させられる場合です。Apache は、成立条件として次の2点を挙げています。

  • 攻撃者が、アプリケーション(ログ送信側)とログ受信サーバの間で 通信を傍受・迂回 できる

  • 攻撃者が、Socket Appender が信頼するトラストストア(未指定ならJava既定のトラストストア)で 信頼されるCAの証明書 を提示できる

この条件を満たされると、ログが「暗号化されている」こと自体は変わらなくても、誰に向けて暗号化しているかの確認が抜けるため、攻撃者が用意した受信先へログが流れたり、ログ転送が別サーバに誘導されたりするリスクが残ります。

ログには障害解析用の情報だけでなく、運用次第でユーザー識別子やリクエスト情報など機微情報が混ざることもあるため、「ログだから大丈夫」とは言い切れません。

対策:まずは2.25.3へ更新、難しい場合は信頼する証明書を絞る

Apache は、根本対策として Log4j Core 2.25.3 へのアップグレードを推奨しています。
すぐに更新できない場合のリスク低減策としては、Socket Appender が使うトラストストアを見直し、通信に必要なCA/証明書に限定した「私的・限定的なトラストルート」に絞り込む方法が示されています。