Langflow CVE-2026-0768: lỗ hổng Langflow thứ 12 bị khai thác trong thực tế trong năm nay

CVE-2026-0768 là một lỗ hổng thực thi mã từ xa không cần xác thực trong Langflow, khung làm việc trực quan mã nguồn mở dùng để lắp ghép các pipeline và tác nhân mô hình ngôn ngữ lớn, và đến cuối tháng 8 năm 2026, kẻ tấn công đã khai thác nó trong thực tế. Lỗ hổng nằm trong trình xác thực mã đứng sau trình soạn thảo thành phần tùy chỉnh của Langflow: endpoint validate chấp nhận tham số code và chạy đoạn Python chứa trong đó, không có xác thực và, theo cách diễn đạt của Zero Day Initiative, "trong ngữ cảnh quyền root." Mạng honeypot Canary của VulnCheck đã ghi nhận hơn 50 nỗ lực khai thác trong vòng vài giờ sau những lần phát hiện đầu tiên vào ngày 30 tháng 8 năm 2026, và hơn 360 nỗ lực tính đến thứ Hai ngày 1 tháng 9, tất cả đều nhắm vào các cảm biến tại Vương quốc Anh; Caitlin Condon của VulnCheck cho biết lưu lượng nguồn chủ yếu xuất phát từ Nga. Các yêu cầu này không phải là ransomware. Chúng đọc các biến môi trường chứa thông tin đăng nhập siêu người dùng của Langflow, khóa API OpenAI cùng khóa truy cập và khóa bí mật AWS, rồi tìm đến /root/.cache/langflow/secret_key, .ssh và .bash_history. Mục đầy đủ của kho lưu trữ về sự cố này, bao gồm các phân loại về mức độ nghiêm trọng, độ tin cậy và mức độ tổn hại, nằm trong Kho Lưu Trữ Sự Cố AI Orca, cùng với các bản ghi khác về đánh cắp thông tin xác thực và hạ tầng AI bao quanh nó.

Security Affairs đã công bố bài tường thuật của mình vào ngày 2 tháng 9 năm 2026; Ionut Arghire của SecurityWeek đã đưa tin về việc khai thác vào ngày hôm trước, Bill Toulas của BleepingComputer đã đưa tin về vụ việc trong tuần đó, và Sáng kiến An toàn AI của Cloud Security Alliance tiếp nối vào ngày 4 tháng 9 bằng một ghi chú nghiên cứu nhắc lại cơ chế và bổ sung các khuyến nghị. Không có bài tường thuật nào được xem xét cho bài viết này nêu tên một tổ chức bị xâm phạm. Mọi thứ đều bắt nguồn từ các cảm biến của chính VulnCheck và từ khuyến cáo mà Zero Day Initiative đã công bố vào tháng 1.

Một trình soạn thảo thực thi những gì nó được yêu cầu xác thực

Điểm bán hàng của Langflow là bạn lắp ghép một ứng dụng AI bằng cách kéo các thành phần lên một canvas. Các thành phần tùy chỉnh là Python: trình chỉnh sửa cho phép người dùng dán mã và nhấn validate, rồi máy chủ kiểm tra mã đó. Theo khuyến cáo ZDI ZDI-26-034, bước kiểm tra đó lại thực thi chính mã. Câu mô tả nguyên nhân gốc trong khuyến cáo chỉ có một dòng — "việc thiếu xác thực đúng đắn đối với một chuỗi do người dùng cung cấp trước khi dùng nó để thực thi mã Python" — và hệ quả là một yêu cầu HTTP không cần xác thực duy nhất thực thi Python tùy ý trên máy chủ.

