Phơi bày Gitea và n8n: Tại sao cấu hình quan trọng hơn số lượng tài sản

Các cuộc quét internet gần đây đã xác định hàng trăm nghìn instance của Gitea và n8n có thể truy cập công khai. Đây là hai công cụ tự host (self-hosted) phổ biến dành cho quản lý mã nguồn và tự động hóa quy trình làm việc. Mặc dù khối lượng lớn tài sản bị phơi bày gây ra những lo ngại tức thì, các chuyên gia bảo mật nhấn mạnh rằng sự hiện diện trực tuyến của các dịch vụ này không đồng nghĩa với việc chúng đã bị xâm phạm. Yếu tố then chốt không chỉ là khả năng hiển thị, mà còn là cách các nền tảng này được cấu hình để xử lý các thông tin đăng nhập nhạy cảm mà chúng lưu trữ thay mặt người dùng.

Chuyện gì đã xảy ra

Vào ngày 28 tháng 10 năm 2026, các phép đo thu thập qua nền tảng ZoomEye đã tiết lộ số lượng đáng kể các tài sản được lập chỉ mục, nhận dạng là các ứng dụng tự host cụ thể. Cuộc quét tìm thấy 117.523 tài sản khớp với chữ ký của Gitea, một dịch vụ Git nhẹ. Đối với n8n, một công cụ tự động hóa quy trình làm việc, con số cao hơn nhiều với 420.452 tài sản khớp với chữ ký ứng dụng của nó, cùng với 401.268 kết quả khớp bổ sung dựa trên tiêu đề trang. Những con số này đại diện cho số lượng hệ thống phản hồi với các thăm dò nhận dạng, chứ không nhất thiết là số lượng máy chủ bị xâm phạm hoặc cấu hình sai.

Phân tích làm nổi bật rằng cả Gitea và n8n đều đóng vai trò là kho trung tâm chứa các bí mật (secrets). Gitea lưu trữ khóa triển khai (deploy keys), bí mật webhook, token truy cập và thường cả khóa SSH được sử dụng để đẩy mã nguồn. Tương tự, các quy trình làm việc trong n8n chứa thông tin đăng nhập API cho nhiều dịch vụ bên ngoài được tích hợp vào các quy trình tự động. Vì các nền tảng này tập trung dữ liệu xác thực giá trị cao, bất kỳ instance nào mở cho internet công cộng đều đòi hỏi sự xem xét kỹ lưỡng. Rủi ro không chỉ là truy cập trái phép vào chính nền tảng, mà còn là nguy cơ đánh cắp thông tin đăng nhập của bên thứ ba được lưu trữ bên trong đó.

Chi tiết chính

• ZoomEye ghi nhận 117.523 instance Gitea và 420.452 instance n8n vào ngày 28 tháng 10 năm 2026.
• Gitea lưu trữ các mục nhạy cảm như khóa triển khai, bí mật webhook và khóa SSH cùng với các kho chứa mã nguồn.
• Các quy trình làm việc trong n8n nhúng thông tin đăng nhập API cho các dịch vụ bên ngoài được kết nối, khiến chúng trở thành mục tiêu giá trị cao.
• Thiết lập mặc định của Gitea bao gồm INSTALL_LOCK để bảo vệ trang thiết lập và DISABLE_REGISTRATION để ngăn chặn đăng ký trái phép.
• Các instance n8n thường yêu cầu khả năng truy cập công khai cho webhooks, làm tăng mức độ phơi bày so với các thiết lập Gitea chỉ qua VPN.
• Số lượng tài sản không chỉ ra lỗ hổng; nhiều instance được lập chỉ mục có thể đã được củng cố đúng cách bằng đăng nhập một lần (single sign-on) và quyền truy cập hạn chế.

Bối cảnh

Phần mềm tự host mang lại cho các tổ chức quyền kiểm soát dữ liệu và hạ tầng, nhưng cũng chuyển toàn bộ trách nhiệm bảo mật sang cho người vận hành. Không giống như các dịch vụ đám mây được quản lý, nơi nhà cung cấp xử lý việc vá lỗi và kiểm soát truy cập, các instance tự host phụ thuộc vào quản trị viên để cấu hình đúng các thiết lập bảo mật ngay từ ngày đầu tiên. Các công cụ như Gitea và n8n được thiết kế để tích hợp sâu với các hệ thống khác, điều này đòi hỏi phải lưu trữ cục bộ các token và khóa xác thực. Lựa chọn kiến trúc này tạo ra hiệu ứng "kho chứa thông tin đăng nhập", nơi việc xâm phạm máy chủ sẽ dẫn đến quyền truy cập vào nhiều dịch vụ bên ngoài.

