Các nhà nghiên cứu tại GitGuardian đã phát hiện 321 phiên bản n8n chấp nhận các mã thông báo (API tokens) bị lộ trong các lần commit công khai trên GitHub. Họ cũng trình bày bốn cách kẻ tấn công có thể sử dụng chúng để truy cập dữ liệu nhạy cảm và thông tin xác thực hạ nguồn mà không cần khai thác lỗ hổng phần mềm.
Chúng tôi đã quét các bản commit công khai trên GitHub để tìm các mã thông báo API n8n bị lộ và xác định được 4.576 thông tin xác thực duy nhất liên quan đến 1.255 tên miền máy chủ (hostnames). Trong số 896 phiên bản có thể truy cập được tại thời điểm thử nghiệm, có 321 phiên bản chấp nhận ít nhất một mã thông báo bị rò rỉ.
Điều đó có nghĩa là các thông tin xác thực bị rò rỉ đã cung cấp quyền truy cập được xác thực vào 36% các phiên bản có thể truy cập mà chúng tôi đã thử nghiệm, tương đương khoảng 26% tổng số hostnames được xác định trong các bản commit.
Hệ lụy của vấn đề này vượt xa khỏi phạm vi của n8n. Các tổ chức sử dụng nền tảng tự động hóa này để kết nối cơ sở dữ liệu, kho lưu trữ mã nguồn, môi trường đám mây, dịch vụ trí tuệ nhân tạo, nền tảng hỗ trợ khách hàng và các hệ thống nội bộ khác. Một mã thông báo n8n có đủ đặc quyền có thể làm lộ các định nghĩa workflow và dữ liệu thực thi, cho phép kẻ tấn công sử dụng các thông tin xác thực đã lưu trữ và trong một số cấu hình, cho phép chúng trích xuất các giá trị thông tin xác thực cơ bản.
Để đo lường phạm vi tác động (blast radius) tiềm tàng, chúng tôi đã tái hiện bốn kỹ thuật tấn công thực tế trong môi trường n8n được kiểm soát. Mỗi kỹ thuật chỉ yêu cầu chức năng REST API đã được tài liệu hóa và các yêu cầu HTTP tiêu chuẩn. Không cần khai thác lỗ hổng CVE hay công cụ chuyên dụng nào.
Tại sao n8n là mục tiêu giá trị cao
n8n là một nền tảng tự động hóa workflow mã thấp (low-code), nguồn mở với sự hỗ trợ của các tác nhân AI và hàng trăm tích hợp có sẵn. Các tổ chức sử dụng nó để kết nối các công cụ nội bộ, tự động hóa quy trình, thực hiện logic kinh doanh và điều phối các tích hợp API trên toàn bộ hệ thống công nghệ của họ.
Nền tảng này có thể được tự lưu trữ (self-hosted) hoặc triển khai thông qua n8n.cloud, và kho lưu trữ nguồn mở của nó đã thu hút gần 200.000 sao trên GitHub.
Một phiên bản n8n chạy các workflow bao gồm các nút (nodes). Một số nút kích hoạt workflow theo lịch trình hoặc thông qua webhooks, trong khi những nút khác biến đổi dữ liệu, thực thi mã hoặc kết nối với các dịch vụ bên ngoài bằng các thông tin xác thực đã lưu trữ như API keys, tokens và mật khẩu cơ sở dữ liệu.
Các thông tin xác thực đó được mã hóa khi lưu trữ (encrypted at rest) bằng một bí mật chính gọi là N8N_ENCRYPTION_KEY. Tuy nhiên, n8n vẫn cần giải mã và sử dụng chúng bất cứ khi nào workflow chạy. Do đó, một kẻ tấn công với đủ đặc quyền API có thể tham chiếu các thông tin xác thực đó trong các workflow mới và khiến phiên bản n8n sử dụng chúng thay mặt cho kẻ tấn công.
Với hơn 100.000 phiên bản có thể nhìn thấy qua Shodan và hơn 50 cảnh báo bảo mật được công bố kể từ tháng 1 năm 2026, n8n đã thu hút sự chú ý tương tự như các nền tảng tích hợp giá trị cao khác.
Tính đến ngày 31 tháng 3 năm 2026, 58% các phiên bản chúng tôi đã quét đang chạy một phiên bản bị ảnh hưởng bởi ít nhất một cảnh báo bảo mật đã biết. Một số CVE gần đây cho phép kẻ tấn công thoát khỏi môi trường thực thi (sandbox) và giành quyền đọc hoặc ghi tùy ý vào hệ thống tệp của máy chủ.
CVE-2025-68613, một lỗ hổng chèn biểu thức (expression injection) với điểm CVSS là 9.9, đã được thêm vào danh mục Các lỗ hổng bị khai thác đã biết của Cơ quan An ninh Cơ sở hạ tầng và An ninh mạng Hoa Kỳ (CISA) vào ngày 11 tháng 3 năm 2026, xác nhận việc khai thác trong thực tế.
Mã thông báo API bị rò rỉ tạo ra một rủi ro riêng biệt. Kẻ tấn công không nhất thiết phải khai thác lỗ hổng n8n nếu một thông tin xác thực hợp lệ đã cung cấp quyền truy cập được xác thực vào phiên bản đó.
Chúng tôi tìm thấy 321 phiên bản chấp nhận mã thông báo bị rò rỉ
GitGuardian Public Monitoring quét các nguồn công khai để tìm các thông tin xác thực bị lộ. Đối với nghiên cứu này, chúng tôi đã thu thập mọi mã thông báo API n8n mà nó đã xác định được trong các bản commit công khai trên GitHub kể từ tháng 4 năm 2025.
Quy trình của chúng tôi đã trích xuất hostname n8n được commit cùng với mỗi mã thông báo, gửi một yêu cầu xác thực chỉ đọc đến phiên bản liên quan và ghi lại phản hồi.
Kết quả quét cho thấy:
| Giai đoạn | Số lượng |
|---|---|
| Mã thông báo API duy nhất | 4.576 |
| GitHub commit chứa mã thông báo | 5.469 |
| Hostnames duy nhất được trích xuất | 1.255 |
| Phiên bản có thể truy cập công khai | 896 |
| Phiên bản chấp nhận mã thông báo bị rò rỉ | 321 |
321 phiên bản được xác nhận đại diện cho khoảng 36% trong số 896 phiên bản có thể truy cập và 26% trong tổng số 1.255 hostnames được xác định trong các bản commit.
Chúng tôi cũng thực hiện quy trình tương tự đối với các API keys của n8n Model Context Protocol (MCP) được tìm thấy trong cùng bộ commit. Mã thông báo MCP cho phép các trợ lý AI gọi các workflow n8n thông qua Model Context Protocol, tạo ra một bề mặt tiếp xúc mới hơn so với REST API.
Trong số 372 mã thông báo MCP được xác định, có bảy mã vẫn hợp lệ tại thời điểm thử nghiệm, tương đương khoảng 2%.
Tại sao các mã thông báo n8n bị rò rỉ vẫn có thể duy trì hiệu lực
Một API key n8n là một JSON Web Token (JWT) được ký với một khai báo đối tượng (audience claim) "aud": "public-api". Một mã thông báo được giải mã trông như sau:
{
"sub": "efdf9cca-049a-46aa-afdc-172f0824f6cb",
"iss": "n8n",
"aud": "public-api",
"jti": "aac8a7a8-c8c4-4855-8e8b-2806e90b16e1",
"iat": 1781551662
}Mã thông báo ghi lại thời gian phát hành trong claim iat. Các API keys n8n cũ hơn thường không chứa claim exp xác định thời điểm hết hạn.
n8n đã giới thiệu thời hạn hết hạn mặc định 30 ngày trong phiên bản 1.78.0 vào tháng 2 năm 2025, nhưng nhiều mã thông báo được tìm thấy trong quá trình nghiên cứu đã được tạo ra mà không có ngày hết hạn. Một key được commit lên GitHub vài tháng trước đó vẫn có thể sử dụng được cho đến khi ai đó xóa hoặc thu hồi nó một cách rõ ràng.
Trong thực tế, API keys n8n hoạt động khác với các JWT độc lập có thể được xác thực chỉ bằng chữ ký của chúng. Key cũng phải tồn tại trong cơ sở dữ liệu n8n. Một mã thông báo bị lộ trên GitHub vẫn nguy hiểm chừng nào phiên bản đó còn tiếp tục nhận diện nó.
Việc kiểm tra một mã thông báo tiềm năng yêu cầu một yêu cầu chỉ đọc với key được truyền qua tiêu đề X-N8N-API-KEY:
curl -s -o /dev/null -w "%{http_code}" \
-H "X-N8N-API-KEY: <token>" \
https://n8n.example.com/api/v1/workflowsGET /api/v1/workflows trả về các định nghĩa workflow có sẵn cho người dùng đã xác thực.
Phản hồi 200 xác nhận mã thông báo được chấp nhận. Phản hồi 401 cho biết mã thông báo không hợp lệ, đã bị xóa khỏi cơ sở dữ liệu hoặc không xác thực được chữ ký. Phản hồi 404 có thể cho biết API công khai bị vô hiệu hóa trên phiên bản đó.
Yêu cầu này không thực hiện thay đổi nào đối với phiên bản mục tiêu.
URL của phiên bản thường được commit bên cạnh mã thông báo
Một API key n8n chỉ hữu ích khi kẻ tấn công có thể xác định phiên bản chấp nhận nó. Tuy nhiên, trong các bản commit công khai trên GitHub, hostname và mã thông báo thường xuất hiện cùng nhau.
Tệp .env là một ví dụ phổ biến:
N8N_URL="https://n8n.redacted.cloud:5678"
N8N_API_KEY="eyJhREDACTEDPWw4"Chúng tôi cũng tìm thấy một mẫu mới hơn liên quan đến các tệp quyền của Claude Code.
Claude Code có thể lưu trữ các lệnh shell được phép trong .claude/settings.json hoặc .claude/settings.local.json. Khi người dùng cấu hình Claude Code để tương tác với n8n, họ có thể đặt cả URL phiên bản và API key trực tiếp bên trong một lệnh curl đã được phê duyệt.
Bash(curl -s "https://automation.redacted.fr/api/v1/workflows" \
-H "X-N8N-API-KEY: eyJhREDACTEDegE")Các tệp cài đặt này sau đó có thể được commit vào kho lưu trữ mà không có các biện pháp bảo vệ .gitignore tương tự mà các nhà phát triển thường áp dụng cho các tệp .env.
Sự kết hợp giữa hostname và mã thông báo cũng xuất hiện dưới một số tên biến khác, bao gồm:
N8N_MCP_URL
N8N_WEBHOOK_BASE_URL
process.env.N8N_URL
os.getenv("N8N_HOST", "...")Vì hostname thường có sẵn trong cùng một bản commit với mã thông báo, quy trình của chúng tôi không yêu cầu một bước khám phá hạ tầng riêng biệt.
Những gì một mã thông báo n8n đã xác thực có thể làm lộ
Một mã thông báo API n8n cung cấp quyền truy cập theo đặc quyền của người dùng đã tạo ra nó. Trong thực tế, nhiều mã thông báo bị lộ dường như thuộc về chủ sở hữu phiên bản hoặc quản trị viên, có thể vì đó là những người dùng cấu hình các tích hợp và commit các key.
Tùy thuộc vào vai trò của tài khoản, REST API công khai có thể làm lộ:
GET /api/v1/users: Tên người dùng, địa chỉ email, ngày tạo tài khoản và các lời mời đang chờ xử lý. Một số thông tin chỉ giới hạn cho chủ sở hữu phiên bản.GET /api/v1/workflows: Các định nghĩa workflow đầy đủ, bao gồm cấu hình nút, mã JavaScript hoặc Python trong các nút Code, các truy vấn SQL và các bí mật được mã hóa cứng (hard-coded) trong các tham số workflow.GET /api/v1/credentials: Tên thông tin xác thực, loại và thông tin chia sẻ, nhưng không phải giá trị cơ bản. Endpoint này bị giới hạn cho chủ sở hữu và quản trị viên.GET /api/v1/executions: Lịch sử thực thi workflow. Việc thêm?includeData=truecó thể trả về toàn bộ dữ liệu đầu vào và đầu ra từ mỗi lần chạy.GET /api/v1/data-tables: Các hàng từ các bảng hiển thị cho người dùng đã xác thực.GET /api/v1/variables: Tên biến và nội dung của chúng. Endpoint này bị giới hạn cho chủ sở hữu và quản trị viên.
Các định nghĩa workflow tạo ra sự tiếp xúc tức thì nhất vì API trả về cấu hình nút đầy đủ. Nếu một nhà phát triển đặt API key hoặc mã thông báo trực tiếp vào một tham số nút thay vì sử dụng kho lưu trữ thông tin xác thực của n8n, giá trị đó có thể xuất hiện dưới dạng văn bản thuần túy.
Bản thân endpoint thông tin xác thực không trả về các giá trị bí mật được lưu trữ. Tuy nhiên, như các thử nghiệm có kiểm soát của chúng tôi đã chứng minh, một kẻ tấn công có quyền tạo và thực thi workflow có thể tham chiếu đến một thông tin xác thực đã lưu trữ và khiến n8n sử dụng hoặc truyền tải nó.
Audit endpoint cung cấp bản đồ tấn công
Endpoint kiểm tra (audit) của n8n có thể cung cấp cho người dùng đã xác thực một báo cáo bảo mật cho phiên bản đó:
curl -H "X-N8N-API-KEY: $JWT" \
-d "{}" \
-H "Content-Type: application/json" \
https://$N8N_INSTANCE/api/v1/auditPhản hồi có thể xác định:
- Các điểm có khả năng bị tấn công SQL injection trong workflow
- Các nút có quyền truy cập hệ thống tệp
- Các webhooks không được bảo vệ
- Phiên bản n8n đang chạy, có thể được so khớp với các CVE đã biết
- Thông tin xác thực không được sử dụng
- Các nút rủi ro cao hoặc do cộng đồng cài đặt
- Các tính năng bảo mật đã được kích hoạt
- Danh sách cho phép (allowlists) và danh sách chặn (blocklists) của các nút
- Cấu hình đo từ xa (telemetry)
Đối với một quản trị viên hợp pháp, thông tin này hỗ trợ việc xem xét bảo mật. Đối với một kẻ tấn công nắm giữ mã thông báo đặc quyền bị rò rỉ, nó có thể cung cấp một bản đồ ưu tiên về các con đường tấn công hứa hẹn nhất của phiên bản đó.
Bốn kỹ thuật tấn công nhắm vào một phiên bản đã được vá đầy đủ
GitGuardian không thực hiện các kỹ thuật khai thác sau đối với các hệ thống của bên thứ ba bị lộ. Chúng tôi đã tái hiện chúng trong một triển khai n8n được kiểm soát được xây dựng riêng cho nghiên cứu này.
Workflow thử nghiệm chứa ba điểm yếu cố ý:
- Một biểu mẫu web lưu trữ các nội dung gửi đi trong một bảng dữ liệu có thể truy cập được thông qua các workflow đã xác thực.
- Một nút OpenAI xử lý mỗi lần gửi bằng cách sử dụng một đối tượng thông tin xác thực đã lưu trữ.
- Một nút HTTP Request xuất bản kết quả lên GitHub bằng một mã thông báo được mã hóa cứng trong các tham số nút.
Sử dụng môi trường đó, chúng tôi đã trình bày bốn kỹ thuật, tiến triển từ việc liệt kê thụ động đến việc trích xuất thông tin xác thực chủ động.
Kỹ thuật 1: Liệt kê phiên bản
GET /api/v1/users đã trả về bốn tài khoản: chủ sở hữu phiên bản, hai người dùng đang hoạt động và một đăng ký đang chờ xử lý.
GET /api/v1/workflows đã trả về chín định nghĩa workflow đầy đủ. Trong workflow mục tiêu, các tham số của một nút HTTP Request chứa một mã thông báo GitHub dưới dạng văn bản thuần túy.
Kỹ thuật đầu tiên này không yêu cầu sửa đổi workflow. Thông tin bị lộ đã có sẵn thông qua các hoạt động đọc được phép đối với tài khoản đã xác thực.
Kỹ thuật 2: Sử dụng thông tin xác thực OpenAI đã lưu trữ
GET /api/v1/credentials đã liệt kê mọi đối tượng thông tin xác thực đã lưu trữ, bao gồm một đối tượng có tên "OpenAI account". Endpoint này tiết lộ tên, loại và mã định danh của nó, nhưng không tiết lộ bản thân API key.
Chúng tôi đã tạo một workflow với trình kích hoạt Schedule và một nút OpenAI tham chiếu đến thông tin xác thực bằng ID của nó, sau đó kích hoạt nó.
Hai thủ thuật khiến điều này hoạt động: trình kích hoạt Schedule tự động khởi chạy sau khoảng 10 giây, cho workflow thời gian để hoàn thành. GET /api/v1/executions?includeData=true sau đó sẽ lấy lại bản ghi thực thi đầy đủ. Vì n8n lưu trữ toàn bộ đầu ra của mỗi nút, phản hồi OpenAI sẽ xuất hiện dưới dạng văn bản thuần túy.
Chúng tôi đã thực chạy thành công các yêu cầu OpenAI tùy ý bằng cách sử dụng thông tin xác thực đã lưu trữ của phiên bản mà không bao giờ nhìn thấy giá trị của nó.
Kỹ thuật 3: Đọc bảng dữ liệu
Hai thủ thuật tương tự cũng được áp dụng.
Chúng tôi đã tạo một workflow với trình kích hoạt Schedule và một nút Data Table được cấu hình để lấy tất cả các hàng, sau đó kích hoạt nó. GET /api/v1/executions?includeData=true đã trả về bản ghi thực thi vài giây sau đó, với mọi hàng ở dạng văn bản thuần túy.
Bốn hàng đã bị trích xuất, bao gồm tên, địa chỉ email, câu trả lời biểu mẫu và trạng thái xử lý.
Workflow sau đó đã bị xóa.
Kỹ thuật 4: Trích xuất thông tin xác thực OpenAI thô
Kỹ thuật thứ tư không chỉ dừng lại ở việc sử dụng thông tin xác thực đã lưu trữ mà còn trích xuất giá trị cơ bản của nó.
Chúng tôi đã khởi động một trình lắng nghe HTTP, sau đó tạo một workflow với trình kích hoạt Schedule và một nút HTTP Request.
Thủ thuật chính là nút HTTP Request có thể sử dụng thông tin xác thực n8n đã lưu trữ làm phương thức xác thực trong khi gửi yêu cầu đến bất kỳ URL nào. Chúng tôi đã cấu hình nút sử dụng thông tin xác thực OpenAI đã lưu trữ và trỏ nó đến trình lắng nghe của mình.
Khi workflow khởi chạy, n8n đã đính kèm giá trị thông tin xác thực dưới dạng Bearer token trong tiêu đề Authorization gửi đi. Trình lắng nghe đã nắm bắt được API key thô vài giây sau khi kích hoạt.
Workflow sau đó đã bị xóa.
Cùng với nhau, các kỹ thuật này cho thấy cách một kẻ tấn công có thể tiến triển từ một mã thông báo n8n bị rò rỉ đến việc lộ thông tin xác thực và dữ liệu rộng hơn bằng cách sử dụng các chức năng hợp pháp của nền tảng:
- Liệt kê người dùng, workflow và cấu hình bảo mật.
- Xác định các đối tượng thông tin xác thực đã lưu trữ và các bí mật được mã hóa cứng.
- Sử dụng các thông tin xác thực đã lưu trữ mà không cần xem giá trị của chúng.
- Đọc dữ liệu có sẵn cho các workflow.
- Khiến n8n truyền tải thông tin xác thực đã lưu trữ đến hạ tầng do kẻ tấn công kiểm soát.
Việc xóa workflow độc hại cũng loại bỏ các bản ghi thực thi liên quan khỏi giao diện, có khả năng khiến những người phòng thủ chỉ có bằng chứng hạn chế để điều tra.
Các workflow trong thực tế cho thấy những điểm yếu tương tự
Cuộc trình diễn có kiểm soát không dựa trên một cấu hình lý thuyết thuần túy. Trong quá trình nghiên cứu, chúng tôi đã tìm thấy các phiên bản n8n thực tế chứa các mẫu tiếp xúc tương tự.
Một workflow đã tự động sao lưu các định nghĩa của chính nó vào một kho lưu trữ GitHub công khai. Một SSH deployment key đã được mã hóa cứng trực tiếp vào một trong các nút của nó.
Lịch sử Git của kho lưu trữ chứa các phiên bản cũ của mọi workflow, và SSH key vẫn còn hợp lệ.
Workflow này thực tế đã tự xuất bản cấu hình và thông tin xác thực nhạy cảm của chính nó mỗi khi nó chạy.
Trường hợp này minh họa lý do tại sao các nền tảng tự động hóa workflow có thể tạo ra phạm vi tác động cực lớn. Chúng nằm giữa nhiều hệ thống, xử lý dữ liệu nhạy cảm và thường xuyên xác thực với các dịch vụ bên ngoài. Một điểm yếu trong một workflow có thể làm lộ quyền truy cập vượt xa cả bản thân nền tảng tự động hóa đó.
Thông báo có trách nhiệm nhận được phản hồi hạn chế
Tìm thấy một thông tin xác thực bị lộ còn hiệu lực chỉ là bước đầu tiên. Rủi ro vẫn tồn tại cho đến khi tổ chức bị ảnh hưởng thu hồi nó và giải quyết mọi sự tiếp xúc hạ nguồn.
Chúng tôi đã cố gắng thông báo có trách nhiệm với bảy tổ chức:
- Ba nhà cung cấp dịch vụ lưu trữ liên quan đến khoảng 100 phiên bản bị ảnh hưởng
- Bốn công ty riêng lẻ
Một nhà cung cấp dịch vụ lưu trữ đã không phản hồi. Ba trong số bốn công ty riêng lẻ cũng không phản hồi.
Một công ty vận hành chương trình tiền thưởng lỗi (bug bounty), đã xác nhận báo cáo, trả mức thưởng 1.200 USD và thu hồi thông tin xác thực ngay lập tức. Sự kết hợp giữa việc công nhận và khắc phục nhanh chóng đó là trường hợp ngoại lệ.
GitGuardian cũng đã thực hiện một số thông báo trực tiếp tới n8n trong quá trình nghiên cứu. n8n đã xác nhận các báo cáo, cho biết họ đã biết về các vấn đề và dự định giải quyết chúng, sau đó đóng các báo cáo. Tại thời điểm công bố, GitGuardian chưa xác nhận độc lập rằng các bản vá liên quan đã được phát hành.
Khoảng 30% trong số 321 phiên bản bị ảnh hưởng được lưu trữ trên n8n.cloud hoặc các dịch vụ quản lý tương tự.
GitGuardian Public Monitoring hiện đã xác định các mã thông báo API n8n bị lộ và thông báo cho các nhà phát triển bị ảnh hưởng thông qua chương trình tiết lộ Good Samaritan của công ty. Các phát hiện này cũng dẫn đến việc GitGuardian cập nhật trình phát hiện và kiểm tra tính hợp lệ của API key n8n để cải thiện độ chính xác.
Kết luận rút ra
Một mã thông báo n8n bị rò rỉ không phải là một sự tiếp lộ thông tin xác thực riêng lẻ. Một mã thông báo có đủ đặc quyền có thể làm lộ các định nghĩa workflow, bí mật mã hóa cứng, dữ liệu thực thi và các bảng nội bộ. Nó cũng có thể cho phép kẻ tấn công sử dụng các thông tin xác thực đã lưu trữ hoặc, bằng cách tạo ra một workflow gửi chúng đến một endpoint bên ngoài, trích xuất các giá trị cơ bản của chúng.
Không cần CVE hay công cụ chuyên dụng nào trong các thử nghiệm có kiểm soát của chúng tôi. Một vài yêu cầu HTTP tiêu chuẩn là đủ để chuyển từ một mã thông báo bị lộ sang dữ liệu nhạy cảm và quyền truy cập thông tin xác thực hạ nguồn. Kẻ tấn công sau đó có thể xóa workflow và các bản ghi thực thi liên quan, để lại rất ít bằng chứng bên trong chính n8n.
Thu hồi mã thông báo n8n bị lộ là bước đầu tiên, nhưng có thể chưa phải là cuối cùng. Các tổ chức nên xác định workflow, dữ liệu và thông tin xác thực hạ nguồn nào mà tài khoản đó có thể truy cập, xem xét phiên bản để tìm các thay đổi trái phép và xoay vòng (rotate) các thông tin xác thực đã kết nối khi không thể loại trừ khả năng bị lộ.
Các nền tảng tự động hóa tạo ra phạm vi tác động đặc biệt lớn vì chúng nằm ở trung tâm của các tích hợp trong tổ chức. Một mã thông báo duy nhất có thể cung cấp con đường hướng tới kiểm soát nguồn, cơ sở dữ liệu, dịch vụ đám mây, AI API, nền tảng hỗ trợ và dữ liệu khách hàng. Rủi ro không chỉ giới hạn ở phiên bản n8n mà còn ở mọi hệ thống được kết nối với nó.
