Chuỗi lỗ hổng libheif và SSO: Cách các nhà nghiên cứu chiếm tài khoản ChatGPT của nhân viên OpenAI

Một báo cáo mới từ nhóm nghiên cứu bảo mật Hacktron đang gây chú ý trong cộng đồng an ninh mạng, khi họ công bố chi tiết cách kết hợp hai lỗ hổng nghiêm trọng để xâm nhập vào hệ thống của OpenAI. Câu chuyện này không chỉ là một vụ tấn công đơn lẻ, mà còn cho thấy bức tranh đáng lo ngại về cách AI đang thay đổi cán cân trong lĩnh vực an toàn thông tin.

Minh họa chuỗi tấn công qua thư viện xử lý ảnh

Chuỗi tấn công bắt đầu từ một thư viện xử lý ảnh

Vào ngày 25 tháng 7 năm 2026, đội ngũ Hacktron đã khai thác thành công lỗ hổng tràn bộ đệm heap (heap buffer overflow) trong thư viện libheif – thư viện mã nguồn mở chuyên xử lý định dạng ảnh HEIC/HEIF. Lỗ hổng nằm ở phiên bản 1.19.7 mà Discourse sử dụng trong Docker image dựa trên Debian 12.

Điểm đáng chú ý là bản vá bảo mật liên quan đã được sửa ở upstream từ năm trước, nhưng không được gắn nhãn CVE và không được backport kịp thời vào Debian. Ngay cả Debian 13 tại thời điểm đó vẫn phân phối phiên bản dễ bị tổn thương 1.19.8. Phải đến ngày 8 tháng 8 năm 2026, Debian mới phát hành bản cập nhật bảo mật cho vấn đề này.

Khi người dùng tải lên tệp HEIC/HEIF, Discourse không dùng FastImage (vốn không hỗ trợ định dạng này) mà chuyển tiếp cho ImageMagick để chuyển đổi. Điều này vô tình đưa thẳng parser libheif ra trước các tệp do kẻ tấn công kiểm soát, mở đường cho việc thực thi mã từ xa.

Từ RCE đến chiếm tài khoản ChatGPT

Sau khi có RCE (thực thi mã từ xa) trên diễn đàn community.openai.com, nhóm nghiên cứu phát hiện ra rằng vấn đề nghiêm trọng hơn nằm ở tầng SSO (đăng nhập một lần). Diễn đàn cho phép "Sign in with OpenAI" thông qua auth.openai.com, và bất kỳ dịch vụ nào dùng chung cơ chế SSO này đều có thể trở thành bàn đạp để truy cập vào ChatGPT và Codex.

Nhóm Hacktron nhấn mạnh: lỗ hổng leo thang quyền không phải là vấn đề riêng của Discourse, mà là lỗi cấu hình SSO phía OpenAI. Nếu bất kỳ dịch vụ first-party hoặc third-party nào dùng SSO của OpenAI bị xâm phạm, hậu quả sẽ tương tự.

Để chứng minh mức độ ảnh hưởng mà không xâm phạm dữ liệu nhạy cảm, nhóm đã dùng tài khoản Codex của một nhân viên OpenAI (có kết nối với tổ chức GitHub nội bộ) để mở một pull request vô hại trong monorepo nội bộ. Sau đó, họ dừng toàn bộ hoạt động kiểm thử.

Minh họa quy trình khai thác và phản hồi từ các bên

Dòng thời gian phản hồi và tiền thưởng

Toàn bộ quá trình từ phát hiện ban đầu đến khi có quyền truy cập vào repo nội bộ của OpenAI diễn ra chưa đầy 72 giờ. Cụ thể:

• 05:00–06:00 UTC ngày 25/7: Hacktron có RCE và quyền quản trị Discourse tại community.openai.com
• 08:00–10:00 UTC: Gửi báo cáo qua nền tảng Bugcrowd
• 13:30–15:30 UTC: Tạo pull request chứng minh tác động, thông báo trực tiếp cho OpenAI qua Twitter/X
• 22:49 UTC: OpenAI xác nhận đã vá xong, khoảng 14 giờ sau báo cáo
• 26–28/7: Discourse phản hồi, ra bản vá và bổ sung sandbox cho ImageMagick
• 01/9/2026: OpenAI trao thưởng 6.500 USD và đánh dấu đã xử lý xong

