Hai cách thoát khỏi sandbox OpenAI Codex: Heapjack và Overpatch

Vào ngày 15 tháng 9 năm 2026, Oren Yomtov, một nhà nghiên cứu bảo mật chính tại Accomplish AI, đã công bố một bài mô tả kỹ thuật về hai cách riêng biệt để thoát khỏi hộp cát bao quanh tác nhân lập trình Codex của OpenAI. Cả hai đều được báo cáo cho OpenAI vào ngày 12 tháng 8 năm 2026 và cả hai đều được khắc phục trong vòng tám ngày, theo bài viết của ông: Heapjack trong Codex Desktop bản dựng 26.818.21641 và Overpatch trong Codex CLI 0.149.0. Heapjack là lỗ hổng nghiêm trọng hơn trong hai. Nó không đòi hỏi gì ở người bị tấn công ngoài việc mở một kho lưu trữ trong Codex và đặt một câu hỏi về đoạn mã, và nó hoạt động ở chế độ chỉ đọc, chế độ nghiêm ngặt nhất mà sản phẩm cung cấp, không có lời nhắc phê duyệt và không hiển thị gì trên màn hình. Không có CVE nào được cấp cho cả hai lỗ hổng và không có thông báo riêng nào của OpenAI được công bố, theo Cloud Security Alliance, và chưa có ai được báo cáo là bị ảnh hưởng bởi chúng. Nó được đưa vào danh mục cùng với các mục khác trong năm về kiểm soát tác nhân trong kho lưu trữ sự cố AI, nơi mỗi bản ghi đều kèm theo tài liệu nguồn, mức độ tin cậy và cờ tranh chấp.

Heapjack: token nằm trong một heap mà bên không đáng tin cậy có thể đọc được

Codex Desktop không hỏi trước khi cài đặt thành phần mà Yomtov đã tấn công. Tại thời điểm cài đặt, nó ghi một khối node_repl vào tệp cấu hình toàn cục tại ~/.codex/config.toml, và Yomtov báo cáo rằng không có cơ chế chọn tham gia nào và không có cài đặt nào để tắt nó. Bởi vì mục này nằm trong cấu hình dùng chung thay vì trong lựa chọn của từng người dùng, một người dùng Codex CLI thông thường sẽ thừa hưởng cùng công cụ đó mà không bao giờ được hỏi.

Công cụ node_repl bản thân là một chương trình native chạy bên ngoài sandbox. Nó có thể mở ứng dụng, kết nối tới Unix socket và chỉnh sửa tệp cấu hình toàn cục. Thứ mà nó khởi chạy bên trong sandbox là một tiến trình Node.js duy nhất, và tiến trình đó nắm giữ hai ngữ cảnh thực thi JavaScript: một ngữ cảnh tin cậy chứa mã của chính OpenAI, và một ngữ cảnh không tin cậy chạy bất cứ điều gì tác nhân được yêu cầu thực hiện.

Ngữ cảnh tin cậy chứng minh rằng nó đáng tin cậy bằng cách trình ra một token ngẫu nhiên, được tạo mới trong mỗi lần chạy. Đó được cho là ranh giới giữa hai ngữ cảnh. Nhưng nó không phải vậy, bởi vì cả hai ngữ cảnh cùng nằm trong một V8 isolate duy nhất dùng chung một heap bộ nhớ, nên token chỉ là một chuỗi nằm trong bộ nhớ mà mã không đáng tin cậy có thể đọc được. Một người bình luận phản ứng với thông tin tiết lộ trên X đã nói thẳng vấn đề hơn, trong một câu mà BleepingComputer trích dẫn: "Các ngữ cảnh V8 cô lập các biến toàn cục, không phải bộ nhớ, vì vậy sandbox thực ra chỉ là một lời hứa mà heap chưa từng đồng ý." Đó là một cách mô tả, không phải bằng chứng; bằng chứng là proof of concept.

Khai thác của Yomtov làm đúng những gì mô tả đó hàm ý. JavaScript không đáng tin cậy gọi v8.getHeapSnapshot(), quét ảnh chụp heap thu được để tìm các chuỗi có dạng UUID, rồi kiểm thử từng ứng viên. Một phỏng đoán sai sẽ trả về "not authorized". Một token đúng đi kèm đối số không hợp lệ thì thay vào đó trả về một lỗi xác thực thực sự. Sự khác biệt giữa hai thông báo lỗi chính là oracle giúp xác định giá trị đúng.

