XBOW、Exim の未認証 RCE 脆弱性 CVE-2026-45185 を発見
Dead.Letter (CVE-2026-45185) – How XBOW found an unauthenticated RCE on Exim

私はセキュリティ分野で 20 年間、そのうち 10 年は専門的にエクスプロイトを開発してきましたが、今回は初めて AI を活用して Exim の深刻な脆弱性 CVE-2026-45185 を発見しました。この脆弱性は GnuTLS との相互作用により生じる Use-After-Free で、たった 1 バイトの書き込みで遠隔コード実行が可能になるという驚くべきものです。
私はこれまでエクスプロイト作成には AI を使わずにきましたが、初めてその警戒を解き、これまで自分の手だけが入っていた場所にこれらのモデルを招き入れることにしました。
HNでの議論
45- nhattruongadm
脆弱性の発見方法自体が、バグそのものと同様に興味深い。XBOW は AI ベースの攻撃セキュリティツールであり、ライブラリ統合ポイントにおける UAF バグは、まさに人間のコードレビューをすり抜けるようなものだ。レビュアーはプロトコルのロジックに注目するが、エラーパスで TLS セッションが中断中にオブジェクトのライフタイムに何が起こるのかには目を向けない。
ここで注目すべきパターンがある。複雑な C ソフトウェアにおける最もリスクの高い攻撃対象領域は、多くの場合コアロジックではなく、統合境界にある。つまり、あるコンポーネント(Exim)が別のコンポーネント(GnuTLS)が管理するオブジェクトのライフサイクルについて仮定を置く場所だ。これらの境界領域では、両方のコードベースに対する深い理解を同時に必要とするため、人間にとっては認知コストが高くつくが、自動化された解析には適している。
これが、「よく監査された TLS ライブラリを使えば安心」という考えが完全に安全性を担保しない理由でもある。ライブラリが提供する正しさの保証を継承できるのは、ライブラリ作成者がテストしたパスに対してのみであり、あなたが負荷下やエラー条件下でそれをどのように呼び出すかについては保証されない。
- kro
「本日、調整されたディストリビューションリリースが行われる」とのことだが、私は本日早い段階で通知を受け取ったものの、そこに CVE 番号は含まれていなかった。これは混乱を招くし、1 日に 2 つの別々のセキュリティ更新通知をリリースするのは、あまり調整がうまくいっていないように思える。
https://lists.debian.org/debian-security-announce/2026/msg00...
- ofjcihen
>What follows is, before anything else, a story. One of those old, well-worn ones.
くそっ。