Ba thuộc tính biến nó thành một sự cố thay vì một báo cáo lỗi. Vectơ CVSS là AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, với điểm số 9.8: có thể truy cập qua mạng, độ phức tạp thấp, không cần đặc quyền, không cần tương tác của người dùng, và mất toàn bộ tính bảo mật, tính toàn vẹn và tính khả dụng. Ngữ cảnh thực thi là root, đó là lý do các lệnh của kẻ tấn công mà cả Condon và Cloud Security Alliance đều mô tả đều hướng tới /root/.cache/langflow/secret_key — tệp mà Langflow sử dụng để mã hóa thông tin xác thực được lưu trữ và dữ liệu phiên. Và điểm cuối không yêu cầu bất kỳ thông tin xác thực nào, nên mức độ phơi nhiễm chỉ phụ thuộc vào khả năng truy cập mà thôi.

Lịch sử tiết lộ có ý nghĩa quan trọng đối với cách sự việc diễn ra. Dòng thời gian của ZDI ghi lại việc báo cáo đến tài khoản GitHub của Langflow vào ngày 18 tháng 7 năm 2025, yêu cầu cập nhật vào ngày 11 tháng 9 năm 2025, yêu cầu bản sửa lỗi vào ngày 10 tháng 10 năm 2025, và thông báo về ý định công bố dưới dạng zero-day vào ngày 10 tháng 12 năm 2025. ZDI đã phát hành khuyến cáo vào ngày 9 tháng 1 năm 2026. Các nhà nghiên cứu được ghi nhận là Peter Girnus, William Gamazo Sanchez và Alfredo Oliveira của Trend Research. Cơ sở dữ liệu khuyến cáo của GitHub có cùng văn bản với GHSA-x5pr-rvjj-j6qm, được xuất bản ngày 23 tháng 1 năm 2026, được phân loại là CWE-94, và không liệt kê bất kỳ phạm vi phiên bản bị ảnh hưởng nào cả. Biện pháp giảm thiểu được ZDI nêu rõ không phải là một bản vá: đó là "hạn chế tương tác với sản phẩm."

Các báo cáo công khai xác định phạm vi bị ảnh hưởng là các bản phát hành Langflow tính đến và bao gồm 1.4.2, phiên bản mà mô-đun Metasploit được bổ sung sau đó đã được xây dựng và kiểm thử nhắm đến. Đó là nơi sự chắc chắn kết thúc, và phần về các bản sửa lỗi bên dưới trình bày lý do.

Các phát hiện 360 chứng minh được gì và không chứng minh được gì

Canaries của VulnCheck là các cảm biến hướng internet được tạo ra để trông giống thứ mà kẻ tấn công đang quét tìm. Công ty đã ghi nhận lần khai thác đầu tiên đối với CVE-2026-0768 vào ngày 29–30 tháng 8 năm 2026: hơn 50 lần phát hiện trong vài giờ vào Chủ nhật, tăng vượt 360 vào thứ Hai. Condon, phó chủ tịch nghiên cứu mối đe dọa của VulnCheck, đã mô tả hoạt động này trên LinkedIn là “sự kết hợp giữa trinh sát và thu thập thông tin xác thực,” đồng thời cho biết lưu lượng nguồn chủ yếu đến từ Nga và “cho đến nay chỉ đánh trúng các Canaries ở Vương quốc Anh.”

Chuỗi lệnh mà các cảm biến ghi nhận đủ cụ thể để trở thành một kịch bản hành động. Kẻ tấn công đã truy vấn môi trường để tìm LANGFLOW_SUPERUSER, các biến khớp với OPENAI_API, và các khóa AWS_ACCESS cùng AWS_SECRET — ba nhóm thông tin xác thực mà một máy chủ Langflow có nhiều khả năng chứa nhất. Chúng đã đọc khóa bí mật được lưu trong bộ nhớ đệm tại /root/.cache/langflow/secret_key. Chúng đã kiểm tra quyền truy cập .ssh và xem xét kích thước của .bash_history, cả hai đều cho thấy liệu một kẻ vận hành có thể di chuyển ngang hay chỉ đơn thuần đọc được bí mật. Một bài viết cộng đồng về chuỗi tấn công này, được Cloud Security Alliance trích dẫn, bổ sung rằng cùng hoạt động đó đã tìm kiếm trong cây mã nguồn và các tệp .env để tìm bí mật được nhúng, đánh cắp những gì tìm thấy, và kiểm tra xem một máy chủ đã bị cài backdoor bởi kẻ vận hành trước đó hay chưa trước khi thêm cơ chế duy trì của chính nó.

