CVE-2026-45185: Cuộc đua khai thác lỗ hổng Exim giữa Con người và AI
XBOW đã phát hiện CVE-2026-45185, một lỗ hổng RCE nghiêm trọng trong Exim, và sử dụng khoảng thời gian công bố để tổ chức một cuộc đua thú vị giữa chuyên gia bảo mật con người và mô hình ngôn ngữ lớn (LLM) trong việc phát triển khai thác.

CVE-2026-45185: Cuộc đua khai thác lỗ hổng Exim giữa Con người và AI
Trong bối cảnh an ninh mạng ngày càng phức tạp, câu chuyện về việc phát hiện và khai thác lỗ hổng thường gắn liền với những đêm thức trắng của các chuyên gia bảo mật. Tuy nhiên, một báo cáo mới từ XBOW đã đưa ra một cái nhìn đầy thú vị và cũng phần nào "đáng sợ" về tương lai của ngành này: cuộc đua giữa con người và Trí tuệ nhân tạo (AI) trong việc khai thác một lỗ hổng nghiêm trọng.
Dead Letter CVE
Lỗ hổng CVE-2026-45185 là một lỗi Use-After-Free (UAF) nghiêm trọng cho phép thực thi mã từ xa (RCE) mà không cần xác thực trên Exim, một phần mềm chuyển thư (MTA) phổ biến được sử dụng trên nhiều máy chủ Linux. Điều đáng nói là XBOW không chỉ dừng lại ở việc tìm ra lỗi, mà họ còn tận dụng khoảng thời gian 7 ngày trước khi công bố rộng rãi để tiến hành một thí nghiệm độc đáo: xem ai sẽ nhanh hơn trong việc xây dựng một đoạn mã khai thác (exploit) hoàn chỉnh—một chuyên gia bảo mật dày dạn kinh nghiệm hay một hệ thống AI tự động.
Chi tiết kỹ thuật về lỗ hổng
Về mặt kỹ thuật, lỗi này nằm trong cách Exim xử lý kết nối TLS thông qua thư viện GnuTLS mặc định. Khi quá trình tắt kết nối TLS (TLS shutdown) diễn ra, Exim giải phóng bộ đệm chuyển TLS (xfer_buffer). Tuy nhiên, một trình bao lệnh nhận lồng nhau (nested BDAT receive wrapper) vẫn có thể đang xử lý các byte dữ liệu đến và cuối cùng gọi hàm ungetc().
Hàm này sẽ ghi một ký tự dòng mới (\n) vào vùng nhớ vừa được giải phóng. Mặc dù chỉ là một ghi một byte duy nhất, nhưng hành động này đủ để làm hỏng metadata của bộ cấp phát bộ nhớ (allocator metadata). Từ đó, kẻ tấn công có thể khai thác sự hỏng hóc này để leo thang đặc quyền và thực thi mã từ xa.
Brendan working
Điều khiến CVE-2026-45185 trở nên nguy hiểm là nó không yêu cầu bất kỳ cấu hình đặc biệt nào trên máy chủ. Chỉ cần Exim sử dụng GnuTLS (mặc định trên nhiều bản phân phối như Debian hay Ubuntu), lỗ hổng này đã hiện hữu.
Thử thách 7 ngày: Con người vs. AI
Sau khi báo cáo lỗ hổng cho đội ngũ Exim và nhận được thời hạn công bố là 7 ngày, nhóm XBOW đã quyết định biến khoảng thời gian này thành một cuộc thi. Một phía là tác giả bài viết—một chuyên gia bảo mật với gần 10 năm kinh nghiệm viết exploit và 20 năm trong ngành an ninh. Phía còn lại là XBOW Native, một sản phẩm AI tự động hóa việc tìm kiếm và phát triển khai thác.
Chiến thuật của Con người
Tác giả con người đã tiếp cận vấn đề với tư duy truyền thống: cố gắng thao túng bộ nhớ heap của Exim để ghi đè metadata của bộ cấp phát tùy chỉnh (custom allocator). Kế hoạch là sử dụng các cấp phát bộ nhớ do DKIM điều khiển để chiếm lại vùng nhớ đã giải phóng, từ đó làm hỏng trường độ dài (length field) của một khối bộ nhớ.
Tuy nhiên, con người đã gặp khó khăn lớn. Exim sử dụng một bộ cấp phát bộ nhớ pool tùy chỉnh rất phức tạp. Hơn nữa, các đối tượng chứng chỉ (certificate objects) được GnuTLS cấp phát trong quá trình thiết lập TLS không bao giờ được giải phóng ngay cả khi kết nối đóng. Điều này khiến xfer_buffer bị "mắc kẹt" giữa các đối tượng còn sống, ngăn chặn việc gộp vùng nhớ (coalescing) của glibc và làm cho việc sắp xếp bộ nhớ (heap grooming) trở nên vô cùng khó khăn.
Chiến thuật của AI
Trong khi đó, XBOW Native đã chọn một cách tiếp cận đơn giản và từng bước một. Họ không yêu cầu AI tạo ra exploit hoàn chỉnh ngay lập tức mà bắt đầu với môi trường dễ nhất: tắt ASLR và PIE.
Brendan thinking
Kết quả là AI đã chiến thắng vòng đầu tiên. Đoạn mã do AI tạo ra đã sử dụng một chuỗi khai thác 4 bước tinh vi:
- Làm hỏng con trỏ largebin của glibc: Bằng cách kích hoạt lỗi UAF và ghi byte, AI đã thay đổi một byte trong con trỏ metadata của glibc.
- Chiếm đoạt malloc(4096): Khi Exim mở file spool, nó gọi malloc cho bộ đệm stdio. Con trỏ bị làm hỏng đã khiến glibc trả về địa chỉ do kẻ tấn công kiểm soát.
- Ghi đè cấu trúc FILE: Sử dụng các hoạt động I/O bình thường của Exim, dữ liệu đã chảy qua bộ đệm bị làm hỏng và ghi đè cấu trúc
FILE, bao cả bảng hàm ảo (vtable). - FSOP và ROP chain: Cuối cùng, AI sử dụng kỹ thuật FSOP (File Stream Oriented Programming) để chuyển hướng luồng thực thi sang một ROP chain, đọc file cờ (flag) từ đĩa và gửi lại qua socket SMTP.
Kết luận và Hệ quả
Cuộc đua này kết thúc với chiến thắng thuộc về AI ở vòng đầu tiên. Đoạn mã của AI sử dụng các kỹ thuật tiêu chuẩn của glibc (largebin attack, FSOP) giống hệt như những gì thường thấy trong các cuộc thi CTF (Capture The Flag).
Đối với tác giả con người, đây là một trải nghiệm đầy ám ảnh. Lần đầu tiên trong sự nghiệp, ông cảm thấy lo lắng về nghề nghiệp của mình khi thấy AI có thể giải quyết vấn đề kỹ thuật phức tạp nhanh hơn và hiệu quả hơn. Mặc dù con người vẫn có lợi thế về sự hiểu biết sâu sắc và ngữ cảnh, nhưng tốc độ và khả năng áp dụng kỹ thuật của AI đã cho thấy một tương lai mà công cụ tự động hóa sẽ đóng vai trò trung tâm trong việc nghiên cứu và khai thác lỗ hổng bảo mật.
Bài viết liên quan

Công nghệ
Cerebras, đối tác thân thiết của OpenAI, sẵn sàng cho đợt IPO kỷ lục định giá tới 26,6 tỷ USD
04 tháng 5, 2026

AI & ML
Nguy cơ bảo mật từ "Vibe-Coding": Hàng nghìn ứng dụng AI để lộ dữ liệu nhạy cảm trên mạng
07 tháng 5, 2026

Phần mềm
Google tung ra Antigravity 2.0: Ứng dụng lập trình thế hệ mới với công cụ CLI và gói đăng ký AI Ultra
19 tháng 5, 2026