Sự chênh lệch về khả năng hiển thị công khai giữa Gitea và n8n bắt nguồn từ các mô hình triển khai điển hình của chúng. Gitea thường được các nhóm phát triển sử dụng và truy cập qua VPN doanh nghiệp, cho phép nó vẫn vô hình đối với internet công cộng. Ngược lại, n8n dựa vào webhooks để nhận các trigger từ các nhà cung cấp bên ngoài như cổng thanh toán hoặc hệ thống CRM. Yêu cầu chức năng này thường buộc các instance n8n phải có thể truy cập công khai, khiến chúng dễ xuất hiện hơn trong các cuộc quét toàn internet. Hiểu rõ sự khác biệt này giúp giải thích tại sao n8n xuất hiện thường xuyên hơn trong các chỉ mục công khai mặc dù cả hai công cụ đều được áp dụng rộng rãi.

Tại sao điều này quan trọng

Đối với các đội ngũ chạy phần mềm riêng, những phát hiện này nhấn mạnh mối nguy hiểm của việc triển khai kiểu "cài đặt rồi quên". Phổ biến là các quản trị viên cài đặt một công cụ để đánh giá hoặc thiết lập ban đầu và để nó chạy với các cấu hình mặc định. Trong Gitea, nếu INSTALL_LOCK không được bật, trang cấu hình ban đầu vẫn có thể truy cập được, tiềm ẩn nguy cơ kẻ tấn công có thể đặt lại các thiết lập quản trị. Tương tự, nếu việc đăng ký không bị vô hiệu hóa, người dùng trái phép có thể tạo tài khoản và có khả năng truy cập vào các kho chứa nội bộ hoặc định nghĩa quy trình làm việc. Những sơ suất này không phải là các khai thác phức tạp mà là những khoảng trống cấu hình đơn giản để ngỏ cửa cho kẻ xấu.

Sự tích tụ của các thông tin đăng nhập cũ (stale credentials) đặt ra một mối đe dọa thầm lặng khác. Các nền tảng tự động hóa như n8n có xu hướng phát triển hữu cơ, với các tích hợp mới được thêm theo thời gian. Các quy trình làm việc cũ kết nối với các dịch vụ đã ngừng hỗ trợ hoặc sử dụng thông tin đăng nhập từ nhân viên cũ thường vẫn hoạt động vì việc xóa chúng có vẻ rủi ro. Nếu một instance bị phơi bày, kẻ tấn công có thể thu hoạch các token đã bị lãng quên từ lâu. Việc kiểm toán định kỳ cả các biện pháp kiểm soát truy cập của nền tảng và các bí mật cụ thể được lưu trữ trong các quy trình làm việc là rất cần thiết để duy trì tư thế bảo mật an toàn. Số lượng lớn tài sản được lập chỉ mục cho thấy nhiều tổ chức có thể không thực hiện các kiểm tra thường lệ này.

Bạn có thể làm gì

• Xác minh rằng INSTALL_LOCK được đặt thành true trong cấu hình Gitea của bạn để chặn quyền truy cập vào trình hướng dẫn thiết lập.
• Đảm bảo DISABLE_REGISTRATION được bật trong Gitea trừ khi bạn đặc biệt muốn cho phép đăng ký công khai.
• Xem xét các thiết lập quản lý người dùng trong n8n để xác nhận rằng chỉ những nhân sự được ủy quyền mới có thể tạo tài khoản hoặc sửa đổi quy trình làm việc.
• Kiểm toán tất cả các khóa triển khai và bí mật webhook trong Gitea, loại bỏ bất kỳ mục nào thuộc về nhân viên đã nghỉ việc hoặc các dự án không còn sử dụng.
• Kiểm tra các quy trình làm việc trong n8n để tìm các thông tin đăng nhập API lỗi thời và xoay vòng (rotate) khóa cho bất kỳ dịch vụ nào vẫn đang được sử dụng tích cực.
• Cân nhắc đặt các instance tự host phía sau một reverse proxy hoặc VPN để giới hạn mức độ phơi bày công khai chỉ đối với các endpoint cần thiết.