GitHub Action `tj-actions/changed-files` bị xâm nhập - đang được 23.000 repo sử dụng

• Đây là một GitHub Action phổ biến dùng để theo dõi thay đổi giữa các nhánh, và đã xảy ra nỗ lực làm lộ secret CI/CD thông qua một commit bị xâm nhập
• 23.000 repo bị ảnh hưởng, GitHub đã gỡ action này và hiện không thể tiếp tục sử dụng
• Cần thay bằng action khác và kiểm tra vì có khả năng secret đã bị lộ trong log workflow công khai, sau đó bắt buộc phải xoay vòng khóa
• Harden-Runner của StepSecurity đã phát hiện sự việc, và họ đang phát hành miễn phí action thay thế được tăng cường bảo mật step-security/changed-files

Tóm tắt sự cố

• tj-actions/changed-files đang được sử dụng trong hơn 23.000 kho lưu trữ và đã bị xâm nhập
  • Kẻ tấn công đã sửa mã của action và trỏ lại các thẻ phiên bản tới commit độc hại
  • Điều này khiến secret CI/CD bị in ra trong log build của GitHub Actions
• Có khả năng secret đã bị lộ trong các log workflow công khai
• Vấn đề được phát hiện sau khi Harden-Runner phát hiện một endpoint bất thường
• Một script Python độc hại khiến secret bị dump từ tiến trình Runner Worker
• Tất cả các thẻ đều bị trỏ tới cùng một mã băm commit độc hại (0e58ed8671d6b60d0890c21b07f8835ace038e67)

Biện pháp ứng phó của GitHub

• GitHub đã gỡ action tj-actions/changed-files và ngừng cho phép sử dụng
• CVE chính thức là CVE-2025-30066

Cách khắc phục

• 1. Sử dụng action thay thế an toàn do StepSecurity cung cấp

  • Thay tj-actions/changed-files bằng step-security/changed-files@v45

• 2. Gỡ mọi tham chiếu tới tj-actions/changed-files

  • Tìm và xóa các tham chiếu tới tj-actions/changed-files trong codebase:

    git grep -l "tj-actions/changed-files"  
    

• 3. Kiểm tra log chạy workflow của GitHub Actions

  • Cần kiểm tra log các lần chạy gần đây để xác minh secret có bị rò rỉ hay không
  • Nếu phát hiện secret bị lộ, cần xoay vòng (đặt lại) ngay lập tức

• 4. Thiết lập danh sách cho phép cho GitHub Actions

• Cấu hình danh sách cho phép để chỉ chạy các GitHub Action đáng tin cậy:
  • Có thể thiết lập trong phần cài đặt của GitHub:
    • Settings → Actions → Allow select actions

• 5. Thiết lập StepSecurity Harden-Runner

  • Có thể cấu hình Harden-Runner để giám sát lưu lượng mạng và quá trình chạy workflow

Các bước tiếp theo

• Đã báo cáo sự cố cho GitHub → GitHub issue: #2463
• Kho lưu trữ tj-actions/changed-files đã bị xóa
• Đã được đăng ký chính thức với mã CVE-2025-30066
• Có thể phát hiện và ngăn chặn các vấn đề bảo mật tương tự thông qua StepSecurity Harden-Runner
• Khuyến nghị cấu hình Harden-Runner để tăng cường trạng thái bảo mật và thực hiện giám sát theo thời gian thực

[dl57934]

Tối qua còn không hoạt động, giờ lại được rồi.

[GN⁺]

Ý kiến trên Hacker News

• Tác giả và người bảo trì của Renovate giải thích kịch bản tấn công

  • Kẻ tấn công đã có quyền ghi vào kho lưu trữ tj-actions/changed-files
  • Kẻ tấn công đã giả mạo commit của Renovate để ngụy trang thành commit gần đây
  • Việc giả mạo này không nhằm lừa pull request mà chỉ đơn giản là để gây nhầm lẫn
  • Commit được hiển thị là Unverified, và đa số mọi người không ép buộc chỉ chấp nhận commit đã ký
  • Renovate Bot thực sự đề xuất PR để cập nhật các dependency
  • Một số người đã bật tự động hợp nhất, nhưng đây không phải cấu hình mặc định
  • Sự việc này nhắc lại rằng nhiều người đã lầm tưởng git tag là bất biến

• Trong vài năm gần đây, niềm tin vào dependency và extension của bên thứ ba đang giảm dần

  • Nếu một gói npm có quá nhiều dependency thì sẽ không cài đặt
  • Không cài extension cho vscode hay chrome
  • Thường xuyên có trường hợp mã độc bị thêm vào hoặc giấy phép bị thay đổi
  • Nhìn vào cây dependency của eslint thì khó mà tin tưởng tất cả mọi thứ

• Kho lưu trữ đã hoạt động trở lại và nhà phát triển đã đưa ra giải thích

  • Cuộc tấn công bắt nguồn từ token PAT của tài khoản @tj-actions-bot
  • Bảo mật tài khoản đã được tăng cường, và GitHub đã thu hồi PAT bị xâm phạm

• Điều tra github_events trong Clickhouse để xác định tài khoản được dùng trong cuộc tấn công

  • Các tài khoản "2ft2dKo28UazTZ", "mmvojwip" bị nghi ngờ

• Thật đáng sốc khi cách chạy CI/CD lại là liệt kê các kho lưu trữ ngẫu nhiên trên GitHub

  • Vấn đề trở nên nghiêm trọng hơn do sự gia tăng của các LLM
  • Những tác vụ quan trọng nên được chạy thủ công

• Đồng sáng lập của StepSecurity giải thích cách phát hiện sự cố bảo mật

  • Harden-Runner đã phát hiện dấu hiệu bất thường bằng cách giám sát các lệnh gọi mạng trong workflow GitHub Actions

• Vấn đề nằm ở cách sử dụng GitHub Actions mặc định là dùng git tag không bất biến

  • Thuật toán băm SHA-1 có thể gây va chạm, nên cần hỗ trợ SHA-256

• GitHub Actions bất biến sẽ sớm được đưa vào

  • Có thể fork Actions hoặc sử dụng commit hash

• Dự án maven-lockfile giải thích PR đã được tự động hợp nhất

  • Renovate Bot thật đã tự động hợp nhất commit của Renovate Bot giả

• GitHub Actions nên dùng lockfile cho dependency

  • Ký pháp Semver là một giải pháp tốt để xử lý vấn đề