Hacktron phanh phui cách chiếm quyền tài khoản nhân viên OpenAI qua lỗ hổng libheif và SSO

Lỗi tràn bộ nhớ heap và cấu hình sai SSO dẫn đến việc xâm nhập các kho lưu trữ nội bộ của OpenAI

Ngày 13 tháng 9 năm 2026 | 11 phút đọc

Giới thiệu

Vào ngày 25 tháng 7 năm 2026, chúng tôi đã kết hợp hai lỗ hổng nghiêm trọng để xâm nhập vào tài khoản ChatGPT của nhiều nhân viên OpenAI. Với các tài khoản này, chúng tôi có thể truy cập vào các kho lưu trữ nội bộ của OpenAI và có khả năng là nhiều trình kết nối khác.

Để chứng minh rằng chúng tôi thực sự đã giành được quyền truy cập như dự đoán mà không cần xem bất kỳ thông tin nhạy cảm nào, chúng tôi đã sử dụng Codex của nhân viên đó để mở một PR #1186742 trong monorepo nội bộ openai/openai của OpenAI.

Cho đến hai tháng trước, bất kỳ người dùng hoặc nhân viên OpenAI nào đăng nhập vào diễn đàn hỗ trợ của OpenAI (community.openai.com) đều có thể bị chiếm đoạt tài khoản ChatGPT và Codex. Vì mọi người có thể kết nối nhiều dịch vụ khác nhau với Codex và ChatGPT, phạm vi những gì chúng tôi có thể truy cập về mặt lý thuyết là rất lớn, bao gồm GitHub, Slack và email.

Toàn bộ quá trình từ khi phát hiện ban đầu đến khi truy cập được vào kho lưu trữ của OpenAI diễn ra trong chưa đầy 72 giờ.

Chúng tôi đã ngay lập tức báo cáo lỗ hổng ban đầu cho OpenAI và Discourse, đồng thời phối hợp với họ để triển khai bản vá. Chúng tôi đánh giá cao sự chú trọng đến chi tiết và khả năng giải quyết vấn đề nhanh chóng của họ. OpenAI cũng đã trao cho chúng tôi khoản tiền thưởng 6.500 USD.

Chúng tôi cung cấp toàn bộ mốc thời gian của quá trình tiết lộ thông tin tại đây. Phần còn lại của bài viết trình bày chi tiết cách chúng tôi phát hiện hai lỗ hổng, cách chúng tôi sử dụng các mô hình claude, cũng như những bài học rút ra từ trải nghiệm này.

Bối cảnh

Vài tháng trước, nhóm của chúng tôi tại Hacktron, do Harsh Jaiswal dẫn đầu cùng với Mohan Pedhapati và Rahul Maini, đã bắt đầu nghiên cứu các công ty AI tiên phong để tìm kiếm các lỗ hổng bảo mật. Điều này dẫn đến việc chúng tôi phát hiện ra một cấu hình sai SSO trong cơ sở hạ tầng định danh của OpenAI và một lỗ hổng RCE trong libheif trên diễn đàn cộng đồng mà OpenAI sử dụng.

Kể từ đó, chúng tôi đã mở rộng nghiên cứu sang HEIF Heist, một cuộc điều tra kéo dài nhiều tháng nhằm truy vết libheif trên Slack, Meta, GitHub Enterprise, Ruby on Rails và các framework Node.js như Next.js, Astro và Gatsby. Một lượng đáng ngạc nhiên các phần mềm được sử dụng rộng rãi đều phụ thuộc vào thư viện xử lý hình ảnh này.

Nếu ứng dụng của bạn xử lý hình ảnh do người dùng kiểm soát và chấp nhận các định dạng.heic/.heif/.avif, rất có thể ứng dụng đó đã bị ảnh hưởng. Vui lòng liên hệ với chúng tôi tại [email protected] nếu bạn cần bất kỳ sự hỗ trợ nào.

