Nửa triệu thông tin đăng nhập còn hoạt động bị phơi bày trên GitHub

Truffle Security vừa công bố một phát hiện gây chấn động giới bảo mật: hơn 1,1 triệu thông tin đăng nhập (credentials) bị lộ trong các kho lưu trữ công khai trên GitHub, trong đó 543.699 vẫn còn hiệu lực tính đến thời điểm kiểm tra. Câu chuyện không chỉ nằm ở việc rò rỉ, mà ở chỗ các biện pháp bảo vệ hiện có dường như vẫn chưa đủ để ngăn chặn hậu quả.

Thông tin đăng nhập bị đánh cắp

Con số biết nói từ 224 triệu kho lưu trữ

Theo báo cáo của Truffle Security, nhóm nghiên cứu đã quét 224 triệu kho lưu trữ công khai trên GitHub vào tháng 8 năm 2025 và phát hiện tổng cộng 1.103.438 thông tin đăng nhập bị phơi bày.

Đến cuối tháng 7 năm 2026, công ty bảo mật này đã thử nghiệm các thông tin đăng nhập đó với chính các dịch vụ phát hành chúng. Kết quả gây sốc: 543.699 bộ vẫn còn hoạt động, tức là kẻ tấn công hoàn toàn có thể sử dụng chúng để truy cập vào hệ thống của nạn nhân.

Trường hợp lâu đời nhất là một khóa AWS được commit từ năm 2009 và chưa từng được thay đổi kể từ đó. Khoảng thời gian phơi bày trung bình lên tới 784 ngày — hơn hai năm một thông tin đăng nhập nằm công khai mà không ai xử lý.

"2.636 thông tin đăng nhập còn sống đến từ các tệp được sửa đổi lần cuối trước năm 2015. Một phần tư trong số mọi thứ chúng tôi tìm thấy đã tồn tại hơn bốn năm," Truffle Security nhấn mạnh.

Nghịch lý: Càng bảo vệ, càng rò rỉ

Điều đáng lo ngại nhất không nằm ở những thông tin đăng nhập cũ, mà ở những thông tin được đẩy lên sau khi GitHub đã bật cảnh báo miễn phí và biện pháp bảo vệ push mặc định nhằm ngăn chặn rò rỉ vô ý.

Cụ thể, theo thống kê của Truffle:

• 245.959 thông tin tồn tại trước khi GitHub cung cấp cảnh báo miễn phí.
• 97.897 thông tin xuất hiện trong giai đoạn quét miễn phí và bảo vệ push chỉ cần bật một thiết lập.
• 199.843 thông tin xuất hiện sau khi biện pháp chặn trở thành mặc định, và vẫn đang phản hồi với nhà cung cấp hơn hai năm sau đó.

Nói cách khác, việc ngăn chặn thông tin đăng nhập bị push lên GitHub không đồng nghĩa với việc chúng bị vô hiệu hóa. GitHub có chạy một chương trình quét bí mật (secret-scanning) gửi các token bị lộ tới nhà cung cấp để thu hồi, nhưng chương trình này không bắt buộc đối tác phải thu hồi các bí mật được phát hiện. Đây chính là lý do khiến số lượng lớn thông tin đăng nhập vẫn còn hiệu lực.

Những dịch vụ bị ảnh hưởng nhiều nhất

Danh sách các bí mật bị phơi bày bị chi phối bởi một số loại thông tin đăng nhập phổ biến:

• 69.041 thông tin tài khoản dịch vụ Google Cloud (service account credentials)
• 51.067 chuỗi kết nối MongoDB (connection strings)
• 33.343 khóa API Google còn hoạt động

Theo Truffle, các thông tin đăng nhập này vẫn còn hiệu lực không phải vì việc phơi bày không bị ngăn chặn, mà vì chúng không bị thu hồi. Nhiều nhà cung cấp dịch vụ có thể không có quy trình tự động để vô hiệu hóa các token bị rò rỉ.

Biểu tượng bảo mật

Bài học cho doanh nghiệp và lập trình viên

Truffle Security kết luận bằng một nhận định đáng suy ngẫm:

"Bảo vệ push là một biện pháp kiểm soát tốt và ngăn chặn bí mật ngay từ cửa. Nó không có gì để nói về 543.699 bí mật đã ở bên trong, và nó chưa bao giờ được thiết kế để làm điều đó. Cảnh báo có bao phủ lịch sử, nhưng chỉ ở nơi chủ sở hữu đã bật chúng, đọc chúng, rồi đi xoay khóa."

Đối với các nhà phát triển và doanh nghiệp tại Việt Nam — đặc biệt là các startup đang vận hành hạ tầng trên cloud và sử dụng GitHub làm nền tảng chính — câu chuyện này là lời cảnh tỉnh quan trọng:

• Không bao giờ commit khóa API, mật khẩu hay token trực tiếp vào mã nguồn, kể cả trong kho lưu trữ riêng tư.
• Bật tính năng bảo vệ push và quét bí mật trên mọi kho lưu trữ, không chỉ những kho quan trọng.
• Thường xuyên xoay vòng (rotate) khóa định kỳ, đặc biệt sau khi có bất kỳ dấu hiệu rò rỉ nào.
• Sử dụng trình quản lý bí mật như HashiCorp Vault, AWS Secrets Manager hay Google Secret Manager thay vì lưu trong mã nguồn.
• Thiết lập quy trình thu hồi tự động khi phát hiện thông tin đăng nhập bị lộ, không chỉ dừng ở việc xóa commit.

Sự việc lần này cho thấy một thực tế phũ phàng: ngay cả khi các nền tảng lớn như GitHub đã triển khai các biện pháp bảo vệ mặc định, trách nhiệm cuối cùng vẫn thuộc về chính đội ngũ phát triển. Phát hiện rò rỉ chỉ là bước đầu — điều quan trọng là phải vô hiệu hóa ngay lập tức những gì đã bị phơi bày.