広く使用されているExim メール転送エージェントの新たに開示された脆弱性は、数千のインターネット公開メールサーバーを認証なしのリモートコード実行に晒し、LinuxおよびUnix系システム全体のコア電子メールインフラストラクチャを脅かしています。
CVE-2026-45185として追跡され、「Dead.Letter」というニックネームが付けられたこのバグは、GnuTLSライブラリでコンパイルされたときのEximによるTLS暗号化SMTP トラフィックとBDAT チャンク分割メッセージボディの処理に存在しています。
Exim メーラー脆弱性
Exim は、ISP、エンタープライズ、Linuxディストリビューションによってメールの受信、ルーティング、配信に使用される人気のあるオープンソースメール転送エージェント（MTA）です。
この脆弱性は、GnuTLSでビルドされ、SMTP機能でSTARTTLSとCHUNKING（BDAT）の両方をアドバタイズするように設定されたExim バージョン4.97から4.99.2に影響します。OpenSSLベースのEximビルドは影響を受けません。これにより管理者に1つの重要な緩和パスが与えられます。
CVE-2026-45185は、GnuTLSがTLSセッションを処理するときのEximのBDAT メッセージボディ解析ロジックにおけるリモートで悪用可能なuse-after-free（UAF）脆弱性です。
認証されていない攻撃者は、同じ接続上でTLSシャットダウンとBDAT チャンク処理を混在させるように設計されたSMTP コマンドのシーケンスを送信することにより、メモリ破損を引き起こすことができます。最終的には任意のコード実行につながります。
この脆弱性は、EximがTLS I/Oを汎用入力層にどのように接続し、BDAТがその入力を独自の受信関数でどのようにラップするかにかかっています。クライアントがSTARTTLSを発行すると、Eximは GnuTLSセッションを作成し、4 KBの転送バッファ（xferbufferと呼ばれることが多い）を割り当て、TLS対応の読み込み関数（tls_getc、tls_ungetc など）をSMTP解析パイプラインに接続します。
その後のすべてのSMTP バイト（メッセージボディを含む）は、TLSセッションがアクティブな間、このバッファを流れます。
BDAT（RFC 3030 CHUNKINGから）は2番目のレイヤーを導入します。BDATチャンクが開始すると、Eximは現在の受信コールバックを「下位」行（lwr_receive_*）にプッシュダウンし、トップ行をBDAT固有のラッパー（bdat_getc、bdat_ungetc）に置き換えます。
これらのBDAT ラッパーは自身でI/Oを実行しません。保存された下位レイヤーに委任し、TLS中は、同じ転送バッファで支えられたTLS受信パスのままです。
コアバグは、クライアントがBDAT ボディの途中でTLSのclose_notify メッセージを送信するときに発生します。TLSシャットダウン中に、Eximは GnuTLSセッションをティアダウンの一部として転送バッファを解放しますが、BDAт受信スタックを完全にアンワインドに失敗します。
トップレベルのコールバックはプレーンテキスト（smtp_getc）にリセットされますが、BDAT層は、lwr_receive_ungetc経由で解放されたTLSバッファへの陳腐なポインタをまだ保持しており、これはtls_ungetc をポイントしています。
その後、BDAт解析を完了している間、Eximは、CRLFシーケンスの欠落を修復する特殊なケースでbdat_ungetc を使用してバイトを「プッシュバック」しようとします。BDAT は下位レイヤーのungetc を呼び出すため、これはtls_ungetc を解放されたバッファで呼び出すことになり、すでにアロケーターに返されたヒープメモリへの単一バイト書き込みを実行します。
その単一のニューラインバイトは、Eximの内部アロケーターメタデータ（その「ストア」プールヘッダー）にランドし、攻撃者がプール長フィールドを破損させ、その後のヒープ動作を制御された方法で形成することを可能にします。
1バイトからリモートコード実行へ
プリミティブは「単なる」解放されたメモリへの1バイト書き込みですが、周囲のアロケーター設計がそれを強力にします。Eximは、mallocの上に構築されたカスタムプールアロケーター（「ストア」）を使用します。各プールはstoreblock チャンクのリストであり、next や length などのヘッダーフィールドが将来の割り当てを誘導します。
解放された領域を制御された割り当てで慎重に再利用することにより（たとえば、特定のプール内でstoremalloc を使用するDKIM検証パスを経由）、攻撃者はアロケーターメタデータを解放されたバッファの内部に配置できます。
storeblock ヘッダーの length フィールドの単一バイトを反転させることにより、攻撃者は、アロケーターの利用可能な空間のビューを「膨張」させることができます。これにより、Exim は、プールが基礎となるmallocチャンクの実際の終端をはるかに超えて広がると信じるようになります。
その後、攻撃者によって制御されるSMTP コマンド（長いMAIL FROM やRCPT TO の引数など）は、Exim がプールメモリだと考えている場所に文字列を書き込ませますが、実際には他の機密構造と重複します。
XBOWのレポートは、このプリミティブを複数の方法で使用できることを示しています：
- ASLRなし、非PIE バイナリの CTF風セットアップでは、LLM ガイド付きエクスプロイトは解放されたチャンク内のglibc largebin ポインタを破損させ、将来のmalloc(4096)をハイジャックし、FILE 構造と重複させ、FSOP経由でROP チェーンに進み、任意のコードを実行しました。
- ASLR が有効になっているより現実的なビルドに対しては、人間が作成したエクスプロイトは代わりにExim 自身のストアアロケーターをターゲットにし、グローバルACLフックの関数ポインタを上書きしたため、Exim が事前DATA ACL ロジックを実行するとき、効果的に攻撃者が提供したシェルコマンドを実行しました。
どちらの場合も、悪用は完全に認証なしです。脆弱性のあるGnuTLS/BDAT 組み合わせが存在することを超えて、特別なExim 設定は必要ありません。
公開アドバイザリーは、成功した悪用により、メールサーバーの完全な侵害が発生する可能性があり、メール を読み取ったり改ざんしたり、横方向に移動したり、追加のマルウェアを配備したりできることを警告しています。
CVE-2026-45185の異常な側面は、発見者が公開窓を使用して、人間のエクスプロイト開発を自律型大規模言語モデルと比較することです。
XBOWは、完全に自動化されたLLM が制御された環境で動作するエクスプロイトチェーンを生成し、よく知られているglibc ヒープエクスプロイテーション パターンとFSOP プリミティブに大きく依存しており、それに対して、人間ガイド付きの作業はより標的固有のアロケーター攻撃とそれを生成しました。本番のようなビルドに対してより清潔なヒープレイアウト。
この実験は、LLM が完全な現実の悪用を最後から最後まで完全に実行することに苦労したとしても、すでに脆弱性トリアージ、ヒープ形状推論、および概念実証生成を加速させることができることを強調しています。
これにより、バグの発見から武器化まで、そして技術詳細が公開されたときに防御側がすぐにパッチを適用する緊急性が短縮されます。
この脆弱性は、GnuTLSに対してビルドされ、サーバーがSTARTTLSとCHUNKING 機能の両方をアドバタイズするとき、Exim バージョン4.97から4.99.2に影響します。
GnuTLS をデフォルトのTLSバックエンドとして出荷するDebianおよび他のディストリビューションは、特に、TLSを有効にし、大規模なチャンク分割メッセージを処理するインターネット公開MX ホストで、特に露出しています。
Exim 4.99.3 には、TLSのclose_notify がBDAT の途中に到着するときに入力スタックを正しくリセットし、陳腐なTLSコールバックが解放されたメモリへの書き込みをトリガーするのを防ぐ修正が含まれています。
セキュリティトラッカーとベンダーは、4.99.3以降へのアップグレードを主要な緩和策として推奨しています。緊急のアップグレードが不可能な場合、管理者は以下を実施することでリスクを軽減できます：
- EximビルドをGnuTLS からOpenSSL に切り替えます。OpenSSL はこの特定のバグの影響を受けません。
- 一時的にBDAT /CHUNKING サポートを無効化し、クライアントを従来のDATA セマンティクスに強制的に戻します。
- STARTTLS の公開を制限するか、特に信頼されていないネットワークからのSMTP ポートへの厳密なアクセス制御を適用します。
詳細な技術的レポートの入手可能性と人間およびLLM 支援エクスプロイトチェーンの実証可能性を考慮すると、GnuTLS でExim を実行している組織はCVE-2026-45185 を高優先度のリモートコード実行リスクとして扱うべきであり、脆弱なメールゲートウェイへのパッチまたは再構成に迅速に移動する必要があります。
翻訳元: https://gbhackers.com/critical-exim-mailer-flaw/