Thông báo về bản vá: Nếu bạn tự lưu trữ Discourse, hãy xây dựng lại bản cài đặt của mình ngay bây giờ. Các Docker image cũ hơn có thể chứa thư viện libheif dễ bị tổn thương, cho phép thực thi mã thông qua việc tải lên hình ảnh. Hãy chạy lệnh git pull theo sau là./launcher rebuild app từ thư mục /var/discourse; việc cập nhật qua giao diện web đơn thuần có thể không thay thế được image nền tảng. Các khách hàng sử dụng dịch vụ lưu trữ của Discourse đã được vá lỗi. Xem thêm tư vấn bảo mật.

OpenAI sử dụng Discourse cho diễn đàn của họ và cho phép "Đăng nhập bằng OpenAI" thông qua auth.openai.com. Sau khi hiểu rõ về các dịch vụ và cơ sở hạ tầng của OpenAI, chúng tôi có lý do để tin rằng việc xâm nhập diễn đàn có thể tạo ra con đường dẫn đến các dịch vụ rộng lớn hơn của OpenAI thông qua luồng định danh này. Để kiểm chứng giả thuyết đó, trước tiên chúng tôi cần thực thi mã từ xa (RCE) trên một dịch vụ của OpenAI như diễn đàn cộng đồng Discourse.

Mặc dù bản thân ứng dụng Discourse không phải là mục tiêu dễ dàng (chúng tôi đã từng xem xét nó trước đây), nhưng chúng tôi nghĩ rằng mình có thể nhắm vào một thư viện phụ thuộc.

Tràn bộ đệm heap trong libheif

Vào ngày 23 tháng 7, chúng tôi bắt đầu xem xét quy trình tải lên hình ảnh của Discourse và phát hiện ra rằng các tệp HEIC và HEIF đi theo một con đường bất thường. Discourse thường sử dụng FastImage để kiểm tra hình ảnh, nhưng vì FastImage không hỗ trợ HEIF, nó đã chuyển các tệp đó sang lệnh magick của ImageMagick để chuyển đổi. Điều này làm lộ trình phân tích libheif cơ bản trực tiếp với các tệp do kẻ tấn công kiểm soát.

Chúng tôi bắt đầu một phiên làm việc với Opus 4.8 trên Docker image của Discourse và yêu cầu nó kiểm tra gói libheif đã cài đặt để tìm các vấn đề bảo mật. Sau một thời gian, nó phát hiện ra rằng một số bản sửa lỗi bảo mật cụ thể đã không được back-port (chuyển ngược) vào gói libheif. Điều này cho phép xảy ra lỗi tràn bộ đệm heap, dẫn đến các nguyên hàm R/W (đọc/ghi) ngoài phạm vi (OOB) trong quá trình giải mã HEIC.

Điều thú vị là mã dễ bị tổn thương đã được thay đổi ở phía upstream từ năm trước, nhưng commit đó không được ghi lại là bản sửa lỗi bảo mật và không nhận được CVE. Đây có thể là lý do tại sao Debian 12 và 13 chưa nhận được các bản backport bảo mật liên quan kịp thời. Vì Docker image của Discourse dựa trên Debian 12, nó đã cài đặt phiên bản libheif 1.19.7 dễ bị tổn thương. Ngay cả Debian 13 vẫn cung cấp phiên bản 1.19.8 dễ bị tổn thương vào thời điểm đó. Kể từ đó, Debian đã xuất bản bản cập nhật bảo mật cho Debian 13 vào ngày 8 tháng 8 năm 2026.

Vào ngày 24 tháng 7, chúng tôi đã sử dụng Opus 4.8 để phát triển một exploit thực thi mã ImageMagick/libheif hoạt động được khi ASLR bị vô hiệu hóa. Sau đó, chúng tôi khởi chạy nhiều phiên riêng biệt để làm cho nó ổn định với cấu hình mặc định của Discourse khi bật ASLR, nhưng không đạt kết quả.

