Duy Linh
Writer
Tranh chấp quyền quản trị trong thư viện Go fsnotify được sử dụng rộng rãi đã làm dấy lên lo ngại về an ninh chuỗi cung ứng sau khi một số người đóng góp bị loại khỏi tổ chức GitHub của dự án và các bản phát hành mới bị đưa vào diện xem xét kỹ lưỡng.
Dù chưa có bằng chứng cho thấy bất kỳ phiên bản nào của fsnotify bị xâm phạm, vụ việc cho thấy sự thiếu minh bạch trong quản trị các dự án mã nguồn mở quan trọng có thể nhanh chóng tạo ra lo ngại trên toàn bộ hệ sinh thái phần mềm.
fsnotify là thư viện thông báo hệ thống tập tin đa nền tảng, hỗ trợ Windows, Linux, macOS, BSD và illumos. Với hơn 10.000 lượt đánh dấu sao trên GitHub cùng hơn 300.000 dự án phụ thuộc, thư viện này đóng vai trò quan trọng trong nhiều công cụ dành cho nhà phát triển, tiện ích dòng lệnh và quy trình hạ tầng.
Chính vì mức độ phổ biến lớn, chỉ cần xuất hiện nghi vấn liên quan đến quyền kiểm soát người bảo trì hoặc quyền phát hành cũng có thể tạo hiệu ứng lan rộng trong chuỗi cung ứng phần mềm.
Trong một bài đăng trên mạng xã hội sau đó đã bị xóa, ông cho rằng xung đột nội bộ khiến một số người đóng góp mất quyền truy cập, làm dấy lên lo ngại về khả năng dự án bị thâu tóm.
Người bảo trì bị loại bỏ đã báo động sau khi mất quyền truy cập (Nguồn: Socket).
Những tuyên bố này nhanh chóng thúc đẩy các cuộc thảo luận trên GitHub khi cộng đồng tìm kiếm câu trả lời về việc ai đang kiểm soát kho lưu trữ của dự án.
Lo ngại càng tăng khi xuất hiện đồng thời nhiều dấu hiệu như các bản phát hành mới sau thời gian dài im lặng, việc thu hồi quyền truy cập của người bảo trì và quy trình xem xét chưa rõ ràng.
Đối với nhiều chuyên gia, đây là những dấu hiệu thường xuất hiện trong giai đoạn đầu của các cuộc tấn công chuỗi cung ứng, dù chưa có hoạt động độc hại nào được xác nhận.
Trước đó vào tháng 4/2026, nghiên cứu từ Socket cho biết các công cụ bảo mật tự động đã gắn cờ fsnotify là “không được bảo trì” sau hơn một năm không có bản phát hành mới.
Ngay sau đó, Matsumoto phát hành các phiên bản 1.10.0 và 1.10.1 để sửa lỗi xử lý sự kiện hệ thống tập tin, đặc biệt là các vấn đề liên quan đến inotify trên Linux. Dù các bản cập nhật giải quyết các lỗi thực tế, thời điểm phát hành vẫn khiến cộng đồng thêm nghi ngại.
Người duy trì dự án Martin Tournoij (@arp242) phủ nhận mọi cáo buộc liên quan đến việc dự án bị thâu tóm. Ông cho biết những người đóng góp bị loại bỏ vẫn có quyền truy cập vào các commit cũ nhưng hiện không còn tham gia duy trì dự án một cách tích cực.
Trong khi đó, Oshi Yamaguchi, cộng tác viên của Grafana và là người khởi xướng cuộc thảo luận, cho rằng fsnotify được sử dụng quá rộng rãi nên các dự án phụ thuộc cần được cung cấp thêm thông tin để đánh giá thay đổi này.
Ông cũng bày tỏ lo ngại rằng nhiều đóng góp gần đây được hợp nhất quá nhanh mà chưa trải qua quá trình đánh giá đầy đủ trên nhiều nền tảng khác nhau.
Tournoij khẳng định việc thu hồi quyền truy cập liên quan đến quản trị và chất lượng mã nguồn, không phải hành động thù địch. Ông cũng nhắc tới bất đồng trong việc cập nhật cấu hình tài trợ, vốn được đưa trực tiếp lên nhánh chính mà chưa có thảo luận đầy đủ.
Lý do tại sao các người bảo trì khác bị loại khỏi tổ chức #757 (Nguồn: Socket).
Sau đó, Matsumoto đã thừa nhận phát ngôn trước đó có sai sót và gửi lời xin lỗi. Ông cho biết mục tiêu là hỗ trợ hồi sinh một dự án đã hơn một năm không phát hành bản cập nhật.
Sự việc nhanh chóng ảnh hưởng tới các dự án hạ nguồn. Một số nhà phát triển Kubernetes đã mở các cuộc thảo luận để đánh giá tình trạng hoạt động của fsnotify và cân nhắc liệu có nên tìm giải pháp thay thế hoặc sử dụng nhánh phát triển khác hay không.
Một nhánh phát triển như gofsnotify/fsnotify hiện đã nổi lên như phương án dự phòng tiềm năng và đang được cộng đồng theo dõi.
Các chuyên gia an ninh mạng nhận định vụ việc phản ánh đúng mô hình từng xuất hiện trong nhiều cuộc tấn công chuỗi cung ứng trước đây, khi hành vi bất thường của người bảo trì, các bản phát hành đột ngột và cơ chế phân quyền thiếu rõ ràng tạo ra sự bất ổn.
Một ví dụ thường được nhắc tới là vụ cửa hậu xz-utils, nơi niềm tin dành cho người bảo trì đã bị lợi dụng trong thời gian dài.
Theo các nhà duy trì hệ sinh thái Docker và container, các thư viện phụ thuộc như fsnotify thường hoạt động âm thầm phía sau hệ thống nên dễ bị bỏ qua cho tới khi xuất hiện biến động lớn.
Ngoài ra, các công cụ tự động như Dependabot cũng có thể làm tăng rủi ro khi thúc đẩy cập nhật nhanh mà chưa trải qua quy trình xác minh kỹ lưỡng.
Vụ việc fsnotify cuối cùng cho thấy vấn đề lớn hơn nằm ở sự thiếu minh bạch trong quản trị mã nguồn mở. Khi cộng đồng không thể xác định rõ ai đang kiểm soát quy trình phát hành, ngay cả những tranh chấp nội bộ thông thường cũng có thể biến thành mối lo an ninh diện rộng.
Dù chưa phát hiện bất kỳ dấu hiệu xâm phạm nào, sự cố này cho thấy niềm tin có thể bị xói mòn rất nhanh nếu vai trò người bảo trì, quyền truy cập và quy trình đánh giá không được xác định rõ ràng.
Đối với các thư viện mã nguồn mở được sử dụng rộng rãi, việc xây dựng quy trình quản trị và phát hành minh bạch đang trở thành yếu tố quan trọng để duy trì niềm tin trong chuỗi cung ứng phần mềm. (gbhackers)
Đọc chi tiết tại đây: https://gbhackers.com/fsnotify-maintainer-access/
Dù chưa có bằng chứng cho thấy bất kỳ phiên bản nào của fsnotify bị xâm phạm, vụ việc cho thấy sự thiếu minh bạch trong quản trị các dự án mã nguồn mở quan trọng có thể nhanh chóng tạo ra lo ngại trên toàn bộ hệ sinh thái phần mềm.
fsnotify là thư viện thông báo hệ thống tập tin đa nền tảng, hỗ trợ Windows, Linux, macOS, BSD và illumos. Với hơn 10.000 lượt đánh dấu sao trên GitHub cùng hơn 300.000 dự án phụ thuộc, thư viện này đóng vai trò quan trọng trong nhiều công cụ dành cho nhà phát triển, tiện ích dòng lệnh và quy trình hạ tầng.
Chính vì mức độ phổ biến lớn, chỉ cần xuất hiện nghi vấn liên quan đến quyền kiểm soát người bảo trì hoặc quyền phát hành cũng có thể tạo hiệu ứng lan rộng trong chuỗi cung ứng phần mềm.
Tranh chấp quyền quản trị làm dấy lên nghi vấn
Vấn đề bắt đầu khi nhà phát triển Go Yasuhiro Matsumoto, thường được biết đến với tên mattn, cho biết ông đã bị xóa khỏi tổ chức fsnotify trên GitHub.Trong một bài đăng trên mạng xã hội sau đó đã bị xóa, ông cho rằng xung đột nội bộ khiến một số người đóng góp mất quyền truy cập, làm dấy lên lo ngại về khả năng dự án bị thâu tóm.
Người bảo trì bị loại bỏ đã báo động sau khi mất quyền truy cập (Nguồn: Socket).
Những tuyên bố này nhanh chóng thúc đẩy các cuộc thảo luận trên GitHub khi cộng đồng tìm kiếm câu trả lời về việc ai đang kiểm soát kho lưu trữ của dự án.
Lo ngại càng tăng khi xuất hiện đồng thời nhiều dấu hiệu như các bản phát hành mới sau thời gian dài im lặng, việc thu hồi quyền truy cập của người bảo trì và quy trình xem xét chưa rõ ràng.
Đối với nhiều chuyên gia, đây là những dấu hiệu thường xuất hiện trong giai đoạn đầu của các cuộc tấn công chuỗi cung ứng, dù chưa có hoạt động độc hại nào được xác nhận.
Trước đó vào tháng 4/2026, nghiên cứu từ Socket cho biết các công cụ bảo mật tự động đã gắn cờ fsnotify là “không được bảo trì” sau hơn một năm không có bản phát hành mới.
Ngay sau đó, Matsumoto phát hành các phiên bản 1.10.0 và 1.10.1 để sửa lỗi xử lý sự kiện hệ thống tập tin, đặc biệt là các vấn đề liên quan đến inotify trên Linux. Dù các bản cập nhật giải quyết các lỗi thực tế, thời điểm phát hành vẫn khiến cộng đồng thêm nghi ngại.
Người duy trì dự án Martin Tournoij (@arp242) phủ nhận mọi cáo buộc liên quan đến việc dự án bị thâu tóm. Ông cho biết những người đóng góp bị loại bỏ vẫn có quyền truy cập vào các commit cũ nhưng hiện không còn tham gia duy trì dự án một cách tích cực.
Trong khi đó, Oshi Yamaguchi, cộng tác viên của Grafana và là người khởi xướng cuộc thảo luận, cho rằng fsnotify được sử dụng quá rộng rãi nên các dự án phụ thuộc cần được cung cấp thêm thông tin để đánh giá thay đổi này.
Ông cũng bày tỏ lo ngại rằng nhiều đóng góp gần đây được hợp nhất quá nhanh mà chưa trải qua quá trình đánh giá đầy đủ trên nhiều nền tảng khác nhau.
Tournoij khẳng định việc thu hồi quyền truy cập liên quan đến quản trị và chất lượng mã nguồn, không phải hành động thù địch. Ông cũng nhắc tới bất đồng trong việc cập nhật cấu hình tài trợ, vốn được đưa trực tiếp lên nhánh chính mà chưa có thảo luận đầy đủ.
Lý do tại sao các người bảo trì khác bị loại khỏi tổ chức #757 (Nguồn: Socket).
Sau đó, Matsumoto đã thừa nhận phát ngôn trước đó có sai sót và gửi lời xin lỗi. Ông cho biết mục tiêu là hỗ trợ hồi sinh một dự án đã hơn một năm không phát hành bản cập nhật.
Lo ngại lan sang hệ sinh thái mã nguồn mở
Matsumoto cho biết ông đã thực hiện nhiều sửa lỗi và nỗ lực ổn định hệ thống như một phần của quá trình bảo trì hợp pháp, nhưng vẫn lo ngại vì thiếu người bảo trì tích cực để thực hiện đánh giá ngang hàng.Sự việc nhanh chóng ảnh hưởng tới các dự án hạ nguồn. Một số nhà phát triển Kubernetes đã mở các cuộc thảo luận để đánh giá tình trạng hoạt động của fsnotify và cân nhắc liệu có nên tìm giải pháp thay thế hoặc sử dụng nhánh phát triển khác hay không.
Một nhánh phát triển như gofsnotify/fsnotify hiện đã nổi lên như phương án dự phòng tiềm năng và đang được cộng đồng theo dõi.
Các chuyên gia an ninh mạng nhận định vụ việc phản ánh đúng mô hình từng xuất hiện trong nhiều cuộc tấn công chuỗi cung ứng trước đây, khi hành vi bất thường của người bảo trì, các bản phát hành đột ngột và cơ chế phân quyền thiếu rõ ràng tạo ra sự bất ổn.
Một ví dụ thường được nhắc tới là vụ cửa hậu xz-utils, nơi niềm tin dành cho người bảo trì đã bị lợi dụng trong thời gian dài.
Theo các nhà duy trì hệ sinh thái Docker và container, các thư viện phụ thuộc như fsnotify thường hoạt động âm thầm phía sau hệ thống nên dễ bị bỏ qua cho tới khi xuất hiện biến động lớn.
Ngoài ra, các công cụ tự động như Dependabot cũng có thể làm tăng rủi ro khi thúc đẩy cập nhật nhanh mà chưa trải qua quy trình xác minh kỹ lưỡng.
Vụ việc fsnotify cuối cùng cho thấy vấn đề lớn hơn nằm ở sự thiếu minh bạch trong quản trị mã nguồn mở. Khi cộng đồng không thể xác định rõ ai đang kiểm soát quy trình phát hành, ngay cả những tranh chấp nội bộ thông thường cũng có thể biến thành mối lo an ninh diện rộng.
Dù chưa phát hiện bất kỳ dấu hiệu xâm phạm nào, sự cố này cho thấy niềm tin có thể bị xói mòn rất nhanh nếu vai trò người bảo trì, quyền truy cập và quy trình đánh giá không được xác định rõ ràng.
Đối với các thư viện mã nguồn mở được sử dụng rộng rãi, việc xây dựng quy trình quản trị và phát hành minh bạch đang trở thành yếu tố quan trọng để duy trì niềm tin trong chuỗi cung ứng phần mềm. (gbhackers)
Đọc chi tiết tại đây: https://gbhackers.com/fsnotify-maintainer-access/
Được phối hợp thực hiện bởi các chuyên gia của Bkav,
cộng đồng An ninh mạng Việt Nam WhiteHat
và cộng đồng Khoa học công nghệ VnReview
