Ba chuyên gia của Hacktron AI cho biết họ đã đi từ một tệp ảnh được tải lên diễn đàn OpenAI đến khả năng sử dụng tài khoản Codex của nhân viên để mở một pull request trong kho mã nội bộ. Toàn bộ quá trình từ phát hiện ban đầu đến lúc chứng minh quyền truy cập diễn ra trong chưa đầy 72 giờ.
Claude hỗ trợ nhóm phát triển và điều chỉnh exploit. Nhưng AI không phải nguyên nhân duy nhất khiến chuỗi tấn công thành công. Điểm vào vẫn là những vấn đề quen thuộc của kỹ nghệ phần mềm: thư viện xử lý ảnh chưa được vá, dịch vụ nhận tệp không được cô lập đủ chặt và phạm vi đăng nhập một lần quá rộng.
Bài viết này không hướng dẫn khai thác lỗ hổng. Mục tiêu là bóc tách các quyết định phòng thủ mà một lập trình viên backend có thể áp dụng ngay trong dự án của mình.
Chuỗi tấn công bắt đầu từ một tệp ảnh
Theo báo cáo kỹ thuật của Hacktron AI , diễn đàn community.openai.com sử dụng Discourse và cho phép tải ảnh HEIC, HEIF hoặc AVIF. Những tệp này được chuyển qua ImageMagick, rồi xuống thư viện libheif để giải mã.
Nhóm nghiên cứu phát hiện phiên bản libheif trong môi trường lúc đó còn thiếu bản vá bảo mật cần thiết. Một tệp ảnh được tạo có chủ đích có thể kích hoạt lỗi bộ nhớ và dẫn đến thực thi mã từ xa trên máy chủ xử lý ảnh.
Đây là một bài học dễ bị bỏ qua: ứng dụng của bạn có thể không gọi trực tiếp một thư viện dễ tổn thương. Lỗ hổng vẫn xuất hiện qua chuỗi phụ thuộc:
Upload ảnh → ImageMagick → libheif → lỗi giải mã → thực thi mã
Sau khi kiểm soát môi trường diễn đàn, nhóm tiếp tục phát hiện vấn đề trong luồng SSO của OpenAI. Theo báo cáo, lỗi này cho phép họ tiếp cận tài khoản ChatGPT và Codex của người dùng đang hoạt động, trong đó có tài khoản nhân viên được kết nối với GitHub nội bộ.
Để chứng minh tác động mà không đọc mã nguồn nhạy cảm, nhóm yêu cầu Codex mở một pull request vô hại trong kho mã riêng của OpenAI rồi dừng thử nghiệm. Hacktron đã báo cáo cho OpenAI và Discourse. OpenAI xác nhận lỗi phía mình được sửa khoảng 14 giờ sau báo cáo ban đầu và chi khoản thưởng 6.500 USD. Discourse cũng phát hành hướng dẫn vá và bổ sung sandbox cho quá trình xử lý ảnh.
TechCrunch đã đối chiếu câu chuyện ngày 18/09/2026. Chi tiết kỹ thuật và mốc thời gian trong bài này ưu tiên nguồn công bố trực tiếp của nhóm nghiên cứu.
AI đã thay đổi phần nào của cuộc tấn công?
Hacktron cho biết Claude Opus 4.8 chưa tạo được exploit ổn định trong nhiều phiên làm việc. Sau khi Claude Opus 5 được phát hành, nhóm đưa lại cùng bài toán và có một exploit chạy được trong vài giờ. Con người vẫn chọn mục tiêu, thiết lập môi trường, kiểm tra kết quả và quyết định điểm dừng.
Vì vậy, cách nói chính xác không phải là “Claude tự hack OpenAI”. AI đã giảm thời gian và lượng chuyên môn khan hiếm cần cho một số bước phát triển exploit. Chuỗi tấn công vẫn cần chuyên gia định hướng và kết hợp nhiều lỗi khác nhau.
Điều này làm thay đổi phép tính rủi ro. Một lỗi phức tạp từng khó chuyển thành tấn công thực tế có thể được thử nghiệm nhanh hơn khi người thực hiện có model mạnh, nhiều lượt chạy và môi trường phù hợp.
Năm việc lập trình viên Java cần kiểm tra
1. Không tin phần mở rộng và Content-Type của tệp
Tên avatar.jpg hoặc header image/jpeg không chứng minh nội dung thật của tệp. Backend cần kiểm tra chữ ký tệp, giới hạn dung lượng và chỉ nhận các định dạng thực sự cần cho nghiệp vụ.
Ví dụ, cấu hình giới hạn upload trong Spring Boot là lớp bảo vệ cơ bản:
spring.servlet.multipart.max-file-size=5MB
spring.servlet.multipart.max-request-size=6MBGiới hạn kích thước chưa đủ. Ứng dụng vẫn cần đọc magic bytes bằng một thư viện tin cậy, đổi tên tệp trên máy chủ và từ chối HEIF/AVIF nếu sản phẩm không có nhu cầu xử lý chúng.
2. Tách dịch vụ xử lý tệp khỏi ứng dụng chính
Không nên giải mã ảnh trong cùng tiến trình đang giữ session, khóa truy cập cơ sở dữ liệu hoặc quyền gọi dịch vụ nội bộ.
Một pipeline an toàn hơn có thể gồm:
API nhận tệp → vùng lưu tạm → hàng đợi → worker cô lập → quét/đổi định dạng → kho tệp sạch
Worker nên chạy bằng tài khoản riêng, filesystem chỉ đọc khi có thể, không giữ secret sản xuất và không được tự do truy cập mạng nội bộ. Nếu worker bị chiếm, phạm vi thiệt hại phải dừng ở đó.
3. Quét cả phụ thuộc trực tiếp lẫn phụ thuộc hệ điều hành
Maven hoặc Gradle chỉ cho bạn biết một phần cây phụ thuộc. ImageMagick, libheif, OpenSSL và các gói trong Docker image có thể nằm ngoài pom.xml.
Trong CI/CD, đội phát triển nên kết hợp:
mvn dependency:tree
mvn org.owasp:dependency-check-maven:check
docker scout cves <ten-image>:<tag>Tên công cụ có thể thay đổi theo hạ tầng, nhưng nguyên tắc không đổi: quét source dependency, container image và gói hệ điều hành. Cảnh báo nghiêm trọng phải có người chịu trách nhiệm xử lý, không chỉ xuất một file báo cáo rồi bỏ đó.
4. Xem SSO là ranh giới quyền, không chỉ là tiện ích đăng nhập
Một tài khoản đăng nhập được vào nhiều hệ thống sẽ tạo trải nghiệm thuận tiện. Nó cũng làm tăng bán kính ảnh hưởng khi một dịch vụ vệ tinh bị chiếm.
Mỗi ứng dụng cần kiểm tra lại:
- Token dành cho dịch vụ nào và có bị chấp nhận ở nơi khác không?
- Scope có rộng hơn nhu cầu thật không?
- Tài khoản nhân viên có được bảo vệ khác tài khoản cộng đồng không?
- Kết nối GitHub, email hoặc công cụ nội bộ có yêu cầu xác nhận lại không?
- Phiên đăng nhập có thể bị thu hồi nhanh khi phát hiện sự cố không?
SSO tốt phải giảm số lần đăng nhập mà không biến một lỗi nhỏ thành chìa khóa mở toàn bộ hệ thống.
5. Kiểm soát quyền của AI agent như một tài khoản kỹ thuật
Codex không tự tạo ra quyền truy cập GitHub. Nó sử dụng quyền đã được kết nối với tài khoản bị chiếm. Đây là lý do agent cần được quản trị như service account:
- Chỉ cấp quyền vào repository cần thiết.
- Tách quyền đọc, tạo nhánh, mở PR và merge.
- Không cho agent giữ secret lâu dài nếu không cần.
- Ghi log tool call và thay đổi do agent tạo.
- Yêu cầu con người duyệt các hành động có tác động lớn.
Agent càng làm được nhiều việc, cơ chế thu hồi quyền và audit càng phải rõ.
Checklist trước khi đưa chức năng upload lên production
Trước khi phát hành một API nhận ảnh hoặc tài liệu, đội phát triển nên trả lời được các câu hỏi sau:
- Danh sách định dạng cho phép có được khai báo rõ không?
- Backend có kiểm tra nội dung thực thay vì chỉ đọc tên tệp không?
- Dung lượng, số lượng và thời gian xử lý có bị giới hạn không?
- Tệp được lưu bên ngoài thư mục thực thi và web root chưa?
- Công đoạn giải mã có chạy trong worker cô lập không?
- Container image và gói hệ điều hành đã được quét lỗ hổng chưa?
- Worker có thể truy cập database, metadata service hoặc mạng nội bộ không?
- Log có đủ để phát hiện hàng nghìn tệp lỗi hoặc tiến trình giải mã crash liên tục không?
- Có quy trình vá nhanh và thu hồi session khi xảy ra sự cố không?
Nếu chưa trả lời được một câu, đó là một công việc kỹ thuật cần được đưa vào backlog trước khi tăng lưu lượng.
Điều sinh viên nên học từ sự cố này
Học backend không dừng ở việc làm cho API trả về HTTP 200. Một lập trình viên cần hiểu dữ liệu đi qua những thành phần nào, mỗi thành phần giữ quyền gì và điều gì xảy ra khi một mắt xích bị phá vỡ.
Khi làm project Java/Spring Boot, hãy tập thói quen vẽ luồng xử lý, kiểm tra dependency, viết test cho dữ liệu xấu và giải thích được quyết định phân quyền. Đây cũng là cách VCoderLog tổ chức lộ trình Java Full-stack: học khái niệm, làm lab, review code và sửa lại phần chưa đạt thay vì chỉ hoàn thành giao diện.
Nếu bạn mới bắt đầu, có thể đọc thêm lộ trình Java và Spring Boot hoặc cách dùng AI khi học lập trình mà không mất khả năng tự giải quyết.
VCoderLog Academy nhận tư vấn lộ trình tại edu.vcoderlog.com/lien-he, địa chỉ 261 Phan Đăng Lưu, Kiến An, Hải Phòng, cách cổng Đại học Hải Phòng khoảng 300m. Hotline/Zalo: 083.55.28.228.
Nguồn tham khảo
- Hacktron AI: Hacking OpenAI , công bố ngày 13/09/2026.
- TechCrunch: Researchers used Anthropic’s Claude to hack into OpenAI , ngày 18/09/2026.
- Discourse advisory GHSA-vhm9-85gw-x335 .
Giới hạn thông tin: Bài viết dựa trên công bố của Hacktron và nguồn báo chí đối chiếu. Nhóm nghiên cứu cho biết họ không đọc mã nguồn nhạy cảm; họ tạo một pull request vô hại để chứng minh quyền truy cập rồi dừng thử nghiệm. Không nên diễn giải sự việc thành “Claude tự động hack OpenAI”.