Điều đó xác lập rằng lỗ hổng khai thác hoạt động, rằng nó đã được dùng nhắm vào các phiên bản Langflow hướng internet, và rằng mục tiêu là thông tin đăng nhập chứ không phải gây gián đoạn. Điều nó không xác lập là một nạn nhân. Canary là mồi nhử; một lần phát hiện chỉ là một yêu cầu, không phải một vụ đánh cắp đã được xác nhận. Kho lưu trữ phân loại bản ghi này là tổn hại thực sự, và tổn hại được ghi nhận trong các nguồn công khai là việc mã thu thập thông tin đăng nhập đã thực thi được xác nhận nhắm vào các hệ thống bị phơi lộ — không phải một tổ chức có tên mà các khóa của họ đã bị sử dụng.

Một chi tiết đi ngược lại câu chuyện thường thấy về việc công bố thông tin. Theo VulnCheck, không hề có bản proof-of-concept công khai nào cho CVE-2026-0768 vào thời điểm việc khai thác bắt đầu. Bản khuyến cáo đã được công khai gần tám tháng và mô tả lỗ hổng đủ chính xác để một ai đó có thể dựng ra một exploit chỉ từ nội dung văn bản. Đánh giá của công ty, theo The Hacker News đưa tin, là đây là sự tự phát triển độc lập chứ không phải tái sử dụng mã đã bị rò rỉ.

Mười hai lỗ hổng, mười lăm nghìn lần thử — và nơi những con số ấy bị bẻ cong

Số liệu mang lại sức nặng cho sự cố này đến từ VulnCheck, và đáng để trích dẫn nguyên văn lời của công ty thay vì diễn giải. “Trước năm 2026, bằng chứng cho thấy chỉ có một lỗ hổng Langflow được biết là bị khai thác trong thực tế,” công ty cho biết. “Vào năm 2026, mọi thứ đã thay đổi nhanh chóng.” SecurityWeek đưa tin VulnCheck theo dõi “11 lỗ hổng bổ sung đã bị nhắm mục tiêu và được báo cáo là bị khai thác trong thực tế” trong năm 2026.

Cộng những lỗ hổng đó lại, bạn có mười hai lỗ hổng Langflow đã bị khai thác, trong đó một lỗ hổng có từ trước năm nay. Điều đó không đồng nghĩa với mười hai lỗ hổng trong năm 2026, và các nguồn tin dao động giữa hai cách diễn đạt này. Tiêu đề của Forkast gọi CVE-2026-0768 là “CVE thứ 12 của Langflow bị khai thác trong năm 2026”, trong khi phần thân của cùng bài viết mô tả nhóm mười hai lỗ hổng là “11 lỗ hổng mới và một lỗ hổng được xác định trước khi năm bắt đầu”. Tiêu đề của bản ghi theo sát tiêu đề bài báo. Nếu đọc một cách chặt chẽ, năm 2026 chiếm mười một trong số mười hai, còn lỗ hổng thứ mười hai — lỗ hổng được biết đến trước năm nay — tạo nên phần còn lại.

Con số 15.000 cũng có một điểm đáng lưu ý tương tự. SecurityWeek, The Hacker News và Forkast đều quy “hơn 15.000 cuộc tấn công thành công” cho ba lỗ hổng được nêu tên: CVE-2026-0769, CVE-2025-3248 và CVE-2026-5027. Đó là một con số lớn, nhưng nó là tổng số trên ba CVE, không phải trên toàn bộ danh mục năm 2026 của Langflow. Việc diễn đạt nó thành các nỗ lực khai thác nhằm vào danh mục — như phần tóm tắt của kho lưu trữ làm — rộng hơn những gì VulnCheck đã công bố.

