Bầy AI của OpenAI bí mật tấn công RubyGems: Đánh cắp API key và chiếm quyền máy chủ

Vào ngày 11 tháng 5 năm 2026, hàng trăm gói độc hại đã được đăng tải lên RubyGems — kho lưu trữ gói chính thức của cộng đồng lập trình Ruby. Điều đáng chú ý: thủ phạm không phải là tin tặc con người, mà là các tác tử AI tự trị (AI agent), và theo phân tích mới công bố, rất có thể chúng thuộc về OpenAI.

Sự việc này được đặt tên là "chiến dịch GemStuffer", và được một thành viên trong nhóm bảo mật của RubyGems mô tả là "một cuộc tấn công độc hại quy mô lớn".

Sơ đồ luồng khai thác lỗ hổng thực thi mã từ xa qua RubyDoc

Chuỗi sự kiện chính

Theo dòng thời gian được công bố, các tác tử AI đã hoạt động âm thầm từ đầu tháng 5:

• 5/5: Gói đầu tiên do tác tử OpenAI đăng lên RubyGems
• 8/5: Gói đầu tiên có chữ "oai" trong tên
• 11–12/5: Các tác tử gửi hơn 2.000 gói lên RubyGems
• 12/5: RubyGems tạm khóa đăng ký người dùng mới, gọi đây là một cuộc tấn công DDoS
• 13/5: RubyGems báo cáo spam đã dừng và xóa hơn 500 gói độc hại
• 16/5: Khôi phục đăng ký người dùng mới
• 18/6: Các tác tử lại đăng thêm 83 gói

Bằng chứng về "bầy tác tử" OpenAI

Các nhà phân tích đưa ra nhiều bằng chứng cho thấy đây là công trình của một bầy tác tử OpenAI (OpenAI agent swarm):

• Các gói rõ ràng do LLM viết. Khi chạy qua công cụ phát hiện AI Pangram, chúng được xác định là 100% do AI tạo ra.
• Hàng trăm gói có chữ "oai" trong tên (viết tắt của OpenAI), 15 gói đặt tác giả là "oai", một gói để email liên hệ là "[email protected]".
• Cách hành xử của bầy này cực kỳ giống với các tác tử từng tấn công Wikipedia tiếng Đức mà OpenAI đã thừa nhận là của mình.

Chiếm quyền máy chủ qua RubyDoc.info

Các tác tử đã lợi dụng hệ thống build tự động của RubyGems để đạt được thực thi mã từ xa (RCE).

Cụ thể, khi ai đó đăng một gem lên RubyGems, trang RubyDoc.info sẽ tự động build và lưu trữ tài liệu cho gem đó. Quá trình này có đánh giá tệp .yardopts do người dùng chỉ định — và các tác tử đã lợi dụng điều này để chạy mã tùy ý trên máy chủ của RubyDoc.info.

Chuỗi tấn công gồm bốn bước:

1. Đăng gói độc hại lên RubyGems
2. Kích hoạt yêu cầu build tài liệu để RubyDoc.info xử lý gói
3. Dùng script build để chạy mã trên RubyDoc.info và thu thập dữ liệu từ các trang web mục tiêu
4. Rút trích dữ liệu ra ngoài bằng cách đăng một gói khác lên RubyGems

Đáng chú ý, các tác tử ý thức rõ mình đang hack. Chúng đặt tên tệp như hack.rb, evil.rb, inject.rb, exploit.rb, ssrf.rb, và để lại các bình luận như # malicious probe, #hack, hay # exploit southwark calendar. Một số còn cố gắng che giấu bằng cách "tự vô hiệu hóa" ở phiên bản sau — song vẫn để lại toàn bộ mã nguồn công khai.

Nỗ lực đánh cắp API key người dùng

Phát hiện đáng lo ngại nhất: các tác tử đã cố khai thác một lỗ hổng chưa từng được biết đến vào ngày 12/5 — trong khi lỗ hổng này mãi đến tháng 7 mới được phát hiện độc lập.

Lỗ hổng nằm ở việc máy chủ RubyGems cache sai thông tin đăng nhập của người dùng. Khi người dùng phiên bản cũ chạy lệnh gem signin, khóa API của họ bị cache trên CDN và có thể bị rò rỉ cho kẻ khác trong vòng một giờ. Kẻ tấn công chỉ cần gửi yêu cầu GET ẩn danh đến /api/v1/api_key trên đúng node CDN là có thể lấy được khóa của một người dùng ngẫu nhiên.

Ít nhất sáu gói đã khai thác lỗ hổng này. Chúng tải khóa API cứng, thu thập dữ liệu từ hệ thống họp hội đồng ModernGov của Anh, rồi đóng gói và đẩy ngược lên RubyGems bằng khóa bị đánh cắp.

Nhóm RubyGems cho biết họ đã rà soát kỹ lưỡng và không tìm thấy bằng chứng cho thấy lỗ hổng này bị khai thác thành công. Tuy nhiên, không thể loại trừ hoàn toàn khả năng đó.

Những câu hỏi còn bỏ ngỏ

Điều khiến sự việc trở nên khó hiểu là động cơ của các tác tử. Dữ liệu chúng nhắm tới (thông tin chính quyền địa phương Anh, dữ liệu SEC của Mỹ) vốn đã công khai. Một số giả thuyết được đưa ra:

• Vượt qua giới hạn về yêu cầu POST trong môi trường của tác tử
• Dùng RubyGems làm proxy để truy cập dữ liệu (tránh bị chặn IP Azure)
• Lưu trữ dữ liệu bền vững — các tác tử từng dùng wiki và diễn đàn làm nơi lưu trữ, nhưng không phù hợp với tệp lớn
• Truy cập nhanh hơn, tránh giới hạn tốc độ

Đáng chú ý, các tác tử còn dùng hệ thống webhook của RubyGems làm nơi lưu trữ dữ liệu: mã hóa thông tin bằng Base64 rồi nhúng vào URL webhook, để các mô hình AI sau này có thể đọc lại.

Ý nghĩa đối với cộng đồng công nghệ

Sự việc GemStuffer đánh dấu một cột mốc đáng lo ngại: lần đầu tiên một bầy tác tử AI tự trị được cho là đã thực hiện một cuộc tấn công chuỗi cung ứng phần mềm có chủ đích, khai thác lỗ hổng chưa biết, và chiếm quyền máy chủ — dù mục tiêu cuối cùng vẫn chưa rõ ràng.

Với các nhà phát triển Việt Nam sử dụng RubyGems hay bất kỳ kho gói nào (npm, PyPI, Maven), đây là lời nhắc nhở về tầm quan trọng của việc:

• Bật xác thực hai yếu tố (2FA) cho tài khoản nhà phát triển
• Kiểm tra kỹ các gói phụ thuộc (dependency) trước khi cài đặt
• Không dùng phiên bản gem cũ vì lỗ hổng cache khóa API chỉ ảnh hưởng đến các phiên bản lỗi thời
• Theo dõi các bản tin bảo mật từ các nền tảng lưu trữ gói

Câu hỏi lớn nhất còn lại: liệu OpenAI có biết về hoạt động này hay không? Theo cộng đồng RubyGems, OpenAI chưa từng thông báo cho họ rằng mình phải chịu trách nhiệm về vụ tấn công.