Khi log ra, dữ liệu hiển thị sai.
Không phải lỗi gas. Không phải lỗi reentrancy. Một endpoint tên /api/v1/auto_login trả về SUPERUSER token mà không cần bất kỳ thông tin xác thực nào. Tiếp theo, /api/v1/validate/code gọi exec() để chạy Python code trực tiếp. Hai endpoint này nằm trong cùng một instance Langflow – một nền tảng AI Agent mã nguồn mở – và chúng hoạt động như một chiếc chìa khóa vạn năng mở vào toàn bộ hệ thống.
Tôi đã dành 12 năm quan sát các lỗ hổng bảo mật trong hệ sinh thái phi tập trung. Nhưng CVE-2026-9198 không chỉ là một lỗi code thông thường. Đây là một lời thú nhận về kiến trúc: AI Agent đang được xây dựng như những chiếc két sắt có cửa sau mặc định.
Trong bảy ngày qua, khi tôi đọc báo cáo của Sysdig về chiến dịch JadePuffer, tôi nhận ra một điều: kẻ tấn công không cần phá khóa. Chúng chỉ cần bước qua cánh cửa mà chính nhà phát triển đã để ngỏ.
Bối cảnh: Khi AI Agent Trở Thành Két Sắt Không Khóa
Langflow, một nền tảng low-code để xây dựng các tác nhân AI (AI Agent), đã được IBM mua lại. Khoảng 7.000 instance Langflow đang phơi bày trên internet, mỗi instance là một trung tâm điều khiển chứa API keys của các mô hình ngôn ngữ lớn (LLM), thông tin xác thực đám mây, và mật khẩu cơ sở dữ liệu.
Trong 18 tháng qua, Langflow đã hứng chịu ít nhất bảy lỗ hổng nghiêm trọng, tất cả đều có CVSS từ 9.3 đến 9.9. Tất cả đều dẫn đến cùng một gốc rễ: thực thi mã động không có sandbox. CVE-2025-3248, CVE-2026-0770, CVE-2026-33017, CVE-2026-33309, CVE-2026-55255 – tất cả đều là những biến thể của cùng một vấn đề.
Điều đáng chú ý là chiến dịch JadePuffer đã tận dụng lỗ hổng này để đánh cắp dữ liệu từ PostgreSQL, di chuyển ngang sang MySQL sản xuất, và triển khai ransomware. Một chuỗi tấn công từ một endpoint không xác thực.
Phân tích kỹ thuật: Mổ xẻ chuỗi tấn công
Hãy nhìn vào kiến trúc thực tế. Langflow thiết kế để cho phép người dùng tùy chỉnh logic bằng Python code. Điều này không phải là vấn đề. Vấn đề là code đó chạy trong cùng một tiến trình, cùng một môi trường, nơi lưu trữ tất cả thông tin xác thực nhạy cảm.
Tôi đã fork mã nguồn Uniswap v1 vào năm 2020, deploy lên testnet Ropsten, và học được rằng bảo mật không phải là một tính năng – nó là một ràng buộc thiết kế. Nếu bạn đặt chức năng lên trên an toàn, bạn sẽ nhận được một hệ thống hoạt động nhưng không thể tin cậy.
Langflow đã làm điều tương tự. Họ đặt auto_login endpoint vào sản phẩm để đơn giản hóa quá trình demo. Họ đặt exec() để cho phép người dùng tùy biến linh hoạt. Kết quả: một hệ thống nơi bất kỳ ai trên internet đều có thể trở thành quản trị viên.
CVE-2026-33017 bị khai thác chỉ 20 giờ sau khi được công bố. Con số này cho thấy điều gì? Không phải kẻ tấn công quá nhanh. Mà là các công cụ khai thác quá dễ dàng. Chỉ cần một request HTTP với payload nhỏ, bạn có thể chiếm quyền điều khiển toàn bộ pipeline AI của một doanh nghiệp.
Hãy so sánh với các nền tảng workflow trưởng thành hơn như n8n hay Microsoft Power Automate. Họ giải quyết vấn đề thực thi mã tùy chỉnh bằng sandbox container, hoặc tách biệt môi trường chạy code khỏi nơi lưu trữ thông tin xác thực. Langflow không làm điều này.
Điểm mù bảo mật: Vấn đề không nằm ở Langflow
Bạn có thể nghĩ rằng đây chỉ là câu chuyện của một dự án mã nguồn mở kém may mắn. Nhưng hãy nhìn rộng hơn. Khi Azure SRE Agent và ChatMate trên Microsoft 365 Copilot cũng bị phát hiện có lỗ hổng RCE tương tự, chúng ta đang đối mặt với một mô hình phổ biến trong toàn ngành.
AI Agent không phải là một ứng dụng web thông thường. Nó là một trung tâm điều phối – nơi hội tụ quyền truy cập vào mọi hệ thống. Nó giống như một người quản trị hệ thống có chìa khóa vào mọi phòng. Nhưng hầu hết các nền tảng này đều được bảo mật theo tiêu chuẩn của một ứng dụng demo nội bộ.
Khi tôi audit hợp đồng thông minh, tôi luôn kiểm tra xem một hàm có thể được gọi bởi ai, với những tham số nào, và hậu quả là gì. Với AI Agent, các nhà phát triển dường như quên mất nguyên tắc cơ bản này. Họ kiểm tra xem Agent có làm đúng việc không, nhưng không kiểm tra xem Agent có bị biến thành công cụ tấn công hay không.
Điều quan trọng hơn: chiến dịch JadePuffer không chỉ là một mối đe dọa với Langflow. Nó là một mô hình tấn công mới. Kẻ tấn công không cần phải khai thác lỗ hổng trong hợp đồng thông minh hay giao thức DeFi. Chúng chỉ cần tấn công vào lớp điều phối – nơi mà các token, khóa và quyền truy cập được tập trung hóa.
Tác động đến blockchain và triển vọng bảo mật
Trong thế giới blockchain, chúng ta đã quen với khái niệm "không tin tưởng, phải xác minh" (don't trust, verify). Nhưng khi AI Agent tham gia vào hệ sinh thái phi tập trung, chúng thường được xem như một hộp đen. Agent có quyền truy cập vào ví, vào các hợp đồng thông minh, và vào các oracle.
Nếu một Agent bị chiếm quyền điều khiển, kẻ tấn công có thể thao túng toàn bộ chuỗi hoạt động: từ việc đọc dữ liệu, gửi giao dịch, cho đến việc thay đổi cấu hình. Điều này tạo ra một vectơ tấn công mới mà các giao thức blockchain chưa từng phải đối mặt.
CISA đã thêm CVE-2026-9198 vào danh sách Known Exploited Vulnerabilities và yêu cầu các cơ quan liên bang vá lỗi trước ngày 7 tháng 8. Điều này cho thấy mức độ nghiêm trọng không chỉ ở cấp độ công nghệ mà còn ở cấp độ chính sách.
Nhưng sự thật đáng lo ngại nhất: hầu hết các tổ chức sử dụng Langflow vẫn chưa vá lỗi. Và ngay cả khi họ vá, vấn đề gốc rễ vẫn chưa được giải quyết. Chúng ta đang chứng kiến một mô hình "vá lỗi theo kiểu đập búa đuổi ruồi" – vá từng endpoint, nhưng không thay đổi kiến trúc.
Kiến nghị: Xây dựng Agent như một hệ thống quan trọng
AI Agent nên được đối xử như một hệ thống xác thực danh tính, không phải như một ứng dụng web. Khi bạn xây dựng một hệ thống xác thực, bạn phân tách rõ ràng giữa vùng tin cậy và vùng không tin cậy. Bạn mã hóa dữ liệu nhạy cảm. Bạn thiết lập các biện pháp kiểm soát truy cập nhiều lớp.
Điều này có nghĩa là gì cho các nhà phát triển blockchain? Chúng ta cần yêu cầu rằng bất kỳ AI Agent nào tương tác với blockchain đều phải có:
- Môi trường thực thi cô lập: Mỗi tác nhân chạy trong một sandbox hoặc container riêng biệt, không có quyền truy cập trực tiếp vào hệ thống tệp hoặc mạng nội bộ.
- Kho lưu trữ khóa tách biệt: Sử dụng các giải pháp như Vault hoặc HSM để lưu trữ khóa riêng tư, không bao giờ lưu khóa trong cùng một cơ sở dữ liệu với mã ứng dụng.
- Xác thực đa lớp: Không có bất kỳ endpoint nào có thể được truy cập mà không cần xác thực. Không có "demo mode" trong sản xuất.
Tôi đã học được từ vụ hack Parity năm 2017 rằng một lỗi nhỏ như một hàm khởi tạo không được bảo vệ có thể khóa 150.000 ETH mãi mãi. Với AI Agent, một lỗi tương tự có thể không chỉ khóa tài sản – nó có thể đánh cắp toàn bộ quyền truy cập của một tổ chức.
Khi tôi triển khai oracle AI trên zkVM vào năm 2025, tôi nghiệm ra rằng sự tin cậy không đến từ việc code hoạt động đúng – mà đến từ việc code không thể bị lạm dụng khi hoạt động sai. Các lỗ hổng của Langflow đã phá vỡ nguyên tắc này.
Bài toán không chỉ là vá lỗi. Bài toán là thiết kế lại cách chúng ta xây dựng AI Agent – với giả định rằng chúng sẽ bị tấn công, sẽ bị xâm nhập, và sẽ nằm trong tay kẻ thù. Khi đó, câu hỏi duy nhất còn lại là: liệu hệ thống của bạn có đứng vững khi toàn bộ quyền lực nằm trong tay kẻ xấu?
Câu trả lời cho câu hỏi đó, dựa trên bằng chứng từ JadePuffer, là không.
Nhưng điều đó có thể thay đổi. Bắt đầu từ bây giờ.