Khi đã có token trong tay, tiến trình chạy trong sandbox sẽ ghi yêu cầu JSON của chính nó vào bộ mô tả tệp 1 — cũng chính là ống stdout mà ngữ cảnh tin cậy dùng để liên lạc với tiến trình cha gốc. Tiến trình cha xác thực token, thấy token hợp lệ và thực hiện công việc. Trong bản chứng minh khái niệm, công việc đó là lệnh open của hệ thống, lệnh này chuyển yêu cầu cho launchd và khởi chạy ứng dụng hoàn toàn bên ngoài cây tiến trình của Codex. Cùng token đó cũng cho phép kết nối tới các Unix socket tùy ý, trong đó có socket daemon Docker, và với tới một công cụ để chỉnh sửa tệp cấu hình toàn cục.

Tất cả đều chạy ở chế độ chỉ đọc, chế độ mà một người dùng thận trọng chọn chính vì kho lưu trữ trước mặt họ không đáng tin. Không có lời nhắc phê duyệt nào xuất hiện ở bất kỳ giai đoạn nào. Kịch bản thực tế rất ngắn: mở một kho lưu trữ đã sao chép trong Codex, ở chế độ chỉ đọc, và đặt một câu hỏi về mã. Bất kỳ ai đã viết kho lưu trữ đó đều có thể thực thi lệnh không qua sandbox trên máy, và không có gì trên màn hình cho biết điều đó.

Overpatch: một công cụ vá đã ban phần tử cha cho mọi thứ mà nó chạm vào

Lỗ hổng thứ hai nằm trong Codex CLI, tác nhân dòng lệnh mã nguồn mở, và đó là một lỗi về quyền chứ không phải lỗi về bộ nhớ. Ở chế độ workspace-write, tác nhân có thể ghi bên trong thư mục dự án và không nơi nào khác; một lệnh shell nhắm vào thư mục home sẽ bị từ chối. Công cụ apply_patch lẽ ra phải giữ vững ranh giới đó. Thay vào đó, nó suy ra quyền từ các đường dẫn được nêu trong bản vá mà nó đang áp dụng, và nó cấp quyền ghi cho thư mục cha của từng đường dẫn.

Chỉ cần nêu một đường dẫn bên trong /tmp trong một bản vá là quyền được cấp sẽ mở rộng tới gốc của ổ đĩa, vì thư mục cha của /tmp là /. Toàn bộ mẹo nằm ở đó.

Khai thác đang hoạt động sử dụng hai mục trong một bản vá duy nhất. Mục đầu tiên chỉ định /tmp và không làm gì hữu ích — nó thất bại, vì một tệp không thể ghi đè lên một thư mục — và chỉ tồn tại để mở rộng quyền được cấp. Mục thứ hai nối thêm một dòng vào .zshrc thông qua một liên kết tượng trưng vào thư mục home. Xóa mục đầu tiên thì thao tác ghi bị từ chối. Giữ nó thì terminal tiếp theo mà nhà phát triển mở sẽ chạy dòng của kẻ tấn công mà không bị sandbox, với sandbox hoàn toàn không còn tham gia nữa.

Điều đó khiến Overpatch trở thành một lỗi persistence (duy trì dai dẳng) chứ không phải sự cố chỉ xảy ra một lần. Tệp khởi động bị đầu độc sẽ thực thi lại mỗi khi nhà phát triển mở một shell, cho đến khi ai đó đọc .zshrc và nhận ra dòng bị thêm vào — đó là lý do hướng dẫn của Cloud Security Alliance là chủ động truy tìm nó thay vì chờ triệu chứng.

Cả hai lỗi đều đặt cơ chế thực thi vào bên trong chính thứ đang được thực thi

Cách chính Yomtov đóng khung vấn đề là phần vượt ra ngoài Codex. apply_patch tự tính quyền của mình từ dữ liệu đầu vào do kẻ tấn công cung cấp. node_repl giữ bí mật phân tách mã tin cậy khỏi mã không tin cậy trong bộ nhớ mà mã không tin cậy có thể đọc. Trong mỗi trường hợp, sandbox đều được yêu cầu — từ bên trong — cho thứ gì đó đi qua.

Hình dạng này không mới. BleepingComputer, đơn vị đưa tin về thông tin được tiết lộ vào ngày 20 tháng 9 năm 2026, lưu ý rằng vào tháng 7 năm 2026, các nhà nghiên cứu của Pillar Security đã trình diễn cùng ý tưởng đó trên Cursor, Codex, Gemini CLI và Antigravity của Google, nơi một tác nhân nằm trong sandbox của nó ghi một tệp mà một công cụ đáng tin cậy bên ngoài sandbox sau đó sẽ thực thi. Điều khiến cặp Codex trở nên đáng chú ý là cơ chế vượt qua chỉ đọc trong Heapjack và việc không có bất kỳ cài đặt nào để vô hiệu hóa thành phần mang nó.

