Lỗ hổng ChatGPT cho phép chiếm đoạt tài khoản chỉ bằng một cú nhấp vào link chia sẻ

Nhóm nghiên cứu bảo mật của Parameter vừa công bố một chuỗi lỗ hổng nghiêm trọng trong ChatGPT: kẻ tấn công có thể tạo một hội thoại độc hại, chia sẻ công khai qua tính năng bình thường của ChatGPT và gửi liên kết cho nạn nhân. Khi nạn nhân mở link, mã JavaScript của kẻ tấn công sẽ chạy ngay trong phiên đăng nhập của họ với danh tính chatgpt.com.

Đáng chú ý, nạn nhân không cần cài ứng dụng, không cần tham gia dự án nào, không dán mã và cũng không mở công cụ dành cho nhà phát triển. Chỉ cần mở liên kết là đủ. OpenAI đã khắc phục sự cố vào ngày 26/10/2026, phân loại mức độ nghiêm trọng P1 và trao tổng tiền thưởng 5.000 USD.

Minh họa trang chia sẻ công khai của ChatGPT bị chỉnh sửa

Chuỗi tấn công bắt đầu từ hai tính năng vô hại

Điểm khởi đầu của nghiên cứu là một câu hỏi đơn giản: nếu mã trong tính năng Preview bị nhốt trong một trang web khác, nó còn có thể liên lạc được với những gì?

ChatGPT có thể biến một khối mã HTML thành trang web nhỏ hoạt động thực sự thông qua tính năng Preview. Vì trang này có thể chứa mã tùy ý, ChatGPT chạy nó trong một khung bị hạn chế trên địa chỉ web khác. Ban đầu, lớp cách ly này hoạt động đúng như thiết kế: mã trong Preview không thể đọc parent.document — tức trang ChatGPT chính.

Thế nhưng, cuộc hội thoại còn chứa một biểu đồ tương tác thông thường. Phía sau, biểu đồ này tải một thư viện toán học tên MathLive. Việc tải thư viện không chỉ để vẽ đồ thị mà còn cài đặt một trình lắng nghe tin nhắn trong trang ChatGPT chính, phục vụ bàn phím ảo của MathLive.

Trình duyệt sử dụng API postMessage — cách hợp lệ để hai khung trao đổi thông tin dù không đọc được trang của nhau. Có thể hình dung như một khe thư: khung Preview bị hạn chế không thể bước vào trang chính, nhưng vẫn có thể thả tin nhắn qua khe. Điều này chỉ an toàn nếu bên nhận kiểm tra ai đã gửi tin.

MathLive đã không thực hiện kiểm tra đó. Trình lắng nghe của nó chấp nhận một tin nhắn thay đổi bố cục bàn phím ảo, và bố cục này lại được phép chứa HTML. Biểu đồ đã cài đặt bên nhận, còn Preview cung cấp bên gửi không đáng tin — hai tính năng không liên quan vô tình tạo ra con đường vượt qua sandbox.

Từ HTML đến thực thi JavaScript

Bước tiếp theo là chèn một thẻ iframe với thuộc tính srcdoc, cho phép khung nhúng mang HTML trực tiếp trong thuộc tính. MathLive đã chèn khung này vào tài liệu chính của ChatGPT mà không có thuộc tính sandbox. Điều này mang lại hai đặc tính nguy hiểm: srcdoc tạo một tài liệu mới nơi script bên ngoài có thể thực thi, và vì trang ChatGPT chính tạo khung, trình duyệt gán cho nó danh tính https://chatgpt.com.

Tuy nhiên, Content Security Policy (CSP) của ChatGPT vẫn chặn JavaScript nội tuyến. Nhưng CSP lại cho phép tải script từ YouTube. Lợi dụng endpoint oEmbed của YouTube hỗ trợ tham số callback kiểu JSONP, nhóm nghiên cứu đã khiến YouTube trả về mã JavaScript thực thi đoạn callback của họ. Vì YouTube nằm trong danh sách được CSP cho phép, trình duyệt đã tải và chạy mã này bên trong khung mới.

Đến đây, mã JavaScript tùy ý đã chạy với danh tính chatgpt.com.

Từ lỗi phòng thí nghiệm thành một liên kết công khai

Phiên bản thử nghiệm đầu tiên chưa đủ thuyết phục vì sử dụng một ứng dụng ChatGPT do nhà nghiên cứu kiểm soát làm bên gửi. Bước đột phá là đặt cả hai thành phần vào một cuộc hội thoại công khai thông thường: một biểu đồ thật khởi tạo MathLive trong trang chính, và một khối Preview do trợ lý AI tạo sau đó gửi hai tin nhắn độc hại.

