Các tác nhân AI của bạn đang hoạt động đúng như thiết kế, nhưng các framework nền tảng lại vô tình trao quyền kiểm soát cho kẻ tấn công, mở đường truy cập vào khóa OpenAI, thông tin đăng nhập cơ sở dữ liệu và token CRM của bạn.
Đây không phải là giả thuyết. Chỉ trong vài tháng, ba trong số các framework tác nhân AI được triển khai rộng rãi nhất đã biến những lỗi thông thường thành những cánh cửa đột nhập nguy hiểm. Check Point Research đã phát hiện lỗ hổng SQL injection trong bộ kiểm soát SQLite của LangGraph dẫn đến thực thi mã từ xa (RCE) hoàn toàn. Tenable và VulnCheck theo dõi một lỗi Path Traversal trong điểm cuối tải tệp của Langflow, cũng dẫn đến RCE đang bị khai thác trong thực tế. Cyera đã ghi nhận một lỗi Path Traversal khác trong bộ nạp prompt của LangChain-core, cho phép đọc bí mật từ đĩa. Hai con đường dẫn đến quyền kiểm soát hệ thống, một con đường dẫn đến các khóa bảo mật của bạn. Đáng chú ý, đây đều là cùng một loại lỗi, chỉ xuất hiện dưới ba hình thức framework khác nhau. 😱
Những framework này đã trở thành cơ sở hạ tầng sản xuất nhanh hơn bất kỳ ai có thể bảo mật chúng. Chúng lưu trữ trạng thái tác nhân, xử lý các tệp tải lên, tải cấu hình prompt và giữ thông tin đăng nhập đến cơ sở dữ liệu, CRM cũng như các API nội bộ. Các công cụ giám sát lưu lượng và quy trình không được xây dựng để coi một framework được nhập khẩu là một ranh giới cần bảo vệ, và chính điểm mù này là nơi ba chuỗi lỗ hổng này tồn tại, ngày càng mở rộng mỗi tuần khi các framework này được đưa vào sản xuất. 🚧
Chuỗi lỗ hổng LangGraph: Từ SQL Injection đến Python Shell
LangGraph cấp cho các tác nhân AI khả năng ghi nhớ thông qua các bộ kiểm soát (checkpointers) – lớp lưu trữ trạng thái thực thi. Framework này đã vượt mốc 50 triệu lượt tải xuống mỗi tháng. Yarden Porat của Check Point Research đã phân tích lớp này và tìm thấy ba lỗ hổng, hai trong số đó có thể dẫn đến RCE. 💣
CVE-2025-67644 (CVSS 7.3) là một lỗ hổng SQL injection trong bộ kiểm soát SQLite. Hàm xây dựng mệnh đề WHERE cho các tra cứu checkpoint đã đưa các khóa bộ lọc do người dùng kiểm soát trực tiếp vào truy vấn mà không có tham số hóa hoặc thoát ký tự. Lỗ hổng này không ảnh hưởng đến tất cả mọi người, nhưng khi nó tấn công, hậu quả sẽ rất nghiêm trọng. Một hệ thống sẽ bị phơi nhiễm nếu tự host LangGraph trên bộ kiểm soát SQLite hoặc Redis và cho phép đầu vào không đáng tin cậy tiếp cận get_state_history() hoặc các điểm cuối lịch sử tương tự. Khi các điều kiện này được đáp ứng, kẻ tấn công có thể kiểm soát bộ lọc để ghi một hàng dữ liệu giả mạo trực tiếp vào bảng checkpoint. Nếu chạy nền tảng LangSmith được quản lý của LangChain trên PostgreSQL, lỗ hổng này sẽ không tồn tại.
Sau đó, CVE-2026-28277 (CVSS 6.8) hoàn thành công việc. Bộ giải mã checkpoint msgpack của LangGraph xây dựng lại các đối tượng Python từ dữ liệu đã lưu trữ, cho phép nhập một module và gọi một hàm được chỉ định với các đối số do kẻ tấn công cung cấp. Bước này cần quyền ghi vào kho lưu trữ checkpoint; SQL injection chính là thứ cấp quyền đó từ xa. LangGraph tải hàng giả mạo như một checkpoint hợp lệ, bộ giải mã chạy hàm được chỉ định, bao gồm cả os.system, và mã độc sẽ được thực thi dưới danh tính của máy chủ tác nhân. Một vấn đề thứ ba, CVE-2026-27022 (CVSS 6.5), cũng dẫn đến kết quả tương tự thông qua bộ kiểm soát Redis.
Hiện chưa có báo cáo khai thác nào được xác nhận trong thực tế, nhưng bằng chứng khai thác (PoC) đã được công khai trong thông báo của Check Point. Các bản vá lỗi yêu cầu nâng cấp phiên bản: langgraph-checkpoint-sqlite lên 3.0.1, langgraph lên 1.0.10, và langgraph-checkpoint-redis lên 1.0.2. 🛠️
Chuỗi lỗ hổng Langflow: Một yêu cầu không xác thực dẫn đến RCE
Langflow là framework đang bị tấn công trong thực tế. CVE-2026-5027 (CVSS 8.8) là một lỗ hổng Path Traversal trong điểm cuối POST /api/v2/files, nhận tên tệp trực tiếp từ dữ liệu form và ghi vào đĩa mà không được làm sạch. Kẻ tấn công có thể chèn các chuỗi Path Traversal vào tên tệp và thả một tệp bất kỳ, chẳng hạn như một cron job vào /etc/cron.d/. Vì Langflow được xuất xưởng với tính năng tự động đăng nhập (auto-login) được bật theo mặc định, một phiên bản bị phơi nhiễm không cần bất kỳ thông tin đăng nhập nào. Một yêu cầu không xác thực duy nhất có thể tiếp cận điểm cuối, và lần chạy cron tiếp theo sẽ trao quyền kiểm soát hệ thống cho kẻ tấn công. 🚨
Caitlin Condon của VulnCheck đã xác nhận việc khai thác vào ngày 9 tháng 6: “Các Canary của chúng tôi đã quan sát thấy việc khai thác CVE-2026-5027 thành công tận dụng Path Traversal để ghi các tệp có vẻ là tệp thử nghiệm trên các hệ thống nạn nhân.” Censys ước tính có khoảng 7.000 phiên bản bị phơi nhiễm trên internet, hầu hết ở Bắc Mỹ. Đây là lỗi Langflow thứ ba bị khai thác trong thực tế trong năm nay, sau CVE-2025-34291 đã được nhóm MuddyWater do nhà nước Iran tài trợ vũ khí hóa và được CISA thêm vào danh mục Lỗ hổng bị khai thác đã biết (Known Exploited Vulnerabilities catalog) vào tháng 5. Bản thân CVE-2026-5027 đã được vá trong phiên bản 1.9.0, phát hành ngày 15 tháng 4.
Điều đáng nói là thời gian. Bản vá được phát hành ngày 15 tháng 4. Các cuộc tấn công bắt đầu vào tháng 6, và VulnCheck đã thêm CVE-2026-5027 vào danh sách lỗ hổng bị khai thác vào ngày 8 tháng 6 sau khi các cảm biến của họ phát hiện những đợt tấn công đầu tiên. Mọi phiên bản chưa được vá trong khoảng thời gian đó đã nằm trong tình trạng dễ bị tấn công gần hai tháng. Bài học cho các đội ngũ bảo mật là phải bắt đầu tính thời gian vá lỗi ngay khi thông tin được tiết lộ, chứ không phải đợi đến khi được đưa vào danh mục liên bang. ⏳
Khoảng trống LangChain-core: Đọc tệp tùy ý qua bộ nạp Prompt
LangChain-core, nền tảng của cả hai framework trên, đã tiết lộ CVE-2026-34070 (CVSS 7.5), một lỗ hổng Path Traversal trong API tải prompt cũ của nó. Các hàm load_prompt() đọc một đường dẫn tệp từ một dict cấu hình mà không kiểm tra các chuỗi Path Traversal hoặc đường dẫn tuyệt đối, do đó, kẻ tấn công có thể điều hướng đường dẫn đó để đọc các tệp tùy ý mà quy trình có thể tiếp cận, bao gồm tệp .env chứa OPENAI_API_KEY và ANTHROPIC_API_KEY. Cyera đã kết hợp nó với CVE-2025-68664 (CVSS 9.3), một lỗ hổng deserialization giải quyết các bí mật môi trường thông qua một đối tượng được tạo sẵn. Các phiên bản sửa lỗi khác nhau, điều này quan trọng khi bạn vá: CVE-2026-34070 nằm trong langchain-core 1.2.22 và 0.3.86; CVE-2025-68664 nằm sớm hơn trong 1.2.5 và 0.3.81. Phải vá cả hai, nếu không lỗ hổng nghiêm trọng hơn sẽ vẫn tồn tại phía sau một bản vá khác. 🔑
Ba framework, ba lỗi AppSec kinh điển: Path Traversal, SQL Injection, Deserialization không an toàn. Không có gì lạ lẫm, không có gì đặc trưng cho AI, chỉ là những lỗ hổng cũ kỹ đang tồn tại bên trong cơ sở hạ tầng mới. Đây không phải là vấn đề của các mô hình tiên phong. Đây là vấn đề về hệ thống, nằm ở lớp giao thoa giữa AI và doanh nghiệp. 💡
Tại sao máy quét không thể nhìn thấy nó?
Merritt Baer, CSO tại Enkrypt AI và cựu phó CISO tại AWS, đã chỉ ra lý do tại sao loại lỗi này khó phát hiện. Nó không tự nhận mình là vấn đề AI. "Các CISO sẽ trải nghiệm sự không an toàn của MCP không phải trên lý thuyết, mà khi một nhân viên dán dữ liệu nhạy cảm vào một công cụ, hoặc khi kẻ tấn công tìm thấy một máy chủ MCP không xác thực trong đám mây của bạn," Baer nói với VentureBeat. "Nó sẽ không giống 'rủi ro AI'. Nó sẽ giống như chương trình bảo mật truyền thống của bạn đang thất bại." Các chuỗi framework ở đây có hình dạng tương tự. Một phiên bản Langflow bị phơi nhiễm là một máy chủ không xác thực trong đám mây của bạn, và cảnh báo, nếu có, sẽ giống như một sự cố thông thường.
Đó là khoảng trống chỉ trong một câu. Mã khai thác nằm trong framework mà mã của bạn nhập. WAF không bao giờ thấy một bộ giải mã msgpack chạy ba lớp bên dưới. EDR quan sát máy chủ tác nhân thực hiện các cuộc gọi quy trình tương tự hàng nghìn lần mỗi ngày và bỏ qua. Cả hai công cụ đều đang làm đúng nhiệm vụ của mình. Không ai coi bản thân framework là thứ có thể quay lại tấn công bạn. 🎯
Nguyên nhân gốc rễ còn cũ hơn cả AI, và Baer đã gọi tên nó. “MCP đang được phát hành với cùng một lỗi mà chúng ta đã thấy trong mọi đợt triển khai giao thức lớn: các cài đặt mặc định không an toàn,” cô nói với VentureBeat. “Nếu chúng ta không xây dựng xác thực và đặc quyền tối thiểu ngay từ ngày đầu tiên, chúng ta sẽ phải dọn dẹp các vụ vi phạm trong thập kỷ tới.” Tính năng tự động đăng nhập của Langflow chính là lỗi đó. Bộ nạp prompt không được bảo vệ của LangChain-core chính là lỗi đó. Các cài đặt mặc định tiện lợi lại là lỗ hổng. Và ngay khi một tác nhân kết nối với bất kỳ thứ gì, rủi ro đó sẽ tăng lên gấp bội. “Bạn không chỉ tin tưởng vào bảo mật của riêng mình, bạn còn thừa hưởng tính vệ sinh của mọi công cụ, mọi thông tin đăng nhập, mọi nhà phát triển trong chuỗi đó,” Baer nói. “Đó là rủi ro chuỗi cung ứng trong thời gian thực.” ⛓️
Có một lỗi quản trị chồng lên lỗi kỹ thuật, và đó là sự phân loại sai lầm tương tự mà Assaf Keren, giám đốc an ninh của Qualtrics và cựu CISO của PayPal, đã chỉ ra trong các công cụ liền kề. “Hầu hết các đội ngũ bảo mật vẫn phân loại các nền tảng quản lý trải nghiệm là ‘công cụ khảo sát’, nằm trong cùng cấp độ rủi ro với một ứng dụng quản lý dự án,” Keren nói với VentureBeat. “Đây là một sự phân loại sai lầm lớn.” Thay thế bằng các framework tác nhân AI, điều đó vẫn đúng. Các đội ngũ xem LangGraph, Langflow và LangChain là tiện ích cho nhà phát triển, sau đó kết nối chúng với cơ sở dữ liệu, CRM và các khóa nhà cung cấp. “Bảo mật phải là yếu tố hỗ trợ,” Keren nói, “nếu không các đội ngũ sẽ tìm cách lách qua nó.” Những framework này chính là hình ảnh của việc lách luật. 👥
Điều cần trình bày với Hội đồng quản trị
Hội đồng quản trị không cần số CVE. Họ cần hậu quả, và Keren vạch ra ranh giới mà hội đồng quan tâm. Hầu hết các đội ngũ đã lập bản đồ phạm vi ảnh hưởng kỹ thuật. “Nhưng không phải phạm vi ảnh hưởng kinh doanh,” Keren nói với VentureBeat. “Khi một công cụ AI kích hoạt điều chỉnh bồi thường dựa trên dữ liệu bị nhiễm độc, thiệt hại không phải là một sự cố bảo mật. Đó là một quyết định kinh doanh sai lầm được thực hiện với tốc độ máy móc.” Một RCE trong framework là cùng một vấn đề nhưng ở lớp sớm hơn. Tác nhân không chỉ làm rò rỉ thông tin xác thực; nó còn hành động trên các hệ thống sản xuất bằng thông tin đó, và doanh nghiệp sẽ thấy một kết quả mà không ai có thể giải thích. 📈
Vì vậy, hãy trình bày theo cách mà hội đồng quản trị sẽ hiểu: chúng ta đang chạy các framework tác nhân AI trong sản xuất có thể bị biến thành các shell từ xa thông qua các lỗi mà máy quét của chúng ta không được xây dựng để tìm thấy, cả ba đều đã được vá, một trong số đó đang bị tấn công tích cực, và đây là ngày mọi phiên bản được xác minh và đóng. Không có điều nào trong số này yêu cầu phần mềm độc hại tùy chỉnh hoặc lỗ hổng zero-day. 🎯
Danh sách kiểm tra sáu câu hỏi
Để đối phó với tình hình này, bài viết đưa ra một danh sách kiểm tra gồm sáu câu hỏi trọng tâm mà các đội ngũ bảo mật cần trả lời ngay lập tức: 📝
* 1. Kho lưu trữ trạng thái của tác nhân có thể bị tấn công bằng mã độc không? (Liên quan đến chuỗi LangGraph SQLi-to-RCE, CVE-2025-67644 và CVE-2026-28277). Giải pháp là nâng cấp các phiên bản liên quan và đảm bảo get_state_history() không bị phơi nhiễm. 🔒 * 2. Một yêu cầu không xác thực có thể ghi tệp vào máy chủ tác nhân của chúng ta không? (Liên quan đến Langflow CVE-2026-5027, lỗi Path Traversal đang bị khai thác). Cần nâng cấp Langflow lên 1.9.0+, tắt tự động đăng nhập và cô lập các công cụ phát triển AI. 🚫 * 3. Bộ nạp prompt của chúng ta có thể đọc các tệp mà nó không được phép chạm vào không? (Liên quan đến LangChain-core CVE-2026-34070 và CVE-2025-68664). Yêu cầu nâng cấp langchain-core lên các phiên bản đã vá và thay thế load_prompt() bằng một thư mục được cho phép. 🔑 * 4. Một framework bị xâm phạm có thể trao toàn bộ thông tin xác thực cùng một lúc không? Các framework này thường được triển khai với các khóa nhà cung cấp, thông tin đăng nhập cơ sở dữ liệu và token tích hợp có sẵn cho môi trường quy trình. Cần chuyển các khóa nhà cung cấp sang cơ chế inject tạm thời, xoay vòng các khóa có thể đã bị lộ và giới hạn đặc quyền. 🔐 * 5. Các framework này có đang chạy ngoài sự quản lý bảo mật không? "Shadow AI" là vấn đề lớn. Cần kiểm kê, gán chủ sở hữu và đưa các framework vào quy trình phê duyệt. 📊 * 6. Máy quét của chúng ta có thể nhìn thấy bên trong framework trong thời gian chạy không? Các công cụ bảo mật truyền thống thường bỏ qua các lớp sâu bên trong framework. Cần thêm các phụ thuộc framework vào quản lý lỗ hổng, coi đầu ra tác nhân và trạng thái lưu trữ là không đáng tin cậy, và vá lỗi ngay khi thông tin được tiết lộ. 🕵️♀️
Hãy đưa ra thời hạn cho Hội đồng quản trị, không phải công nghệ
Các bản vá lỗi không yêu cầu tái kiến trúc hệ thống. Chúng chỉ là nâng cấp phiên bản và thay đổi cấu hình mà bạn có thể thực hiện ngay trong tuần này. Sự phơi nhiễm nằm ở khoảng cách giữa ngày bản vá được phát hành và ngày đội ngũ của bạn chạy các kiểm tra, và hiện tại, khoảng cách đó được đo bằng hàng tháng. Các framework đã làm chính xác những gì chúng được xây dựng để làm, nhưng điều đó lại vô tình mở ra cánh cửa cho kẻ xấu. Hãy hành động ngay! 🚀