Bản vá bảo mật n8n 14/10: 8 lỗ hổng, 5 mức High — 3 việc làm trước khi dựng webhook cho khách

Tuần trước mình có viết về bản vá bảo mật n8n đầu tháng 10. Tuần này có bản vá thứ hai, và bản này nặng hơn: 8 lỗ hổng, 5 cái ở mức High.

Cái đáng chú ý nhất không phải con số mà là loại lỗ hổng. Cross-Project Data Access (CVSS 7.2) cho phép người dùng bị hạn quyền trong một dự án tới được đọc hoặc sửa Data Table của dự án khác, chỉ cần biết đúng mã workflow. Với hệ thống chạy nhiều dự án trên cùng một instance, đây là kiểu lỗ hổng mà ranh giới dữ liệu không giữ được.

Còn ba điểm khác trong bản vá này: • Stored XSS trong phản hồi webhook (CVSS 8.4) — HTML độc hại từ webhook có thể chạy JavaScript trong phiên đã đăng nhập của người khác. Ai đang dựng webhook nhận dữ liệu từ bên ngoài thì phần này đáng để ý nhất. • Prototype pollution và DoS ở node Read/Write Files — mẫu glob cố ý treo event loop, làm nghẽn cả instance chứ không chỉ luồng đó. • Lộ credential trong lỗi thực thi — một số lỗi node hiện ra thông tin kết nối nhạy cảm cho người có quyền xem dữ liệu thực thi.

Bản vá theo 3 nhánh: 1.123.85 cho bản 1.x, 2.43.5 cho bản 2.x ổn định, 2.44.1 cho beta. Bản Cloud đã vá tự động, bản tự host thì phải tự lên. Chưa có báo cáo nào cho thấy các lỗ hổng này đang bị khai thác, nhưng "chưa bị khai thác" và "an toàn" là hai chuyện khác nhau.

Ba việc nên làm sau khi vá:

1. Lên đúng nhánh đã vá, không chạy theo beta Cách làm: chạy n8n --version hoặc xem trang About để xác định phiên bản đang chạy. Bản 2.x thì lên 2.43.5 trở lên, bản 1.x thì lên 1.123.85. Beta 2.44.1 chỉ dành cho môi trường thử nghiệm. Với Docker: xuất toàn bộ workflow ra JSON trước, kéo lại image, dựng lại container với đúng volume cũ.

2. Rà lại quyền người dùng và ranh giới dự án Cách làm: vào quản lý người dùng, bật giới hạn workflow trong phạm vi dự án của chính người đó, chặn truy cập chéo Data Table. Rà và vô hiệu hoá tài khoản của nhân viên đã nghỉ việc hoặc tài khoản khách không còn dùng. Tách bản vá bảo mật và nâng cấp tính năng thành hai việc riêng, để khi có vấn đề biết ngay do cái nào.

3. Dọn log thực thi và đổi lại thông tin kết nối Cách làm: lỗi lộ credential chỉ nguy hiểm khi thông tin đó đã được ghi vào log. Quét lịch sử thực thi, kiểm tra các lần chạy có lỗi, xoá log cũ, đổi lại API key và mật khẩu tài khoản dịch vụ mà luồng từng dùng. Rà lại quyền xem dữ liệu thực thi cho từng vai trò.

Sơ đồ luồng kiểm tra: • Xuất JSON toàn bộ workflow làm bản lưu, ghi lại phiên bản đang chạy • n8n --version, đối chiếu với nhánh đã vá tương ứng • Nâng image Docker, dựng lại container, giữ nguyên volume dữ liệu • Siết quyền theo dự án, chặn truy cập chéo Data Table • Quét lịch sử thực thi, xoá log lỗi cũ, đổi lại các key đã lộ • Theo dõi 24 giờ đầu, gắn cảnh báo vào nhóm chat khi node gặp lỗi

Ba con số chuyển từ chỗ cứ đoán sang biết chính xác: • Thời gian vá lỗi bảo mật: từ khoảng 3 giờ dựng lại môi trường xuống còn 25 phút • Tài khoản người dùng cần rà lại: từ 14 tài khoản xuống còn 6 tài khoản thật sự hoạt động, 8 tài khoản thừa bị vô hiệu hoá • Số lần lộ thông tin kết nối trong log thực thi: từ 23 lần trong một tháng xuống còn 0, sau khi dọn log và đổi lại key

Câu đúc kết: bản vá bảo mật là việc bắt buộc, nhưng chỉ bấm nút cập nhật thì chưa đủ — phải rà quyền và dọn log mới thật sự đóng được lỗ hổng.

Chi tiết checklist 3 việc sau khi lên bản 2.43.5, danh sách 8 lỗ hổng và mẫu lệnh rà quyền mình để tại link Blog dưới phần bình luận nhé!

Bạn đang ở bản n8n nào, và có dựng webhook nhận dữ liệu từ bên ngoài chưa? Nếu có, phần Stored XSS trong bản vá này là phần nên rà trước tiên.

#n8n #AIAutomation #Security #Webhook

Bình luận

Nhận checklist 3 việc sau bản vá 14/10, danh sách 8 lỗ hổng và mẫu lệnh rà quyền cho n8n: https://tyauto.name.vn/posts/2026-10-25-personal-feed-n8n-patch-bao-mat-1410-8-lo-hong.html