Các mục riêng lẻ đằng sau mô hình này đều đã được ghi nhận. CVE-2025-3248 là một lỗ hổng chèn mã trong cùng endpoint /api/v1/validate/code, được vá trong Langflow 1.3.0 bằng cách thay thế việc thực thi bằng xác thực chỉ biên dịch, theo cảnh báo GHSA-rvqx-wpfh-mfx7 của GitHub được Cloud Security Alliance trích dẫn — nghĩa là CVE-2026-0768 là cùng loại lỗi trong cùng đường xử lý mã, khoảng bốn tháng sau khi bản vá đó được phát hành. CVE-2026-33017, một lỗ hổng RCE không cần xác thực trong endpoint xây dựng flow công khai, đã bị vũ khí hóa trong khoảng 20 giờ sau khi được công bố vào tháng 3 năm 2026 và bị dùng để đánh cắp thông tin đăng nhập OpenAI, Anthropic và AWS trước khi chuyển hướng sang đào tiền mã hóa Monero, theo ghi nhận của Cloud Security Alliance. Ghi chú ngày 12 tháng 6 năm 2026 của cùng liên minh này đề cập đến CVE-2026-5027, một lỗ hổng duyệt đường dẫn trong endpoint tải tệp lên mà các nhà nghiên cứu liên hệ với nhóm MuddyWater được nhà nước Iran hậu thuẫn, và ghi chú ngày 4 tháng 9 của tổ chức này ghi nhận CVE-2026-55255, một lỗ hổng bỏ qua phân quyền cho phép người dùng đã xác thực chạy các flow của người dùng khác, được đưa vào danh mục Known Exploited Vulnerabilities của CISA vào ngày 7 tháng 7 năm 2026. Bốn lỗ hổng đó có chung một dạng: một endpoint hoặc bỏ qua xác thực hoặc bỏ qua làm sạch dữ liệu, trong một nền tảng mà nhiệm vụ của nó là lưu giữ thông tin đăng nhập cho mọi thứ mà nó giao tiếp.

Vì sao một nền tảng điều phối lại đáng để bỏ công

Một instance Langflow production được cấu hình với khóa API của nhà cung cấp, thông tin xác thực cloud, chuỗi kết nối cơ sở dữ liệu và bí mật tích hợp, vì các flow mà nó chạy cần những thứ này tại thời điểm gọi. Do đó, việc xâm phạm máy chủ sẽ mang lại quyền truy cập đang hoạt động vào mọi dịch vụ mà instance lưu thông tin xác thực. Khóa OpenAI hoặc Anthropic bị đánh cắp cho phép kẻ tấn công tính chi phí suy luận cho nạn nhân hoặc mạo danh tổ chức với các bên hạ nguồn; khóa AWS bị đánh cắp mở ra hạ tầng vượt xa container Langflow. Chính đòn bẩy đó, chứ không phải bất kỳ năng lực nào dành riêng cho AI, là thứ mà các lệnh quan sát được nhắm tới.

Đánh giá của Cloud Security Alliance là việc tái diễn trên bốn hệ thống con khác nhau của Langflow trong một năm — trình xác thực mã, điểm cuối xây dựng luồng công khai, tải lên tệp, thực thi quy trình công việc — cho thấy một lỗ hổng mang tính hệ thống trong kỹ thuật bảo mật chứ không phải một loạt các khiếm khuyết không liên quan. Đó là đánh giá của liên minh, được đưa ra trong một ghi chú nghiên cứu, không phải là phát hiện của một kiểm toán viên độc lập, và Langflow đã không phản hồi công khai về điều đó trong tài liệu được xem xét ở đây.

Những gì đã được sửa, và điều gì vẫn còn mơ hồ