OpenAI sau đó làm rõ: việc kiểm thử nhắm vào community.openai.com nằm ngoài phạm vi chương trình bug bounty của họ, và khoản tiền thưởng công nhận phát hiện phía OpenAI chứ không phải các hành động nhắm vào Discourse.

Khi AI rút ngắn khoảng cách giữa lỗ hổng và khai thác

Điểm gây suy ngẫm nhất trong báo cáo là vai trò của AI trong toàn bộ quá trình. Nhóm nghiên cứu cho biết họ dùng Claude để phân tích gói libheif, phát triển exploit và thích ứng với từng môi trường mục tiêu.

Một chi tiết đáng chú ý: khi mô hình Opus 4.8 gặp khó khăn với việc tạo exploit hoạt động ổn định khi bật ASLR, phải mất nhiều phiên làm việc. Nhưng ngay sau khi Opus 5 ra mắt, cùng bài toán đó đã được giải quyết chỉ trong vài giờ. Sau đó, bước nhảy từ Opus 5 lên GPT-5.6 Sol lại tiếp tục mở rộng khả năng khai thác khi không biết gì về hệ thống mục tiêu.

Dự án HEIF Heist kéo dài hai tháng, nhắm vào nhiều nền tảng như Slack, Zoom, Meta, GitHub Enterprise và các framework Node.js, chỉ tốn dưới 3.000 USD tiền token và do ba nhà nghiên cứu thực hiện. Việc thích ứng exploit cho mỗi công ty mới thường chỉ mất một đến hai ngày. Đáng lo hơn, theo nhóm nghiên cứu, chỉ Shopify phát hiện được hoạt động bất thường – dù hàng nghìn ảnh đã được gửi đi và bộ xử lý ảnh của họ liên tục gặp sự cố.

Hàm ý cho các tổ chức và lập trình viên

Báo cáo đưa ra cảnh báo rõ ràng: nếu ứng dụng của bạn xử lý ảnh do người dùng kiểm soát và chấp nhận các định dạng .heic/.heif/.avif, khả năng cao bạn cũng nằm trong vùng ảnh hưởng. Lỗ hổng không gắn với một phiên bản cụ thể mà trải rộng trên cả họ phiên bản 1.19.x, 1.20.x, 1.22.x và 1.23.x.

Các khuyến nghị chính:

• Cập nhật upstream: Cài đặt phiên bản libheif và libde265 mới nhất có bản vá bảo mật. Tính đến ngày 14/9/2026, bản phát hành bảo mật mới nhất là v1.23.4.
• Phòng thủ nhiều lớp: Vô hiệu hóa việc giải mã HEIF/AVIF không tin cậy nếu không cần thiết, hoặc cô lập pipeline xử lý ảnh trong sandbox tạm thời được gia cố.
• Tự chủ máy chủ Discourse: Nếu bạn tự vận hành Discourse, hãy chạy git pull và ./launcher rebuild app từ /var/discourse; chỉ cập nhật qua giao diện web có thể không thay thế được image nền.

Phần kết luận của báo cáo đặt ra vấn đề mang tính thời đại: phần mềm từ lâu được bảo vệ nhờ "bảo mật qua sự phức tạp" – mã nguồn có thể công khai, nhưng để biến lỗi thành exploit đáng tin cậy vẫn cần chuyên môn hiếm, thời gian lớn và hiểu biết về môi trường mục tiêu. AI đang xóa bỏ lớp bảo vệ đó bằng cách biến chuyên môn khan hiếm thành sức mạnh tính toán.

Với độc giả Việt Nam đang vận hành các sản phẩm web, đây là lời nhắc nhở thiết thực: các thư viện xử lý ảnh tưởng chừng phụ trợ lại có thể là mắt xích yếu nhất trong chuỗi bảo mật, và các lỗ hổng đã công khai nhưng chưa được backport vẫn là mối đe dọa thực sự. Trong kỷ nguyên AI, giả định về năng lực của kẻ tấn công cần được cập nhật thường xuyên, thay vì dựa vào những mô hình đe dọa đã lỗi thời.