Opus 5 đã được phát hành

Tối hôm đó, Anthropic đã phát hành Claude Opus 5. Chúng tôi bắt đầu một phiên làm việc mới, phiên này đã tạo ra một exploit ARM64 hoạt động được cho máy Mac cục bộ trong vòng 3 giờ. Sau đó, chúng tôi yêu cầu nó chuyển đổi exploit sang môi trường x86-64 và cấu hình jemalloc được Discourse sử dụng.

Đến 6 giờ sáng ngày 25 tháng 7, chúng tôi đã xác nhận RCE cục bộ thông qua việc tải lên hình ảnh. Sau đó, chúng tôi đặt Claude vào một vòng lặp tự động /goal nhắm vào instance Discourse Cloud của riêng chúng tôi, được proxy qua rce.ee/ctf-forum để làm cho nó trông giống như một mục tiêu CTF vì Opus từ chối viết exploit cho các instance từ xa.

Khi kiểm tra lại lúc 10 giờ sáng, tác nhân AI đã đạt được RCE trên Discourse Cloud và chứng minh quyền truy cập bằng cách đọc tệp /etc/hosts. Sử dụng tập lệnh exploit đã tạo, chúng tôi đã quản lý để có được RCE trên instance của OpenAI.

Sau khi xác nhận giả thuyết về việc chiếm đoạt tài khoản ChatGPT/Codex của các thành viên tích cực trên diễn đàn mà không cần tương tác, chúng tôi đã gửi báo cáo ngay lập tức cho OpenAI. Sau đó, chúng tôi chiếm quyền điều khiển tài khoản của một nhân viên OpenAI, người có Codex được kết nối với tổ chức Github của OpenAI. Để chứng minh tác động mà không thực sự truy cập vào bất kỳ mã nguồn nội bộ nào, chúng tôi đã gửi một prompt đến tài khoản Codex của nhân viên này để mở một PR cho chúng tôi trong monorepo nội bộ của OpenAI. Sau đó, chúng tôi dừng mọi thử nghiệm tiếp theo.

Chúng tôi đã cập nhật bài gửi trên BugCrowd với bằng chứng về tác động và cảnh báo cho bộ phận bảo mật của OpenAI. Chúng tôi cũng chuẩn bị một báo cáo cho Discourse và gửi đến chương trình HackerOne của họ. Discourse đã nhận được báo cáo vào thứ Bảy, phản hồi vào Chủ nhật và có bản sửa lỗi vào thứ Hai (khen ngợi về tốc độ). Họ cũng ngay lập tức bắt đầu đưa ImageMagick vào môi trường sandbox.

Chúng tôi muốn nhấn mạnh rằng lỗ hổng để leo thang đặc quyền không phải là vấn đề riêng của Discourse. Đó là một vấn đề SSO của OpenAI đã biến việc xâm nhập diễn đàn thành quyền truy cập vào ChatGPT và Codex. Nếu bất kỳ dịch vụ nào của OpenAI hoặc bên thứ ba sử dụng OpenAI SSO bị xâm nhập, nó cũng sẽ dẫn đến quyền truy cập tương tự - Discourse chỉ là một cách để chứng minh điều đó.

Chi phí để tìm ra các lỗ hổng này

Việc hack Discourse và OpenAI chỉ mất vài ngày đối với một tác nhân AI và chỉ vài giờ làm việc của con người. Toàn bộ dự án nghiên cứu HEIF Heist nhắm vào Slack, Zoom, Meta và nhiều nền tảng khác kéo dài hai tháng, tiêu tốn tổng cộng chưa đầy 3.000 USD tiền token và được thực hiện bởi ba nhà nghiên cứu. Việc điều chỉnh exploit cho mỗi công ty mới thường chỉ mất một hoặc hai ngày.