Đây là phần yếu nhất của hồ sơ công khai, và đáng để nói chính xác vì sao. Bản tin khuyến cáo của ZDI không nêu phiên bản nào đã được vá. Mục cơ sở dữ liệu của Snyk cho CVE này liệt kê các phiên bản bị ảnh hưởng là mọi phiên bản trước 1.10.1 và khuyến nghị nâng cấp lên 1.10.1 trở lên. Các bài báo công khai, bao gồm SecurityWeek và Security Affairs, mô tả phạm vi bị ảnh hưởng là các bản phát hành đến 1.4.2 nhưng không xác định được bản phát hành nào đã được sửa. Cloud Security Alliance lưu ý vào ngày 4 tháng 9 rằng những người duy trì Langflow đã không công bố một bản tin bảo mật riêng nêu tên CVE này, và các công cụ theo dõi không thống nhất về việc bản phát hành nào thực sự đã khắc phục lỗ hổng — một sự mơ hồ mà liên minh này cho là tương tự một trường hợp Langflow trước đó, khi một phiên bản được báo cáo là đã sửa vẫn có thể bị khai thác.

Langflow đã thực sự phát hành các bản sửa lỗi ở đúng khu vực, vào đúng ngày. Phiên bản 1.11.6 được công bố vào ngày 1 tháng 9 năm 2026, thứ Hai mà số lượng honeypot đã vượt mốc 360, và ghi chú phát hành của nó mô tả một bản backport các bản sửa lỗi bảo mật, bao gồm "lấp các lỗ hổng quét mã thành phần" và "phân giải chú thích mà không thực thi" (yêu cầu kéo 14876). Phiên bản 1.12.0 tiếp theo vào tối hôm đó. Việc tăng cường thêm đối với cùng đường dẫn mã vẫn tiếp tục sau đó: một yêu cầu kéo sau đó có tiêu đề "ngăn validate_code thực thi các import" cho thấy điểm cuối validate vẫn đang được siết chặt nhiều tuần sau lần khai thác đầu tiên. Không điều nào trong số đó tạo thành một tuyên bố của nhà cung cấp rằng CVE-2026-0768 đã được sửa trong một bản phát hành được nêu tên, và không có tuyên bố nào như vậy được tìm thấy trong các nguồn được trích dẫn của hồ sơ.

Điều đã thay đổi ở phía kẻ tấn công thì rõ ràng hơn. Một mô-đun khai thác Metasploit cho lỗ hổng này đã được mở dưới dạng pull request vào ngày 2 tháng 9 năm 2026 — cùng ngày Security Affairs công bố — và được hợp nhất vào ngày 8 tháng 10 năm 2026, được kiểm thử với Langflow 1.4.2. Dù quá trình dẫn xuất ban đầu ra sao, việc khai thác lỗ hổng này đã không còn đòi hỏi công sức tự phát triển nữa sáu tuần sau khi nó bắt đầu bị khai thác.

Khuyến nghị của Cloud Security Alliance là thực hiện chuỗi hành động vá và luân chuyển thay vì chỉ vá: xác minh phiên bản đang chạy và chuyển sang bản phát hành ổn định hiện tại; coi mọi instance được phơi bày trên Internet đang chạy phiên bản bị ảnh hưởng là đã bị xâm phạm cho đến khi chứng minh được điều ngược lại, vì hoạt động quan sát được là thu thập thầm lặng chứ không phải gián đoạn có thể thấy; và luân chuyển mọi bí mật mà instance đó có thể truy cập — mật khẩu siêu người dùng Langflow, khóa API của nhà cung cấp, khóa truy cập và khóa bí mật AWS, cùng chính khóa bí mật Langflow, đồng thời mã hóa lại thông tin xác thực đã lưu trữ thay vì chỉ thay thế tệp. Tổ chức này cũng khuyến nghị kiểm tra nhật ký truy cập để tìm các yêu cầu đến endpoint validate, kiểm tra authorized_keys để tìm khóa SSH lạ, và tìm bằng chứng rằng người vận hành trước đó đã cài cửa hậu vào máy chủ. Khi nền tảng phải duy trì khả năng truy cập, tổ chức đề xuất đặt cơ chế kiểm soát truy cập hoặc vô hiệu hóa endpoint validate và từ bỏ việc sử dụng các khóa đặc quyền cao tồn tại lâu dài được lưu trực tiếp trong nền tảng.

