GitHub bị tố phớt lờ phần mềm độc hại giả mạo suốt 3 tuần
Một lập trình viên phát hiện phần mềm của mình bị giả mạo trên GitHub kèm mã độc, nhưng phải chờ tới 23 ngày không có phản hồi. Sự việc chỉ được xử lý ngay sau khi bài viết leo lên trang nhất Hacker News, dấy lên lo ngại về quy trình kiểm duyệt của nền tảng.

GitHub bị tố phớt lờ phần mềm độc hại giả mạo suốt 3 tuần
Một lập trình viên phát hiện phần mềm của mình bị giả mạo trên GitHub, kèm theo mã độc được cài cắm tinh vi. Anh đã báo cáo vi phạm nhưng không nhận được phản hồi nào trong suốt 23 ngày. Sự việc chỉ được giải quyết khoảng 10 phút sau khi bài viết của anh lọt lên trang nhất Hacker News.
Phát hiện giả mạo từ email của khách hàng
Vào ngày 31 tháng 8, tác giả của phần mềm xử lý dữ liệu Easy Data Transform nhận được email từ một khách hàng, thông báo rằng họ tìm thấy một bản sao chép trái phép của sản phẩm này trên GitHub.
Kho lưu trữ giả mạo trên GitHub
Kho lưu trữ giả mạo này sử dụng đúng tên sản phẩm và logo của anh mà không hề xin phép. Ngay trong ngày phát hiện, anh đã gửi báo cáo lên GitHub với cáo buộc đây là hành vi giả mạo.
GitHub đã gửi lại một email phản hồi tự động. Tưởng chừng sự việc sẽ sớm được xử lý, nhưng mọi chuyện lại diễn ra theo chiều hướng khác.
Mã độc ẩn trong tệp cài đặt macOS
Một đồng nghiệp của tác giả đã quét tệp .dmg dành cho Mac lấy từ kho lưu trữ giả mạo bằng virustotal.com và phát hiện hàng loạt cảnh báo mã độc.
Kết quả quét mã độc trên VirusTotal
Đáng chú ý hơn, khi dùng công cụ Isobuster để kiểm tra sâu bên trong tệp .dmg, họ phát hiện kẻ tấn công đã thay đổi cả ảnh nền của tệp cài đặt. Hình nền mới này có nội dung dụ người dùng bỏ qua mọi cảnh báo về mã độc.
Đây là thủ đoạn ngày càng phổ biến của tội phạm mạng: lợi dụng lòng tin vào các nền tảng như GitHub để phát tán mã độc tới người dùng cuối.
Ngày 10 tháng 9, tác giả gửi bổ sung toàn bộ thông tin mới này cho bộ phận hỗ trợ GitHub, hy vọng sự việc sẽ được xử lý nhanh chóng hơn.
23 ngày im lặng đáng báo động
Tính đến ngày 23 tháng 9, tác giả vẫn không nhận được bất kỳ phản hồi nào từ GitHub ngoài email tự động ban đầu. Tổng cộng 23 ngày không có tiếng nói nào từ bộ phận hỗ trợ.
Anh không giấu được sự bức xúc khi cho rằng đây là chất lượng hỗ trợ quá kém. Trong bài viết của mình, anh đặt câu hỏi liệu có nên gửi yêu cầu gỡ bỏ theo Đạo luật Bản quyền Thiên niên kỷ số (DMCA) tới GitHub hay không.
Tác giả cũng thẳng thắn chia sẻ góc nhìn thực tế: những người tải tệp .dmg giả mạo phần lớn là nhằm né việc trả phí bản quyền cho Easy Data Transform. Anh không mấy thông cảm nếu máy tính của họ bị xâm nhập, nhưng anh thực sự không muốn kẻ xấu trục lợi từ công sức của mình.
Anh cũng đưa ra lời khuyên quan trọng cho người dùng: luôn tải phần mềm trực tiếp từ nhà phát triển, bất cứ khi nào có thể.
Chỉ được xử lý khi lên trang nhất Hacker News
Phần cập nhật vào ngày 24 tháng 9 năm 2026 cho thấy GitHub cuối cùng đã gỡ bỏ trang vi phạm, chỉ khoảng 10 phút sau khi bài viết xuất hiện trên trang nhất Hacker News.
Tác giả mỉa mai rằng đây chắc chắn chỉ là "sự trùng hợp ngẫu nhiên".
Bài học rút ra: nếu bạn muốn nhận được sự hỗ trợ cơ bản nhất từ GitHub, bạn cần phải lọt lên trang nhất Hacker News.
Và điều này cho thấy GitHub hoàn toàn có thể xử lý rất nhanh — khi họ thực sự muốn.
Hệ quả cho cộng đồng mã nguồn mở tại Việt Nam
Sự việc này là lời cảnh tỉnh cho cả cộng đồng lập trình viên lẫn người dùng phần mềm, đặc biệt tại Việt Nam — nơi thói quen tải phần mềm từ các nguồn không chính thống, các repository chia sẻ "bản quyền miễn phí" vẫn còn khá phổ biến.
- Luôn đối chiếu tên miền, tên tác giả và logo khi tải phần mềm từ GitHub hay bất kỳ nền tảng mã nguồn nào.
- Ưu tiên tải xuống từ trang chủ chính thức của nhà phát triển thay vì các kho lưu trữ trung gian.
- Quét tệp cài đặt bằng công cụ bảo mật uy tín trước khi khởi chạy.
- Cảnh giác với các tệp cài đặt có cảnh báo bảo mật bị "hướng dẫn" bỏ qua — đây là dấu hiệu điển hình của mã độc.
Ngoài ra, sự việc cũng đặt ra câu hỏi lớn về trách nhiệm của các nền tảng lưu trữ mã nguồn trong việc xử lý báo cáo vi phạm. Khi quy trình kiểm duyệt phụ thuộc vào áp lực truyền thông thay vì quy trình nội bộ minh bạch và kịp thời, chính những nhà phát triển chân chính và người dùng cuối là người chịu thiệt hại.