Chúng tôi quan sát thấy rằng mỗi mô hình mới đều ngày càng có khả năng hơn, điều này được thể hiện rõ qua exploit Discourse được trình bày trong báo cáo này. Opus 4.8 đã phải vật lộn qua nhiều phiên để tạo ra một exploit hoạt động được khi bật ASLR. Trong vòng vài giờ sau khi Opus 5 ra mắt, chúng tôi đưa cho nó cùng một vấn đề và nó đã thành công. Trong chiến dịch rộng lớn hơn, chúng tôi thấy một bước nhảy vọt rõ ràng khác từ Opus 5 lên GPT-5, khi chúng tôi phải khai thác lỗ hổng mà không biết gì về hệ thống mục tiêu ngoài việc nó dễ bị tổn thương.

Đối với mỗi mục tiêu, quá trình thử nghiệm bắt đầu bằng việc tải lên hình ảnh. Từ đó, chúng tôi biến lỗi hỏng bộ nhớ thành một lỗ rò rỉ bộ nhớ hoặc shell đáng tin cậy, thường là không cần biết chính xác phiên bản libheif, phiên bản libc hoặc môi trường triển khai. AI bắt đầu gần như mù mờ và điều chỉnh exploit cho mỗi công ty trong vòng một hoặc hai ngày. Chúng tôi không biết bất kỳ công ty nào phát hiện ra hoạt động này ngoại trừ Shopify, ngay cả sau khi hàng ngàn hình ảnh được gửi và các bộ xử lý hình ảnh của họ liên tục bị treo.

Khi việc thực thi mã nằm trong môi trường sandbox hoặc môi trường hạn chế, các mô hình cũng hỗ trợ leo thang đặc quyền, di chuyển ngang và vượt qua các biện pháp phòng thủ hiện có. Đây không hoàn toàn là việc hack tự động và sự hướng dẫn của con người có kỹ năng vẫn rất quan trọng, nhưng khối lượng công việc mà một nhóm nhỏ có thể thực hiện đã tăng lên đáng kể.

Lời kết

Phần mềm từ lâu đã được hưởng lợi từ một loại bảo mật thông qua sự phức tạp. Mã nguồn và thậm chí cả lỗ hổng có thể được công khai, nhưng việc biến một lỗi thành một exploit đáng tin cậy vẫn đòi hỏi chuyên môn hiếm có, thời gian đáng kể và kiến thức về môi trường mục tiêu. Các lỗ hổng hỏng bộ nhớ đã biết rất tốn kém để vận hành, trong khi các lỗ hổng zero-day chủ yếu dành cho các mục tiêu có giá trị cao nhất.

Đây chưa bao giờ là một ranh giới bảo mật thực sự, nhưng trên thực tế, nó bảo vệ các công ty bình thường khỏi các lỗ hổng phần mềm. AI đang loại bỏ sự bảo vệ đó bằng cách chuyển đổi nhiều chuyên môn khan hiếm này thành năng lực tính toán. Công việc từng đòi hỏi một nhóm có nguồn lực tốt và hàng tháng trời nỗ lực giờ đây có thể được nén lại chỉ trong vài ngày.

Các giả định về bảo mật phải bắt kịp với khả năng của kẻ tấn công. Một mô hình đe dọa thực tế nên tính đến khía cạnh kinh tế của việc khai thác ngày nay, thay vì dựa vào các giả định lỗi thời về việc ai có thể thực hiện các cuộc tấn công tinh vi.

Sứ mệnh của Hacktron là giúp bảo mật internet bằng cách tìm kiếm và loại bỏ các lỗ hổng trong các phần mềm được tin dùng rộng rãi trước khi những kẻ xấu làm điều đó. Chúng tôi đang tiếp tục nghiên cứu này trên các phòng thí nghiệm tiên phong và các hệ thống quan trọng khác của internet. Nếu bạn chịu trách nhiệm bảo mật một trong số đó, chúng tôi muốn làm việc với bạn.

Các phiên bản bị ảnh hưởng và các bản vá