Vào tháng 2 năm 2026, một lỗ hổng nghiêm trọng liên quan đến việc thoát khỏi vùng cách ly (sandbox) đã được công bố rộng rãi trong n8n, nền tảng tự động hóa quy trình làm việc mã nguồn mở được sử dụng rộng rãi. Lỗ hổng này, được theo dõi với mã CVE-2026-25049, cho phép người dùng đã đăng nhập vượt qua vùng cách ly đánh giá biểu thức và thực thi các lệnh hệ thống tùy ý trên máy chủ chủ, từ đó đạt được khả năng thực thi mã từ xa hoàn toàn với điểm CVSS v3.1 là 9,9.
Trong khuôn khổ Chương trình Học bổngOPSWAT , các học viên của chúng tôi đã tiến hành một phân tích kỹ thuật toàn diện về lỗ hổng CVE-2026-25049, nhằm làm rõ nguyên nhân gốc rễ, cơ chế khai thác và tác động đối với tổ chức.
Bài viết này cung cấp một phân tích chi tiết về lỗ hổng bảo mật này – từ kiến trúc xử lý biểu thức của n8n và các biện pháp bảo mật theo từng lớp cho đến kỹ thuật cụ thể có thể vượt qua đồng thời cả năm lớp phòng thủ.
CVE-2026-25049 là lỗ hổng nghiêm trọng liên quan đến việc thoát khỏi vùng cách ly (sandbox escape) trong n8n, được phân loại theo CWE-913: Kiểm soát không đúng cách các tài nguyên mã được quản lý động. Lỗ hổng này ảnh hưởng đến tất cả các phiên bản n8n trước 1.123.17, cũng như các phiên bản từ 2.0.0 đến 2.5.1, và đã được vá trong các phiên bản 1.123.17 và 2.5.2. Lỗ hổng này cho phép người dùng đã xác thực có quyền tạo quy trình công việc tạo ra các biểu thức JavaScript độc hại để vượt qua vùng chứa biểu thức của nền tảng, từ đó thực thi các lệnh tùy ý trên máy chủ chủ.
Lỗ hổng này đặc biệt nghiêm trọng vì n8n thường chiếm vị trí đặc quyền trong cơ sở hạ tầng của tổ chức. Với vai trò là trung tâm tự động hóa quy trình làm việc, n8n thường có quyền truy cập trực tiếp vào các API nội bộ, cơ sở dữ liệu, kho thông tin đăng nhập và các dịch vụ của bên thứ ba. Một phiên bản n8n bị xâm nhập không chỉ khiến máy chủ tự động hóa bị lộ thông tin mà còn trở thành điểm trung chuyển để xâm nhập vào mọi hệ thống được kết nối, từ đó làm gia tăng đáng kể phạm vi ảnh hưởng của cuộc tấn công.
CVE-2026-25049 không phải là một lỗ hổng độc lập mà là một lỗ hổng cho phép vượt qua bản vá dành cho CVE-2025-68613, một lỗ hổng thoát khỏi vùng cách ly (sandbox escape) trước đó trong bộ đánh giá biểu thức của n8n. Mặc dù đã triển khai nhiều lớp phòng thủ sau lỗ hổng ban đầu, một lỗ hổng cơ bản trong cách trình làm sạch xử lý các loại nút Cây cú pháp trừu tượng JavaScript (AST) đã cho phép loại tấn công ban đầu tái xuất hiện thông qua một vectơ cú pháp khác. Mô hình này - trong đó bản vá giải quyết kỹ thuật khai thác cụ thể thay vì điểm yếu thiết kế cơ bản - nêu bật thách thức dai dẳng trong việc bảo mật các môi trường đánh giá mã động.
Lỗ hổng bảo mật này đã được công bố vào ngày 4 tháng 2 năm 2026, cùng với mười thông báo bảo mật khác dành cho n8n, và đã được nhiều nhóm nghiên cứu bảo mật phân tích độc lập.
Giới thiệu về n8n
n8n là một nền tảng tự động hóa quy trình làm việc mã nguồn mở, giúp các tổ chức kết nối các hệ thống, tự động hóa quy trình và xây dựng các tích hợp trên hàng trăm dịch vụ. Với sự phổ biến rộng rãi và hơn 1.300 tích hợp sẵn có, n8n đã trở thành một trong những công cụ phổ biến nhất trong lĩnh vực của mình, được các đội ngũ phát triển và doanh nghiệp sử dụng để tự động hóa mọi thứ, từ các công cụ nội bộ đến các đường ống dữ liệu quan trọng đối với hoạt động kinh doanh.
Nền tảng này hỗ trợ cả triển khai tự lưu trữ và trên đám mây, đồng thời cung cấp công cụ xây dựng quy trình làm việc trực quan cùng với hỗ trợ JavaScript trực tiếp cho các logic tùy chỉnh. Kiến trúc của n8n dựa trên các nút (node): các quy trình làm việc được cấu thành từ các nút liên kết với nhau, truyền dữ liệu dưới định dạng JSON giữa các bộ kích hoạt, hành động và các bước hàm. Việc thực thi có thể chạy ở chế độ thủ công để thử nghiệm hoặc ở chế độ sản xuất để triển khai trực tiếp. Kiến trúc này, kết hợp với hỗ trợ bản địa cho các biểu thức JavaScript và quyền truy cập vào các API nội bộ và kho thông tin đăng nhập, khiến n8n trở thành một công cụ tự động hóa mạnh mẽ - nhưng cũng là một mục tiêu có giá trị cao khi xuất hiện các lỗ hổng bảo mật.
Kiến thức kỹ thuật
Cây cú pháp trừu tượng
Cây cú pháp trừu tượng (AST) là một biểu diễn theo cấu trúc phân cấp của mã nguồn do trình phân tích cú pháp tạo ra. Thay vì coi mã nguồn như một chuỗi văn bản phẳng, AST phân tách mã nguồn thành các nút có cấu trúc, đại diện cho các thành phần cú pháp của nó — khai báo biến, biểu thức hàm, biểu thức thành viên, định danh và hằng số.
Việc hiểu rõ các loại nút AST là điều thiết yếu cho phân tích này vì các biện pháp kiểm soát bảo mật của n8n hoạt động ở cấp độ AST. Các bộ lọc kiểm tra các loại nút cụ thể để phát hiện và chặn các mẫu mã nguy hiểm. Lỗ hổng này khai thác thực tế rằng cùng một thao tác ngữ nghĩa – truy cập thuộc tính của một đối tượng – có thể tạo ra các loại nút AST hoàn toàn khác nhau tùy thuộc vào cú pháp JavaScript được sử dụng.
Ví dụ, biểu thức `obj.constructor ` tạo ra một nút `MemberExpression`, trong khi `const { constructor } = obj` tạo ra một `VariableDeclaration` chứa một `ObjectPattern` với nút `Property`. Cả hai đều trích xuất cùng một thuộc tính, nhưng cấu trúc AST của chúng hoàn toàn khác nhau — và các bộ lọc của n8n chỉ kiểm tra mẫu đầu tiên.
Đánh giá biểu thức và kiến trúc bảo mật của n8n
Kiến trúc của n8n được tổ chức thành năm lớp: Frontend, CLI, Core, Workflow và Nodes. Lớp Workflow chịu trách nhiệm đánh giá biểu thức, đây chính là thành phần liên quan đến lỗ hổng bảo mật này.
n8n cho phép người dùng nhúng các biểu thức JavaScript vào các tham số của nút quy trình làm việc để thao tác dữ liệu một cách động. Các biểu thức này được đánh giá ở phía máy chủ bằng cách sử dụng thư viện có tên Tournament, thư viện này sẽ phân tích cú pháp các biểu thức thành một cây cú pháp trừu tượng (AST) trước khi thực thi. Các hàm kiểm tra an toàn được chèn trực tiếp vào quá trình tạo AST của Tournament, thực hiện các kiểm tra trong quá trình xây dựng AST để phát hiện và ngăn chặn các mẫu mã nguy hiểm trước khi bất kỳ đoạn mã nào được thực thi.
Vì các biểu thức này được thực thi trong cùng một tiến trình Node.js với máy chủ n8n, nền tảng này đã triển khai năm lớp bảo mật riêng biệt nhằm ngăn chặn mã không đáng tin cậy thoát ra khỏi môi trường cách ly.
Lớp 1 - Ghi đè bối cảnh toàn cục
Trước khi bất kỳ biểu thức nào được đánh giá, n8n sẽ tạo ra một bối cảnh thực thi bị giới hạn bằng cách ghi đè lên các đối tượng và hàm toàn cục tiềm ẩn rủi ro. Các thuộc tính như document, window, globalThis, eval, setTimeout, setInterval và Function sẽ được thay thế bằng các đối tượng rỗng, từ đó ngăn chặn việc truy cập trực tiếp vào các tính năng này.
Cách tiếp cận này có một hạn chế cố hữu: nếu kẻ tấn công có thể thoát khỏi bối cảnh bị giới hạn và tiếp cận đối tượng quá trình toàn cục thực sự, thì các thuộc tính đã bị ghi đè sẽ trở nên vô nghĩa.
Lớp 2 - Xác thực bằng biểu thức chính quy
Trước khi biểu thức được chuyển đến bộ đánh giá, n8n sẽ thực hiện kiểm tra biểu thức chính quy trên chuỗi biểu thức thô để chặn quyền truy cập vào thuộc tính constructor – một phương thức phổ biến để lấy đối tượng constructor của hàm Function và thực thi mã.
Biểu thức chính quy /\.\s*constructor/gm phát hiện việc truy cập thuộc tính .constructor bằng ký hiệu chấm. Tuy nhiên, việc kiểm tra này có hạn chế cơ bản vì JavaScript cung cấp nhiều cách cú pháp khác nhau để truy cập cùng một thuộc tính, và không phải tất cả các cách đó đều sử dụng ký hiệu chấm.
Lớp 3 - Công cụ kiểm tra an toàn thời gian chạy AST – PrototypeSanitizer
Hệ thống phòng thủ tinh vi nhất được kích hoạt trong quá trình xây dựng AST. Móc PrototypeSanitizer quét qua AST và kiểm tra các nút MemberExpression để xác định xem thuộc tính được truy cập có nằm trong danh sách chặn các thuộc tính đối tượng không an toàn hay không — bao gồm constructor, __proto__, prototype, mainModule và binding.
Bộ lọc xử lý ba trường hợp: ký hiệu chấm (obj.prop) – trong đó nó kiểm tra tên định danh, ký hiệu ngoặc vuông tĩnh (obj['prop']) – trong đó nó kiểm tra giá trị chuỗi nguyên văn, và các biểu thức động được bao bọc trong một hàm lọc thời gian chạy. Như được thể hiện trong Hình 10, chỉ các nút MemberExpression mới được kiểm tra – các mẫu giải cấu trúc không được duyệt qua.
Lớp 4 - Chức năng kiểm tra tính hợp lệ thời gian chạy AST: FunctionThisSanitizer
Được bổ sung dưới dạng bản vá trực tiếp cho lỗ hổng CVE-2025-68613, FunctionThisSanitizer chặn các Biểu thức hàm được gọi ngay lập tức (IIFE) và viết lại chúng để gán `this` vào một đối tượng rỗng. Điều này ngăn chặn kỹ thuật được sử dụng trong mã khai thác ban đầu, trong đó (function(){ return this })() đã làm rò rỉ đối tượng quá trình toàn cục thông qua tham chiếu `this` chưa được gán.
Điều quan trọng là, trình khử trùng này chỉ xử lý các nút FunctionExpression. Nó sẽ ngừng xử lý ngay lập tức đối với bất kỳ đối tượng được gọi nào không phải là FunctionExpression, bao gồm cả các hàm mũi tên.
Các thuộc tính nguy hiểm như `eval`, `Function` và `process.mainModule` sẽ bị xóa hoặc ghi đè trong bối cảnh thực thi, nhằm ngăn chặn việc truy cập trực tiếp vào các nguyên thủy thực thi mã ngay cả khi các lớp trước đó bị bỏ qua.
Phân tích lỗ hổng bảo mật bảo mật
Nguyên nhân gốc rễ
Nguyên nhân gốc rễ của lỗ hổng CVE-2026-25049 nằm ở một giả định chung giữa cả năm lớp bảo mật: mỗi lớp đều cho rằng việc truy cập thuộc tính sẽ diễn ra thông qua ký hiệu chấm (obj.constructor) hoặc ký hiệu ngoặc vuông (obj['constructor']). Không lớp nào tính đến cú pháp giải cấu trúc trong JavaScript.
Việc giải cấu trúc trong JavaScript cho phép trích xuất các thuộc tính từ các đối tượng bằng cách sử dụng một cấu trúc AST hoàn toàn khác biệt:
// Traditional access - produces MemberExpression node
obj.constructor; // Blocked by regex, AST sanitizer, and runtime checks
// Destructuring - produces ObjectPattern → Property node
const { constructor } = obj; // Not checked by any layer
Mặc dù cả hai mẫu đều cho kết quả giống nhau, chúng lại tạo ra các biểu diễn AST hoàn toàn khác nhau. PrototypeSanitizer chỉ kiểm tra các nút MemberExpression, còn biểu thức chính quy chỉ khớp với các mẫu .constructor. Các phép gán giải cấu trúc tạo ra các nút VariableDeclaration → ObjectPattern → Property, mà không có trình kiểm tra nào đi qua.
Tình trạng này càng trở nên nghiêm trọng hơn do cách n8n xử lý các hàm mũi tên. FunctionThisSanitizer chỉ chặn các nút FunctionExpression và viết lại chúng để ràng buộc `this` vào một bối cảnh an toàn. Các hàm mũi tên tạo ra các nút AST ArrowFunctionExpression, mà trình kiểm tra an toàn không xử lý. Do các hàm mũi tên kế thừa `this` từ phạm vi bao quanh (`this` ngữ cảnh), chúng cho phép truy cập vào bối cảnh toàn cục chưa được kiểm tra an toàn.
Khi kết hợp lại, hai sơ suất này dẫn đến việc hoàn toàn bỏ qua cơ chế kiểm tra: việc giải cấu trúc trích xuất hàm tạo Function mà không kích hoạt bất kỳ kiểm tra truy cập thuộc tính nào, và các hàm mũi tên cung cấp một bối cảnh thực thi mà FunctionThisSanitizer không thể chặn lại.
Khai thác
Lỗ hổng này kết hợp cả hai lỗ hổng để xâm nhập đồng thời vào mọi lớp bảo mật. Các đồng nghiệp của chúng tôi đã xác định được lộ trình khai thác như sau:
Bước 1 - Đăng ký hàm mũi tên. Mã độc bắt đầu bằng một hàm mũi tên được bao bọc trong một Biểu thức hàm được gọi ngay lập tức (IIFE):
={{(() => {
// Hàm mũi tên - bỏ qua FunctionThisSanitizer
...
})()}}
Hàm FunctionThisSanitizer kiểm tra xem đối tượng được gọi có phải là FunctionExpression hay không; do đây là một ArrowFunctionExpression, trình kiểm tra sẽ kết thúc sớm mà không thực hiện việc viết lại lệnh gọi. Hàm mũi tên được thực thi với quyền truy cập đầy đủ vào bối cảnh toàn cục thực sự.
Bước 2 - Bỏ qua quá trình giải cấu trúc. Bên trong hàm mũi tên, quá trình giải cấu trúc sẽ trích xuất đối tượng Function từ một thực thể hàm mũi tên:
const { constructor } = () => {};
Vì đây là một phép gán giải cấu trúc, nên AST chứa nút ObjectPattern thay vì MemberExpression. Kiểm tra biểu thức chính quy không phát hiện thấy mẫu .constructor, và PrototypeSanitizer không bao giờ kiểm tra tên thuộc tính. Kẻ tấn công hiện đang nắm giữ một tham chiếu đến hàm tạo Function.
Bước 3 - Thực thi mã động. Sau khi có được hàm tạo Function, kẻ tấn công sẽ tạo và thực thi mã tùy ý:
return constructor(
'return process.mainModule.require("child_process").execSync("whoami").toString()',
)();
Hàm được tạo động này chạy bên ngoài bối cảnh sandbox và có quyền truy cập đầy đủ vào đối tượng quá trình Node.js, cho phép thực thi các lệnh hệ thống tùy ý trên máy chủ.
Bằng chứng về tính khả thi
Để minh họa tác động thực tế của lỗ hổng này, các thành viên trong nhóm của chúng tôi đã tái hiện kịch bản khai thác trong một môi trường phòng thí nghiệm được kiểm soát. Kịch bản tấn công bao gồm việc triển khai một phiên bản n8n có lỗ hổng và nhập một quy trình làm việc chứa mã độc trong tham số của nút — cụ thể là nhắm vào nút "Edit Fields", vốn cho phép đánh giá biểu thức.
Khi quy trình làm việc được kích hoạt, mã độc sẽ vượt qua cả năm lớp lọc và thực thi một reverse shell trên máy chủ, trao lại toàn bộ khả năng thực thi lệnh cho kẻ tấn công.
Lỗ hổng leo thang qua Webhook dẫn đến RCE không cần xác thực
Mức độ nghiêm trọng của lỗ hổng này gia tăng đáng kể khi kết hợp với tính năng webhook của n8n. n8n cho phép các quy trình làm việc (workflow) phơi bày các điểm cuối HTTP dưới dạng webhook với các tùy chọn xác thực có thể cấu hình, bao gồm token bearer, xác thực cơ bản và – đặc biệt nguy hiểm – không yêu cầu xác thực nào cả. Một kẻ tấn công có quyền truy cập để tạo quy trình làm việc có thể cấu hình một webhook công khai với tùy chọn xác thực là "none", nhúng payload RCE vào một nút được kết nối và kích hoạt quy trình làm việc. Lúc đó, bất kỳ yêu cầu HTTP nào đến URL webhook - từ bất kỳ đâu trên internet - đều kích hoạt việc thực thi lệnh tùy ý trên máy chủ chủ.
Quá trình leo thang này biến lỗ hổng CVE-2026-25049 từ một lỗ hổng nội bộ yêu cầu xác thực thành một phương thức tấn công thực tế không cần xác thực và có khả năng ảnh hưởng trên toàn mạng Internet.
Sự làm dịu
Nhóm phát triển n8n đã khắc phục lỗ hổng CVE-2026-25049 trong các phiên bản 1.123.17 và 2.5.2 bằng cách triển khai cơ chế kiểm tra kiểu dữ liệu tại thời điểm chạy trong các hàm làm sạch dữ liệu và mở rộng phạm vi kiểm tra AST để xử lý các mẫu giải cấu trúc. Các tổ chức đang sử dụng các phiên bản bị ảnh hưởng nên tiến hành cập nhật ngay lập tức.
Nếu không thể nâng cấp ngay lập tức, các quản trị viên nên giới hạn quyền tạo và chỉnh sửa quy trình làm việc chỉ dành cho những người dùng được tin cậy hoàn toàn, đồng thời triển khai n8n trong một môi trường được bảo mật chặt chẽ với các đặc quyền hệ điều hành và quyền truy cập mạng bị hạn chế.
Do mức độ nghiêm trọng cao và khả năng bị khai thác dễ dàng – đặc biệt khi kết hợp với các webhook công khai – các tổ chức cũng nên rà soát các quy trình làm việc hiện có để phát hiện các biểu thức đáng ngờ, theo dõi việc thực thi các lệnh hệ thống bất thường xuất phát từ tiến trình n8n, đồng thời kiểm tra cấu hình webhook để phát hiện các điểm cuối bị lộ mà không có xác thực.
Giảm thiểu rủi ro với OPSWAT
Bằng cách tận dụng OPSWAT , các tổ chức có thể nhanh chóng xác định các thành phần n8n dễ bị tấn công trong hạ tầng của mình và thực hiện các biện pháp ứng phó trước khi lỗ hổng bị khai thác. OPSWAT , một công nghệ nền tảng trong nền tảng MetaDefender®, cung cấp danh mục toàn diện về tất cả các thành phần phần mềm, thư viện và các phụ thuộc đang được sử dụng trong môi trường của tổ chức.
Như thể hiện trong Hình 15, MetaDefender đã quét tệp package.json chứa phụ thuộc n8n và tự động đánh dấu CVE-2026-25049 là mức Nguy hiểm, đồng thời hiển thị phạm vi phiên bản bị ảnh hưởng cùng các phiên bản đã được vá lỗi được khuyến nghị để khắc phục. Điều này giúp các nhóm bảo mật nhanh chóng xác định và ưu tiên xử lý lỗ hổng bảo mật trên toàn bộ môi trường triển khai của họ.
OPSWAT được tích hợp trong MetaDefender và MetaDefender Software Chain™, giúp các đội ngũ an ninh có thể:
- Nhanh chóng xác định các thành phần dễ bị tấn công - Ngay lập tức xác định các phụ thuộc mã nguồn mở bị ảnh hưởng bởi các lỗ hổng thoát khỏi môi trường cách ly và thực thi mã, từ đó cho phép khắc phục hoặc loại bỏ kịp thời.
- Đảm bảo việc vá lỗi và cập nhật chủ động - Liên tục theo dõi các thành phần mã nguồn mở để phát hiện các gói phần mềm đã lỗi thời hoặc không an toàn, từ đó thực hiện cập nhật kịp thời và giảm thiểu rủi ro.
- Đảm bảo tuân thủ và báo cáo - Đáp ứng các yêu cầu pháp lý khi các khung quy định ngày càng yêu cầu tính minh bạch trong chuỗi cung ứng phần mềm.
Tham khảo
- NVD - CVE-2026-25049
- Thông báo bảo mật n8n - GHSA-6cqr-8cfr-67f8
- n8n RCE(s): Câu chuyện 4 hồi - Fatih Çelik
- Phân tích sâu về lỗ hổng CVE-2026-25049 - SecureLayer7
- Lỗ hổng thoát khỏi chuỗi biểu thức CVE-2026-25049 dẫn đến thực thi mã từ xa (RCE) trong n8n - Endor Labs
- Thông báo bảo mật của n8n - CVE-2025-68613 (GHSA-v98v-ff95-f3cp)
