GitHub Actions leaking secrets when Miri output is cached

Bài tóm tắt Rust 2026 2. Tăng trưởng Độ khó: Trung bình

Rust · 2026 · 2. Tăng trưởng · Độ khó: Trung bình — bài gốc

Thông báo bảo mật ngắn của Rust Security Response Team; bài báo lỗi do một kỹ sư OpenAI gửi.

Bối cảnh

  • GitHub Actions cho cache thư mục giữa các lần chạy. Cấu hình thường gặp: CI trên main được ghi cache, PR chỉ được đọc (để chống đầu độc cache). Dự án Rust hay cache target/ và binary từ cargo install để CI nhanh hơn.
  • cargo miri cần nhớ biến môi trường liên quan tới build giữa các lần chạy, và cách làm hiện tại là ghi toàn bộ biến môi trường vào target/.

Vấn đề

  • Nếu job chạy Miri có secret trong biến môi trường (truyền cho step, đặt ở env của workflow, hay step trước để lại) và target/ được cache, thì secret nằm trong cache. Ai từng có một thay đổi được merge đều có thể mở PR, CI của PR đọc cache và trích secret ra, rồi đẩy commit thứ hai để xoá dấu vết (GitHub có lúc ẩn commit bị ghi đè, log CI bị xoá sau vài tháng). GitHub chỉ đòi duyệt cho PR đầu tiên của một người.

Thay đổi chính

  • Sửa ngắn hạn: Miri chỉ giữ biến CARGO_* (trừ CARGO_*_TOKEN) và OUT_DIR. Quét hệ sinh thái trên GitHub: 1 repo bị ảnh hưởng, 7 repo nên thận trọng, đã liên hệ.
  • Khuyến nghị: tắt cache cho job đó, hoặc chỉ cấp secret cho các step không gọi Miri; xoá cache và xoay vòng secret có thể đã lộ.

Vì sao

  • Theo Rust: nhiều công cụ không xử lý secret riêng mà mặc định cả môi trường có thể ghi xuống đĩa; Cargo/Miri/Rust không bảo đảm biến môi trường không bị chép vào target/, kể cả build script của bên thứ ba. Cache dễ bị nhiễm secret là cách làm tệ.

Bài học cho SWE

  • Cache của CI là dữ liệu chia sẻ giữa các mức tin cậy khác nhau (main ghi, PR đọc); job ghi vào cache công khai không được thấy secret.
  • Cấp secret theo step chứ không theo cả job hay cả workflow.
  • Đây là chiều ngược của bài toán cache CI: thứ lọt vào input không chỉ phá khoá cache mà còn mang secret theo.

Liên quan