Liên kết /share/ thu được bảo toàn toàn bộ chuỗi tấn công. Kẻ tấn công có thể gửi nó qua email, tin nhắn, phiếu hỗ trợ hay bài đăng mạng xã hội như bất kỳ hội thoại chia sẻ nào. Trong phiên bản ổn định nhất, nạn nhân mở link và nhấp nút Preview một lần; sau đó nhóm nghiên cứu đánh dấu khối HTML để ChatGPT tự động mở, khiến việc mở link trở thành thao tác duy nhất. Họ đã tái hiện đường dẫn tự động ba lần trên một tài khoản khác, kể cả sau khi tải lại cứng, với cảnh báo xuất hiện sau khoảng 4,5 giây.

Đánh cắp dữ liệu hội thoại riêng tư

Mã chạy với danh tính chatgpt.com nên có thể tương tác với ChatGPT trong cùng ngữ cảnh xác thực như ứng dụng web bình thường. Đoạn mã đã đọc thông tin phiên có sẵn trên trang và dùng nó để gọi API hội thoại của ChatGPT.

Đầu tiên, nó liệt kê danh sách các cuộc trò chuyện gần đây của nạn nhân. Sau đó, nó yêu cầu dữ liệu tin nhắn của một cuộc trò chuyện riêng tư cụ thể — cuộc trò chuyện này hoàn toàn không liên quan đến link độc hại và chưa từng được chia sẻ với kẻ tấn công. Tiếp theo, mã tạo một yêu cầu hình ảnh thông thường tới máy chủ do kẻ tấn công kiểm soát để gửi dữ liệu ra ngoài.

Đây là truy cập API có xác thực trực tiếp, không phải thu thập văn bản tình cờ hiển thị trên màn hình.

Nhóm nghiên cứu chỉ cố ý gửi một phần nhỏ dữ liệu ra ngoài để chứng minh. Vì mã đã nhận được toàn bộ phản hồi hội thoại có xác thực, lỗ hổng không giới hạn ở giá trị đó — về lý thuyết, kẻ tấn công có thể thực hiện bất kỳ hành động nào thay mặt tài khoản ChatGPT của nạn nhân.

Minh chứng dữ liệu hội thoại riêng tư có thể rò rỉ khỏi phiên của nạn nhân

Ba sai sót thiết kế và cách OpenAI khắc phục

Bản thân sandbox của Preview hoạt động đúng. Vấn đề nằm ở chỗ một thành phần khác trong trang chính sẵn sàng chấp nhận chỉ thị từ nó. Ba quyết định thiết kế đã biến sai sót này thành lỗ hổng hoàn chỉnh:

• MathLive chấp nhận tin nhắn thay đổi trạng thái mà không xác minh khung nào gửi.
• Định dạng tin nhắn cho phép cung cấp HTML thô làm dữ liệu bố cục bàn phím.
• HTML đó có thể tạo một tài liệu không sandbox kế thừa danh tính chatgpt.com.

Phản hồi từ YouTube chỉ là giải pháp vòng cuối cho CSP, không phải nguyên nhân gốc. Chỉ chặn endpoint đó sẽ loại bỏ một đường dẫn tới JavaScript nhưng vẫn để Preview không đáng tin chèn được HTML vào ChatGPT.

OpenAI đã tái hiện cả việc thực thi JavaScript lẫn chứng minh đọc hội thoại riêng tư. Bản vá được triển khai qua hai phiên bản giao diện web ChatGPT. Ngày 26/10, OpenAI xác nhận cả hai phiên bản đã từ chối tin nhắn MathLive xuyên khung.

Bài học bảo mật

Sự cố cho thấy ranh giới bảo mật phải được duy trì trên toàn bộ sản phẩm, không chỉ trong từng thành phần riêng lẻ. Mọi bề mặt công khai hoặc có thể chia sẻ đều nên được coi là đầu vào do kẻ tấn công kiểm soát.

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

• Bên nhận tin nhắn phải xác minh cả địa chỉ web của người gửi lẫn đúng cửa sổ đã được cấp quyền.
• Cấu hình xuyên cửa sổ không nên chứa HTML thô.
• Tài liệu được tạo động phải giữ sandbox khi nội dung có thể bị ảnh hưởng bởi khung không đáng tin.
• CSP nên là lớp phòng thủ dự phòng, không phải rào cản duy nhất sau khi HTML do kẻ tấn công kiểm soát đã vào được trang chính.

Lỗ hổng này đặc biệt đáng chú ý vì mọi tính năng riêng lẻ đều có vẻ hợp lý: Preview được cách ly, biểu đồ tải bàn phím toán học, các khung trao đổi tin nhắn, CSP cho phép một nhà cung cấp truyền thông lớn, hội thoại công khai có thể chia sẻ. Chỉ khi tất cả được kết hợp trên một trang, lỗ hổng mới xuất hiện — ở những đường nối giữa các tính năng chứ không phải trong bất kỳ tính năng đơn lẻ nào.

Đối với người dùng tại Việt Nam và trên toàn cầu, sự cố là lời nhắc nhở thận trọng khi mở các liên kết chia sẻ hội thoại AI từ nguồn không quen biết, đồng thời cho thấy tầm quan trọng của việc các nền tảng AI lớn duy trì chương trình săn lỗi và phản hồi nhanh với các báo cáo bảo mật.