Ngày 4 tháng 8, CISA thêm CVE-2026-9198 vào danh sách Known Exploited Vulnerabilities. Hạn chót vá lỗ hổng: 7 tháng 8. Tôi lướt lại Shodan hôm nay, vẫn thấy hàng trăm instance Langflow mở cổng 7860 với giao diện login chễm chệ. Kẻ tấn công không cần mật khẩu. Chúng chỉ cần gọi một endpoint. Và đó không phải là một bug. Đó là một thiết kế.
Không phải mọi lỗ hổng đều giống nhau. Nhưng khi một nền tảng AI Agent ghi nhận bảy CVE nghiêm trọng trong 18 tháng, tất cả đều trỏ về cùng một root cause, thì đã đến lúc ngừng gọi đó là "sự cố" và bắt đầu gọi đúng tên: thất bại kiến trúc.
Nếu đây là một hợp đồng thông minh, nó đã bị từ chối trong vòng audit đầu tiên.
Ngữ cảnh: Langflow là gì và vì sao nó quan trọng?
Langflow là một nền tảng AI Agent mã nguồn mở, cho phép người dùng kéo-thả xây dựng các luồng làm việc AI mà không cần viết nhiều code. Nghe quen quen đúng không? Nó giống Zapier nhưng dành riêng cho các tác vụ LLM. Người dùng nối các block: một block gọi GPT, một block truy vấn PostgreSQL, một block gửi email. Mọi thứ trực quan, nhanh, và chết người ở chỗ nền tảng phải giữ hộ bạn mọi loại chìa khoá: API key của OpenAI, mật khẩu database, credential của cloud.
Điểm khác biệt quan trọng: IBM đã mua lại Langflow. Do đó, không ai nghĩ nó sẽ trở thành một "con ngựa thành Troy" ngay trong trung tâm dữ liệu của doanh nghiệp.
Nhưng thực tế ngược lại. Trong 18 tháng, Langflow dính liên tiếp các lỗ hổng với CVSS từ 9.3 đến 9.9. CVE-2025-3248, CVE-2026-0770, CVE-2026-33017, CVE-2026-33309, CVE-2026-55255, và CVE-2026-9198. Mỗi lỗ hổng là một đường code execution. Mỗi lần vá xong, một lỗ hổng khác xuất hiện. Và giữa chúng có một điểm chung: AI Agent có thể thực thi mã Python một cách linh hoạt, nhưng không có sandbox bao quanh.
Không phải AI quá thông minh nên nguy hiểm. Mà là AI Agent được đặt ngay cạnh két sắt mà không có rào chắn.
Phân tích cốt lõi: Khi thiết kế trở thành vũ khí
Hãy nhìn vào chuỗi tấn công của CVE-2026-9198. Đầu tiên, kẻ tấn công gửi một request tới /api/v1/auto_login. Endpoint này trả về token SUPERUSER mà không cần bất kỳ xác thực nào. Bước thứ hai, dùng token đó gọi /api/v1/validate/code. Endpoint này nhận đoạn mã Python do kẻ tấn công cung cấp và thực thi nó qua hàm exec(). Kết thúc. Bạn không cần khai thác gì phức tạp. Bạn chỉ cần đọc tài liệu API.
Và đây mới là điều đáng sợ: auto_login không phải là một lỗi vô tình. Nó là một endpoint được cố ý đưa vào, có thể phục vụ mục đích demo nhanh hoặc onboarding. Nó tồn tại trong source code, không bị chặn ở production, và được đặt cùng tầng mạng với endpoint thực thi mã. Đó là một quyết định thiết kế ưu tiên sự thuận tiện hơn an toàn.
Các nền tảng workflow trưởng thành như n8n hay Zapier xử lý vấn đề code execution theo cách khác: hoặc chạy trong VM/container tách biệt, hoặc yêu cầu người dùng cấu hình quyền nâng cao một cách tường minh. Còn Langflow cho phép code execution nằm cùng vùng tin cậy với database password của khách hàng. Một lần RCE, bạn không chỉ lấy được API key của LLM, bạn lấy được toàn bộ thông tin xác thực mà nền tảng đang lưu trữ.
Đây chính là vụ Mt. Gox của thế giới AI Agent.
Nhưng khoan. Vụ JadePuffer mà Sysdig công bố còn đáng ngại hơn. Kẻ tấn công bắt đầu từ một instance Langflow không vá lỗ hổng, sau đó trích xuất toàn bộ database PostgreSQL của nền tảng, lấy được API key của LLM, credential cloud và khoá ví tiền mã hoá, rồi dùng chúng để di chuyển ngang sang production MySQL và Nacos. Cuối cùng, chúng mã hoá toàn bộ và đòi tiền chuộc.
Toàn bộ chuỗi tấn công chỉ mất vài giờ, và điểm khởi đầu chỉ là một endpoint không có xác thực.
Có một sự mỉa mai ở đây: thị trường AI Agent đang tăng tốc điên cuồng. Các quỹ đầu tư đổ tiền vào mọi nền tảng có chữ "Agent" trong tên. Nhà phát triển chen nhau xây dựng các tác nhân AI có thể tự động gọi API, ký giao dịch, và quản lý ví. Nhưng nền móng mà họ đặt lên thì đang nứt toác. Tôi đã kiểm tra một số nền tảng Agent phổ biến khác như Flowise hay Dify trong các bài audit trước đây. Cùng một kiểu mô hình: code execution endpoint, lưu trữ secret tập trung, thiếu sandbox. Khác tên, cùng một DNA.
Đừng hỏi liệu nền tảng của bạn có bị tấn công hay không. Hãy hỏi: nếu nó bị tấn công, kẻ tấn công sẽ đi được bao xa?
Góc nhìn ngược: Đây không phải vấn đề của AI, mà là vấn đề của quyền hạn
Phần lớn giới công nghệ đang bị ám ảnh bởi "AI alignment" – làm sao để mô hình không nói điều sai trái. Trong khi đó, kẻ tấn công thực tế không thèm quan tâm model nói gì. Chúng chỉ cần một lỗ hổng để đạt được quyền thực thi. Sự thật phũ phàng: model alignment không cứu được bạn khi attacker đã có token SUPERUSER trong tay.
Cộng đồng blockchain đã học được bài học này từ lâu. Chúng ta biết rằng một smart contract có logic hoàn hảo vẫn có thể bị drain toàn bộ nếu hàm withdraw không kiểm tra quyền sở hữu. Chúng ta gọi đó là lỗi access control. Vậy mà khi chuyển sang AI Agent, chúng ta lại dễ dãi hơn nhiều.
AI Agent không phải là một ứng dụng web thông thường. Nó là một lớp phần mềm được cấp quyền truy cập vào các hệ thống khác: cơ sở dữ liệu, API bên thứ ba, cloud, và thậm chí cả ví tiền mã hoá. Nó gần giống một hợp đồng thông minh hơn là một website. Và giống như smart contract, một khi nó được triển khai, mọi lỗ hổng trong nó đều trở thành cửa trước cho kẻ tấn công.
Câu chuyện Langflow còn cho thấy một điểm mù khác: việc IBM mua lại một dự án mã nguồn mở không tự động biến nó thành phần mềm cấp doanh nghiệp. Nhãn hiệu lớn chỉ hữu ích trên slide bán hàng. Còn trên thực tế, khi lỗ hổng thứ bảy xuất hiện, không có kiến trúc mới, chỉ có các bản vá chắp vá. Điều này giống hệt những gì chúng ta thấy trong các dự án crypto được hậu thuẫn bởi quỹ đầu tư lớn: nhiều tiền, nhiều marketing, nhưng không có một quy trình bảo mật nghiêm túc.
Và giờ đến phần khiến tôi thực sự lo lắng: các nhóm ransomware đã phát hiện ra rằng tấn công một AI Agent platform còn có lợi hơn nhiều so với tấn công một máy chủ thông thường. Bởi vì chỉ cần một lần xâm nhập, bạn không chỉ có được dữ liệu, bạn có được chìa khoá của mọi hệ thống mà agent đó kết nối tới.
Bảy nghìn instance phơi bày trên internet không phải là một con số thống kê vô nghĩa. Đó là bảy nghìn ổ khoá treo trước cửa nhà của các doanh nghiệp, và chìa khoá vạn năng thì đã được đăng tải công khai.
Một số người sẽ nói rằng vấn đề chỉ nằm ở các nền tảng mã nguồn mở nhỏ. Nhưng hãy nhớ rằng Microsoft 365 Copilot cũng từng bị phơi bày lỗ hổng RPE, và Azure SRE Agent cũng có lúc gặp sự cố. Vấn đề không nằm ở quy mô hay thương hiệu. Nó nằm ở việc ngành công nghiệp này vẫn coi AI Agent như một "công cụ nội bộ" trong khi thực tế nó đã trở thành một hệ thống lưu trữ bí mật quan trọng.
Hãy tự hỏi: nếu agent của bạn có thể truy cập vào khoá riêng tư, tại sao nó lại không được bảo vệ nghiêm ngặt như ví lạnh của bạn?
Điều cần làm ngay bây giờ
Bạn không cần phải đợi đến khi IBM phát hành bản vá tiếp theo. Bạn cũng không nên tin rằng "nền tảng của chúng tôi an toàn vì chúng tôi có đội ngũ bảo mật". Hãy dành một buổi chiều để tự kiểm tra: Nền tảng Agent bạn đang dùng có cho phép thực thi mã Python không? Nó có lưu secret ở dạng phẳng trong database không? Nó có endpoint không yêu cầu xác thực không? Nếu câu trả lời là "có" cho bất kỳ câu nào, bạn đang nắm một quả lựu đạn chưa rút chốt.
Các tổ chức lớn nên bắt đầu đối xử với AI Agent như một thành phần quan trọng trong kiến trúc bảo mật của họ. Nếu bạn có một agent có thể truy cập vào cơ sở dữ liệu sản xuất, bạn cần giám sát hành vi của nó như giám sát một nhân viên có quyền quản trị hệ thống. Không phải là một đoạn script chạy nền.
Tôi đã thấy quá nhiều dự án crypto bị tấn công chỉ vì một chi tiết nhỏ: một file .env bị lộ, một API key bị đẩy lên GitHub, một endpoint debug không bị vô hiệu hoá. Langflow chỉ là phiên bản AI của cùng một câu chuyện đó. Nhưng quy mô thiệt hại thì lớn hơn rất nhiều.
Khi mọi người nhìn thấy một công cụ mới giúp họ kiếm tiền nhanh hơn, tôi nhìn thấy một cánh cửa mới để kẻ tấn công bước vào. Trong một thị trường tăng, sự hưng phấn che giấu lỗi kỹ thuật. Và những lỗi này chỉ bị phát hiện khi bạn đã mất thứ gì đó.
Bạn có dám chắc rằng agent của bạn không phải là một Langflow đang chờ bị khai thác?