lỗ hổng bảo mật trong Composer đã làm rò rỉ GitHub authentication tokens vào log CI công khai, tạo ra rủi ro bảo mật đáng kể cho các dự án PHP chạy trong GitHub Actions. Sự cố này xuất phát từ cách Composer xử lý một định dạng token mới do GitHub triển khai trong giai đoạn cuối tháng 4/2026.
Nguyên nhân gây ra lỗ hổng bảo mật
GitHub âm thầm đưa ra một định dạng token mới cho dịch vụ GitHub Actions. Điểm thay đổi là token chứa dấu gạch ngang (-), trong khi logic kiểm tra nội bộ của Composer không được thiết kế để chấp nhận ký tự này.
Khi Composer gặp token theo định dạng mới, nó từ chối token và in nguyên giá trị token vào log của Actions như một phần của thông báo lỗi tiêu chuẩn. Điều này khiến bất kỳ ai có quyền truy cập log đều có thể đọc được credential mà không cần kỹ thuật khai thác phức tạp.
Lỗ hổng bảo mật ảnh hưởng đến workflow CI như thế nào
Vấn đề này đặc biệt nguy hiểm trong các workflow phổ biến của GitHub Actions. Nhiều dự án PHP sử dụng các helper như shivammathur/setup-php, công cụ này tự động đưa GITHUB_TOKEN vào cấu hình xác thực toàn cục của Composer.
Nếu token trùng với định dạng mới trong thời gian rollout, Composer sẽ từ chối token và làm lộ toàn bộ chuỗi bí mật ngay trong log. Người vận hành workflow thường không nhận được cảnh báo rõ ràng nào ở thời điểm sự cố xảy ra.
Hướng dẫn kỹ thuật để nhận diện phạm vi ảnh hưởng
Nhà nghiên cứu từ Socket.dev đã công bố phân tích về mức độ nghiêm trọng của sự cố này. Tham khảo thêm tại nguồn gốc mô tả kỹ thuật: Socket.dev.
Điểm đáng chú ý là đây không phải lỗi biên hiếm gặp. Đây là một lỗ hổng bảo mật có thể ảnh hưởng đến bất kỳ dự án PHP nào chạy Composer trong GitHub Actions, đặc biệt khi workflow tự động đăng ký token vào lớp xác thực của Composer.
Trạng thái khắc phục và bản vá bảo mật
GitHub đã tạm thời rollback định dạng token mới, giúp giảm nguy cơ phát sinh rò rỉ mới trong thời điểm hiện tại. Tuy nhiên, việc rollback không xóa được các token đã từng xuất hiện trong log trước đó.
Packagist đã phát hành bản vá chính thức cho Composer. Các phiên bản đã được sửa gồm:
- Composer 2.9.8
- Composer 2.2.28 LTS
- Composer 1.10.28
Khuyến nghị cập nhật ngay lên một trong ba phiên bản này. Tham khảo thêm thông tin phát hành và kiểm tra trạng thái bản ghi tại NVD hoặc kho mã nguồn chính thức của Composer khi có bản cập nhật tương ứng.
Cách bản vá bảo mật hoạt động
Bản sửa đổi thực hiện hai thay đổi chính. Thứ nhất, Composer loại bỏ hoàn toàn giá trị token bị từ chối khỏi output lỗi. Thứ hai, logic kiểm tra token được nới lỏng để không phụ thuộc vào một mẫu ký tự cố định.
Điều này giúp Composer trở nên bền vững hơn trước thay đổi định dạng token từ nền tảng bên ngoài. Với các công cụ xử lý secret, token nên được xem là chuỗi bất định hình, không nên giả định về độ dài, cấu trúc hay bộ ký tự.
Ảnh hưởng hệ thống và nguy cơ bảo mật thực tế
Packagist.org không bị ảnh hưởng trực tiếp vì registry công khai này không dùng GitHub App installation tokens theo cách đó. Private Packagist cũng đã áp dụng bản sửa và rà soát nhật ký cập nhật nội bộ, không ghi nhận token bị lộ trong dữ liệu đã lưu.
Tuy vậy, nguy cơ vẫn hiện hữu với bất kỳ dự án nào chạy Composer bên trong GitHub Actions, nhất là khi helper setup tự động ghi GITHUB_TOKEN vào lớp xác thực của Composer. Đây là tình huống điển hình của lỗ hổng bảo mật trong chuỗi cung ứng phần mềm và quy trình CI/CD.
Hành động cần thực hiện ngay để giảm rủi ro bảo mật
Trước tiên, cần cập nhật Composer lên một trong các phiên bản đã được vá. Sau đó, rà soát lại các log gần đây của GitHub Actions, đặc biệt những lần chạy Composer thất bại có thể đã in token ra output.
Nếu phát hiện dòng log chứa credential, cần xóa hoặc hạn chế quyền truy cập vào log đó để giảm tiếp xúc. Token nào được cho là đã lộ phải được xem là compromised và cần xoay vòng ngay lập tức.
Token do GitHub-hosted runner phát hành thường hết hạn khi job kết thúc hoặc sau khoảng 6 giờ. Với self-hosted runner, token có thể còn hiệu lực tới 24 giờ. Vì vậy, việc đánh giá mức độ phơi bày phải dựa trên thời điểm log bị lộ và thời gian sống của token.
Hướng dẫn kiểm tra log và xác minh sự cố
Khi điều tra sự cố, cần tìm các dấu hiệu token bị in ra dưới dạng lỗi Composer trong workflow CI. Các bước kiểm tra nên tập trung vào:
- Những lần chạy GitHub Actions thất bại trong giai đoạn rollout token mới.
- Các log chứa lỗi xác thực của Composer kèm chuỗi token đầy đủ.
- Các workflow dùng shivammathur/setup-php hoặc helper tương tự.
- Các tài khoản hoặc kho mã đã dùng GITHUB_TOKEN trong cấu hình tự động.
Mẫu CLI kiểm tra phiên bản Composer
composer --version
Mẫu CLI cập nhật Composer
composer self-update 2.9.8
composer self-update 2.2.28
composer self-update 1.10.28
Mẫu kiểm tra nhanh log CI
grep -R "Composer" .github/workflows/
grep -R "GITHUB_TOKEN" .github/workflows/
Trong quá trình khắc phục, cần đảm bảo các workflow không tiếp tục tái sử dụng token cũ trong log hoặc artifact. Khi phát hiện chuỗi bí mật đã từng xuất hiện, nên áp dụng xoay vòng credential và cập nhật bản vá bảo mật đồng thời để giảm nguy cơ bảo mật cho các lần chạy tiếp theo.
Điểm kỹ thuật cần lưu ý
Sự cố này không liên quan đến thực thi mã từ xa hay khai thác phức tạp, nhưng vẫn là một lỗ hổng bảo mật nghiêm trọng vì làm lộ bí mật xác thực trong môi trường CI công khai. Rủi ro nằm ở việc token được ghi thẳng vào log, nơi quyền truy cập thường rộng hơn so với phạm vi dự kiến của secret.
Cách xử lý đúng là vá Composer, kiểm tra toàn bộ log gần đây, đánh giá thời gian sống của token, và xoay vòng mọi credential nghi ngờ đã bị phơi bày. Với các hệ thống tự động hóa phần mềm, đây là lớp rủi ro bảo mật cần được theo dõi như một phần của quy trình an toàn thông tin và bản vá bảo mật.