Các bản sửa lỗi, và những gì OpenAI đã nói và chưa nói

OpenAI đã khắc phục Heapjack trong bản dựng 26.818.21641 của Codex Desktop và Overpatch trong Codex CLI 0.149.0, theo Accomplish. Cả hai đều được xử lý trong vòng tám ngày kể từ báo cáo ngày 12 tháng 8 — tính đến ngày 20 tháng 8, theo cách đọc thông thường của mốc thời gian đó — và Yomtov ghi nhận OpenAI đã xoay chuyển được tình thế.

OpenAI không công bố bất kỳ bản tư vấn bảo mật độc lập nào cho cả hai lỗ hổng, và không có mã nhận dạng CVE nào được gán; Cloud Security Alliance ghi nhận cả hai sự thiếu vắng này trong một ghi chú nghiên cứu ngày 22 tháng 9 năm 2026. Khi được đề nghị bình luận, một phát ngôn viên của OpenAI nói với BleepingComputer: “Chúng tôi cảm ơn các nhà nghiên cứu đã liên hệ với chúng tôi và chia sẻ phát hiện của họ. Chúng tôi đã giải quyết cả hai vấn đề vào tháng 8, nhưng chúng tôi không ngừng củng cố các sandbox của mình, với các cập nhật gần đây siết chặt kiểm soát đối với nơi tác nhân có thể ghi tệp và mở rộng thử nghiệm các biện pháp bảo vệ đó trên nhiều nền tảng.”

Tuyên bố đó xác nhận các bản sửa lỗi và không nói gì về các cơ chế. Nó không cho biết liệu những thay đổi hồi tháng Tám đã loại bỏ mẫu thiết kế hay đã đóng hai con đường cụ thể thoát ra khỏi nó. Cũng không ai bên ngoài OpenAI nói như vậy.

Điều gì đã được xác lập, và điều gì chỉ dựa trên một nhà nghiên cứu?

Cơ quan lưu trữ xếp mục này vào hồ sơ như một phát hiện nghiên cứu, mức độ nghiêm trọng cao, khu vực toàn cầu, độ tin cậy B — được ghi nhận bằng tài liệu, nhưng chỉ từ một nguồn duy nhất hoặc nguồn thứ cấp — không bị tranh cãi, và không ghi nhận tổn hại thực sự nào. Mức xếp hạng đó là lăng kính phù hợp để đọc phần còn lại của bài này, bởi vì sự phân tách giữa những gì nhiều bên xác nhận và những gì chỉ người phát hiện khẳng định chạy xuyên suốt toàn bộ câu chuyện.

Đã được xác lập, theo nghĩa rằng có nhiều hơn một bên nói điều đó:

• Bản công bố có tồn tại và có ghi ngày. Bài viết của Yomtov được xuất bản vào ngày 15 tháng 9 năm 2026; cả hai lỗ hổng đã được báo cáo cho OpenAI vào ngày 12 tháng 8 năm 2026 và, theo lời ông, đã được khắc phục trong vòng tám ngày.

• OpenAI xác nhận đã hành động vào tháng 8. Người phát ngôn của công ty nói với BleepingComputer rằng cả hai vấn đề đều đã được xử lý, điều này củng cố mốc thời gian báo cáo và khắc phục một cách độc lập với người phát hiện, dù công ty không công bố khuyến cáo nào và không có bản tường trình kỹ thuật nào của riêng mình.

• Các phiên bản đã khắc phục được nêu nhất quán. Bản dựng 26.818.21641 cho Codex Desktop và phiên bản 0.149.0 cho Codex CLI được Accomplish đưa ra, được BleepingComputer nhắc lại và được nêu trong khuyến cáo ngày 22 tháng 9 năm 2026 của Nhóm Ứng cứu Khẩn cấp và Điều phối Máy tính Quốc gia Uganda, cơ quan đã đánh giá cặp phiên bản này ở mức "Red".

• Không có CVE, không có khuyến cáo bảo mật từ nhà cung cấp và không có báo cáo về việc bị khai thác. Ghi chú ngày 22 tháng 9 năm 2026 của Cloud Security Alliance ghi nhận việc không có cả CVE và không có khuyến cáo riêng từ OpenAI, đồng thời báo cáo không có trường hợp nào được xác nhận về việc một tổ chức phát hiện cơ chế duy trì của Overpatch đang hiện diện.

