CVE-2026-66066 là lỗ hổng nghiêm trọng trong Active Storage của Ruby on Rails, liên quan đến cách ứng dụng xử lý ảnh tải lên bằng libvips. Vấn đề đáng chú ý không nằm ở một biểu mẫu upload đơn lẻ, mà ở ranh giới tin cậy giữa tệp do người dùng gửi lên, bộ xử lý ảnh và các bí mật đang nằm trong môi trường chạy ứng dụng.
The Hacker News dẫn thông tin từ Rails Security Team, Ethiack và GMO Flatt Security cho biết lỗ hổng có điểm CVSS 9.5, có thể cho phép kẻ tấn công chưa xác thực đọc tệp tùy ý trên máy chủ ứng dụng trong một số điều kiện. Nếu các tệp hoặc biến môi trường bị đọc chứa secret_key_base, khóa master, mật khẩu cơ sở dữ liệu, token dịch vụ đám mây hoặc API key, rủi ro có thể mở rộng thành chiếm quyền phiên, thực thi mã từ xa hoặc di chuyển ngang sang hệ thống khác.
Lỗ hổng xảy ra ở đâu?
Active Storage là cơ chế tích hợp của Rails để quản lý tệp đính kèm, ảnh đại diện, ảnh sản phẩm, ảnh hồ sơ và các biến thể ảnh như thumbnail hoặc bản resize. Từ Rails 7 trở lên, nhiều cấu hình mặc định sử dụng Vips làm bộ xử lý ảnh. Vips lại dựa trên libvips, một thư viện mạnh để đọc, biến đổi và ghi nhiều định dạng tệp.
Điểm yếu xuất hiện khi một ứng dụng Rails dùng libvips để xử lý ảnh từ nguồn không tin cậy. Theo advisory chính thức của Rails, libvips có những operation hoặc loader được đánh dấu là không phù hợp với nội dung thù địch. Active Storage trước bản vá chưa chặn đầy đủ các operation này, khiến tệp được tạo có chủ đích có thể kích hoạt đường xử lý ngoài kỳ vọng và dẫn tới đọc tệp mà tiến trình Rails có quyền truy cập.
Điều kiện để bị ảnh hưởng
Không phải mọi website Rails đều tự động bị khai thác. Một ứng dụng thường chỉ nằm trong vùng rủi ro khi đồng thời sử dụng Active Storage với libvips, chấp nhận ảnh từ người dùng không tin cậy và chạy phiên bản Active Storage/libvips thuộc phạm vi bị ảnh hưởng. Rails 7.0.0 đến 7.2.3.1, Rails 8.0.0 đến 8.0.5 và Rails 8.1.0 đến 8.1.3 được nêu là các nhánh cần nâng cấp. Rails 6.x chỉ liên quan khi hệ thống đã cấu hình Active Storage dùng Vips thay vì mặc định cũ.
Điểm quan trọng là tính năng tạo biến thể ảnh không nhất thiết phải được phơi bày như một endpoint riêng. Trong nhiều ứng dụng thực tế, chỉ cần có avatar, ảnh hồ sơ, ảnh sản phẩm, ảnh bài đăng hoặc direct upload được xử lý lại để hiển thị, chuỗi xử lý ảnh đã có thể tồn tại trong luồng nghiệp vụ bình thường.
Vì sao đọc tệp có thể dẫn tới hậu quả lớn?
Đọc tệp tùy ý đôi khi bị xem nhẹ vì chưa phải là thực thi mã trực tiếp. Với ứng dụng web hiện đại, nhận định này rất nguy hiểm. Nhiều bí mật vận hành được đặt trong biến môi trường hoặc tệp cấu hình: khóa ký cookie, khóa giải mã credentials, mật khẩu cơ sở dữ liệu, token S3/GCS/Azure, webhook secret, API key thanh toán hoặc token hệ thống giám sát.
Khi những bí mật này bị lộ, kẻ tấn công có thể ký cookie hợp lệ, truy cập kho lưu trữ tệp, đọc dữ liệu trong cơ sở dữ liệu, giả mạo luồng tích hợp hoặc dùng quyền của ứng dụng để mở rộng sang dịch vụ nội bộ. Vì vậy, bản vá chỉ là bước đầu; các tổ chức cần giả định bí mật có thể đã bị đọc nếu ứng dụng nằm trong phạm vi ảnh hưởng và đã tiếp xúc với tệp upload không tin cậy.
Cách giảm rủi ro
Rails khuyến nghị nâng cấp lên các bản đã vá: Rails 7.2.3.2, 8.0.5.1 hoặc 8.1.3.1, đồng thời bảo đảm libvips đạt phiên bản 8.13 trở lên. Với môi trường chưa thể nâng cấp Rails ngay, một biện pháp tạm thời là bật VIPS_BLOCK_UNTRUSTED nếu libvips đủ mới, hoặc gọi Vips.block_untrusted(true) khi dùng ruby-vips 2.2.1 trở lên. Nếu libvips cũ hơn 8.13, Rails cho biết không có workaround đầy đủ ngoài việc nâng cấp hoặc loại bỏ phụ thuộc libvips trong ứng dụng.
Sau khi vá, đội vận hành nên xoay vòng secret_key_base, master key, database credential, khóa dịch vụ lưu trữ ảnh và token bên thứ ba mà tiến trình Rails có thể đọc. Cần lưu ý việc đổi secret_key_base có thể làm hết hiệu lực cookie, phiên đăng nhập và URL được ký, nên phải chuẩn bị kế hoạch truyền thông và cửa sổ triển khai phù hợp.
Bài học cho đội phát triển
CVE-2026-66066 nhắc lại một nguyên tắc căn bản: upload ảnh không phải là chức năng ít rủi ro. Tệp ảnh có thể là đầu vào phức tạp, được xử lý bởi nhiều thư viện native và parser định dạng. Những thư viện này thường có bề mặt tấn công rộng hơn so với phần biểu mẫu mà người dùng nhìn thấy.
Đối với các ứng dụng cho phép người dùng tải tệp lên, đội phát triển nên tách quyền xử lý ảnh khỏi quyền đọc bí mật, giới hạn quyền filesystem của worker, kiểm soát định dạng được phép, đặt giới hạn kích thước, quét nội dung đầu vào và giám sát bất thường quanh các endpoint upload. Những biện pháp này không thay thế bản vá, nhưng giúp giảm thiệt hại khi một thư viện xử lý tệp xuất hiện lỗ hổng mới.
Trong ngắn hạn, quản trị viên Rails nên kiểm kê ứng dụng có Active Storage, xác định nơi nào dùng Vips, cập nhật dependency, xoay vòng bí mật và theo dõi log liên quan đến upload hoặc xử lý biến thể ảnh. Với các hệ thống internet-facing có upload công khai, ưu tiên xử lý nên được đặt ở mức cao.
VNCyberS tổng hợp từ The Hacker News, Ruby on Rails Security Advisory và Ethiack
Tiếng Việt
English