Đã thiết lập, đã báo cáo và chưa thiết lập

Đã xác định: rằng CVE-2026-0768 là một lỗ hổng RCE không cần xác thực trong endpoint validate của Langflow, thực thi Python với quyền root, được ghi lại trong ZDI-26-034 và được phản chiếu dưới dạng GHSA-x5pr-rvjj-j6qm; rằng việc khai thác bắt đầu vào ngày 29–30 tháng 8 năm 2026; rằng VulnCheck đã ghi nhận hơn 50 lần phát hiện trong vài giờ và hơn 360 lần tính đến ngày 1 tháng 9, nhắm vào các cảm biến tại Vương quốc Anh, với lưu lượng chủ yếu đến từ Nga; và rằng các yêu cầu quan sát được nhắm vào thông tin xác thực superuser, OpenAI và AWS của Langflow cùng khóa bí mật được lưu trong bộ nhớ đệm, .ssh và .bash_history. Những thông tin này đến từ chính bản tư vấn và từ dữ liệu telemetry của VulnCheck như được SecurityWeek, Security Affairs và The Hacker News đưa tin độc lập.

Được báo cáo, chưa được xác minh độc lập: mọi con số phát hiện. Con số 50, 360 và 15.000 là các số liệu của chính VulnCheck, được công ty công bố và được các hãng truyền thông ghi nguồn cho công ty lặp lại; không có mạng honeypot thứ hai nào công bố một con số củng cố. Việc quy cho cơ sở hạ tầng Nga cũng là cách VulnCheck diễn giải lưu lượng nguồn, không phải là đánh giá mà bất kỳ chính phủ hoặc CERT nào đã chứng thực trong tài liệu được xem xét.

Chưa được xác lập:rằng bất kỳ tổ chức được nêu tên nào đã mất thông tin xác thực. Không có nạn nhân nào được xác định trong các nguồn của hồ sơ. Cũng không có phiên bản đã vá nào được xác nhận: ZDI không nêu phiên bản nào, Snyk nói là 1.10.1, báo cáo nói bị ảnh hưởng đến hết 1.4.2, và ghi chú phát hành 1.11.6 mô tả các bản sửa lỗi bảo mật mà không liên kết chúng với CVE này. Số đếm "lỗ hổng thứ mười hai của năm 2026" cũng không nhất quán nội bộ giữa các nguồn của chính nó, như đã nêu ở trên.

Phần khiến những người vá theo lịch trình phải lo lắng

Khoảng trống tám tháng chính là phát hiện. CVE-2026-0768 được công bố dưới dạng zero-day vào ngày 9 tháng 1 năm 2026, với mô tả kỹ thuật đủ chi tiết để có thể dựng lại, vậy mà không có gì xảy ra với các cảm biến của VulnCheck cho đến cuối tuần cuối cùng của tháng 8. Sau đó, vài trăm nỗ lực tấn công ập đến trong ba ngày, từ những đối tượng vận hành mà theo lời công ty, không có exploit công khai nào để sao chép. Bất cứ điều gì đã khiến những phiên bản đó không được vá suốt tám tháng với một khuyến cáo nghiêm trọng công khai cũng chính là điều khiến lỗ hổng trở nên đáng khai thác khi cuối cùng có người viết mã.

Nó cũng khép lại một vòng lặp mà các CVE Langflow trước đó đã mở ra. CVE-2025-3248 đã được vá bằng cách loại bỏ việc thực thi khỏi chính đường dẫn validate; CVE-2026-0768 vẫn thực thi trên đường dẫn đó. Một bản vá loại bỏ một hành vi mà không loại bỏ quyết định thiết kế đã tạo ra nó chỉ mua được thời gian, và trong trường hợp này nó mua được khoảng bốn tháng.