• Cơ quan lưu trữ không phản bác bất kỳ điều nào trong đó. Hồ sơ được đánh dấu là không tranh chấp, và mức xếp hạng độ tin cậy của nó phản ánh mô hình nguồn tham chiếu chứ không phải bất kỳ bất đồng nào về các sự kiện.

Không được xác lập, hoặc chỉ được xác lập bởi chính người tìm thấy:

• Chi tiết cơ chế thuộc về Yomtov. Oracle ảnh chụp heap, bộ mô tả tệp dùng chung, quyền cấp cho thư mục cha — tất cả đều đến từ bài viết và bản chứng minh khái niệm của ông. Cloud Security Alliance, với ghi chú là bản tóm tắt bên thứ ba chi tiết nhất đang lưu hành, mô tả việc tổng hợp lời kể của ông và bài đưa tin của BleepingComputer, và không nêu rằng mình đã tái tạo một trong hai khai thác hoặc kiểm thử một trong hai bản vá. Khuyến cáo của CERT.UG biên soạn cùng nguồn tài liệu đó.

• Các dải phiên bản dễ bị tổn thương chưa bao giờ được công bố. Chỉ các phiên bản sửa lỗi được nêu tên, nên không có danh sách những bản dựng trước đó từng chứa mỗi lỗ hổng.

• Liệu một bản cài đã được vá có an toàn trước cả nhóm lỗi, chứ không chỉ trước hai trường hợp này, thì không được nêu rõ. Việc OpenAI “liên tục củng cố các sandbox của chúng tôi” là một cam kết chung, không phải tuyên bố về một cơ chế cụ thể.

• Chưa có ai được báo cáo là đã khai thác một trong hai lỗ hổng này. Đó là việc thiếu báo cáo, chứ không phải là kết luận rằng không có chuyện gì xảy ra, và bằng chứng khái niệm cho thấy đường tấn công Heapjack không để lại bất cứ thứ gì trên màn hình cho người dùng nhận ra.

Những gì người dùng có thể thao tác

Bất kỳ ai đang dùng bản dựng Codex Desktop cũ hơn 26.818.21641, hoặc phiên bản Codex CLI cũ hơn 0.149.0, đều nằm ở phía dễ bị tổn thương của ranh giới mà Accomplish vạch ra, và cập nhật là biện pháp khắc phục duy nhất mà thông tin công bố đưa ra. Ngoài ra, Cloud Security Alliance khuyến nghị rà soát các phiên Codex Desktop trước đây có liên quan đến những kho lưu trữ không đáng tin cậy để tìm hoạt động launchd hoặc open và các kết nối socket Docker, đồng thời đọc các tệp khởi động shell — .zshrc, .bashrc và các tệp tương đương — để tìm những lệnh được chèn thêm vào thay vì do người dùng tự viết.

Ghi chú tương tự cũng khuyên không nên coi chế độ chỉ đọc là biện pháp bảo vệ khi kho lưu trữ không đáng tin cậy, và đây cũng là kết luận mà Heapjack tự đưa ra. Các khuyến nghị về cấu trúc của nó còn đi xa hơn: cách ly tiến trình và bộ nhớ vật lý thay vì bí mật dùng chung và quy ước, thông tin đăng nhập được giữ ngoài tầm với của tác nhân, và các bản vá tham chiếu đến đường dẫn bên ngoài dự án bị coi là đáng ngờ ngay từ cái nhìn đầu tiên. Đó là những đề xuất từ một bên thứ ba. Việc OpenAI có áp dụng bất kỳ đề xuất nào trong số đó ngoài hai lần tăng phiên bản hay không thì không được công khai.

Hai điều đáng được tách bạch khi kết lại. Một là cặp lỗi trong một tác nhân lập trình được dùng rộng rãi, được báo cáo vào ngày 12 tháng 8 năm 2026, được sửa trong vòng tám ngày và được đóng lại trong hai số bản dựng. Điều còn lại là câu hỏi thiết kế mà Yomtov nêu tên — liệu một sandbox có thể được thực thi bởi chính đoạn mã mà nó lẽ ra phải chứa hay không — và đó không phải là câu hỏi mà một số hiệu phiên bản có thể trả lời. Cả Accomplish lẫn OpenAI đều chưa nói rằng những thay đổi hồi tháng 8 đã giải quyết được điều đó.