Clinejection: Cách một tiêu đề issue chạm tới token npm của Cline

Ngày 9 tháng 2 năm 2026, nhà nghiên cứu bảo mật Adnan Khan đã công bố bài tường thuật về một lỗ hổng mà anh đã báo cáo riêng cho Cline vào ngày 1 tháng 1: trợ lý lập trình AI mã nguồn mở này đã nối một công cụ tự động phân loại issue, được xây dựng trên GitHub Action claude-code-action của Anthropic, với một prompt dán thẳng mọi tiêu đề issue GitHub gửi đến vào hướng dẫn của mô hình. Bất kỳ tài khoản GitHub nào cũng có thể kích hoạt nó bằng cách mở một issue, và trong bản tái hiện của Khan, một tiêu đề được diễn đạt như một chỉ thị đã khiến tác nhân chạy lệnh shell bên trong workflow. Sau đó, anh lần theo tuyến đường từ chỗ bám đó, qua việc đầu độc bộ nhớ đệm GitHub Actions, đến thông tin xác thực phát hành cho VS Code Marketplace, OpenVSX và npm. Tám ngày sau khi Cline sửa workflow, một token phát hành npm mà Cline tưởng rằng đã được xoay vòng đã bị dùng để phát hành cline 2.3.0, bản này cài OpenClaw trên mọi máy đã cài gói. Mục đầy đủ, cùng với các mức độ nghiêm trọng và độ tin cậy của nó, nằm trong Orca AI Incident Archive, bên cạnh các bản ghi chuỗi cung ứng lân cận từ cùng thời kỳ.

Hai ngày, không phải một

Kho lưu trữ ghi ngày của bản ghi này là 9 tháng 2 năm 2026, với độ chính xác đến ngày, và đó là ngày Khan công bố bài viết của mình tại adnanthekhan.com. Đó không phải là ngày gói độc hại xuất hiện. Bản thân lỗ hổng được đưa vào ngày 21 tháng 12 năm 2025, trong một commit đã thêm quy trình triage vào kho cline/cline, và nó vẫn tồn tại cho đến khi Cline xóa quy trình này vào ngày 9 tháng 2. Việc xuất bản npm trái phép diễn ra vào ngày 17 tháng 2, tám ngày sau bản sửa lỗi và bốn mươi bảy ngày sau báo cáo riêng đầu tiên của Khan.

Việc tách riêng hai ngày đó ra là quan trọng, vì sự thật hệ trọng nhất trong vụ việc nằm trong khoảng trống giữa chúng: cánh cửa đã được đóng vào ngày 9 tháng 2, nhưng chiếc chìa khóa mà kẻ xâm nhập đã sao chép từ trước vẫn còn dùng được vào ngày 17 tháng 2. Chính bản đính chính của Cline, được gửi cho Khan vào ngày 17 tháng 2 và được trích lại trong bài đăng của ông, nói thẳng: "Khi chúng tôi xoay vòng thông tin xác thực vào ngày 9 tháng 2, token xuất bản npm đã không được thu hồi đúng cách. Token sai đã bị xóa, và token bị lộ vẫn còn hoạt động."

Chuỗi: từ tiêu đề issue đến token phát hành

Tệp có lỗ hổng là .github/workflows/claude-issue-triage.yml, tệp này chạy trên sự kiện issues và gọi anthropics/claude-code-action@v1 với Claude Opus 4.5, được ghim trong workflow dưới dạng claude-opus-4-5-20251101. Khan trích dẫn cấu hình của workflow: allowed_non_write_users được đặt thành ký tự đại diện "*", vì vậy bất kỳ tài khoản GitHub nào cũng có thể kích hoạt agent chỉ bằng cách mở một issue, và claude_args đã truyền --allowedTools với Bash, Read, Write, Edit, Glob, Grep, WebFetch và WebSearch. Bash là công cụ thực sự quan trọng. Nó cho phép mô hình thực thi shell bên trong một workflow chạy trong ngữ cảnh nhánh mặc định.

Prompt đã nội suy tiêu đề issue mà không làm sạch nó. Bản proof of concept của Khan dùng một tiêu đề bắt đầu bằng “Tool error.” và tiếp tục bằng chỉ dẫn cài một gói hỗ trợ từ một commit cụ thể trước khi tiếp tục triage. Tham chiếu commit trỏ tới một fork có package.json chứa script preinstall, script này chạy lệnh curl tới một endpoint do kẻ tấn công kiểm soát trước khi npm cài xong bất cứ thứ gì. Vì quá trình cài chạy qua Bash tool, mô hình không bao giờ kiểm tra thứ đã thực thi. Khan đã tái hiện điều này trên một bản sao của kho Cline và báo cáo rằng agent đã thực thi payload trong mọi lần thử.

Việc thực thi mã trong quy trình triage tự thân không phải là quyền truy cập thông tin xác thực phát hành. Bước đó đến từ một đặc tính của GitHub Actions mà Khan đã ghi lại trong một công cụ năm 2024 do anh ấy phát hành có tên Cacheract: bất kỳ workflow nào cũng có thể đọc và ghi bộ nhớ đệm của kho lưu trữ với toàn quyền kiểm soát khóa và phiên bản bộ nhớ đệm, ngay cả một workflow chưa bao giờ khai báo bước lưu đệm. Công việc triage chạy trên nhánh mặc định, nên nó dùng chung phạm vi bộ nhớ đệm với các công việc phát hành hàng đêm, vốn có khôi phục node_modules từ bộ nhớ đệm và có nắm giữ các token phát hành.

Các mục bộ nhớ đệm là bất biến, vì vậy kẻ tấn công không thể chỉ đơn giản ghi đè mục mà một công việc phát hành sẽ khôi phục. Cách Khan lách qua điều đó là khai thác một thay đổi chính sách của GitHub ngày 20 tháng 11 năm 2025, khiến dịch vụ loại bỏ các mục bộ nhớ đệm ngay khi bộ nhớ đệm của một kho lưu trữ vượt quá 10 GB, theo thứ tự ít được sử dụng gần đây nhất. Làm tràn bộ nhớ đệm vượt quá 10 GB, và các mục hợp lệ sẽ bị đào thải do cũ; chiếm các khóa đã bị bỏ trống bằng nội dung bị đầu độc, và công việc tiếp theo khôi phục chúng sẽ chạy mã của kẻ tấn công. Cacheract tự động hóa toàn bộ chuỗi thao tác trong một lần chạy quy trình làm việc duy nhất, và nó duy trì sự tồn tại bằng cách ghi đè action.yml của actions/checkout để bước post của action thực thi một payload vào cuối mỗi công việc.

Mắt xích cuối cùng trong chuỗi là tác vụ chạy hằng đêm, khởi chạy vào khoảng 2 giờ sáng UTC, khôi phục node_modules đã bị đầu độc, rồi phát nổ. Thứ bước ra là VSCE_PAT, OVSX_PAT và NPM_RELEASE_TOKEN, lần lượt là thông tin xác thực cho VS Code Marketplace, OpenVSX và npm. Việc liệu mọi mắt xích có chạy trên chính kho lưu trữ của Cline theo đúng thứ tự đó hay không là một câu hỏi riêng, sẽ được bàn tới bên dưới.

Vì sao thông tin đăng nhập dùng cho bản chạy hằng đêm lại là thông tin đăng nhập của môi trường sản xuất

Phản đối hiển nhiên là các bản phát hành nightly và production lẽ ra phải giữ các bí mật khác nhau. Câu trả lời của Khan là sự tách biệt đó chỉ trên danh nghĩa. OpenVSX và VS Code Marketplace gắn token xuất bản với danh tính nhà xuất bản, chứ không phải với từng tiện ích mở rộng riêng lẻ, và cả tiện ích Cline bản ổn định lẫn bản nightly đều được xuất bản dưới cùng một danh tính, mà Khan xác định trên OpenVSX là saoudrizwan. Trên npm, mô hình token chi tiết gắn với một gói, và Cline đã xuất bản các bản dựng CLI ổn định và nightly của mình lên cùng gói cline. Do đó, một token được cấp cho tác vụ nightly có thể xuất bản sản phẩm production, và đó chính xác là điều đã xảy ra tám ngày sau đó.

Cách chính Khan lý giải về tác động dựa vào quy mô: ông dẫn lời thông báo của Cline rằng nó đã vượt 5 triệu lượt cài đặt, và lưu ý rằng một bản cập nhật tiện ích được phát tán thông qua thông tin xác thực bị đánh cắp sẽ được thực thi trong ngữ cảnh của mọi nhà phát triển có trình soạn thảo tự động cập nhật, với quyền của nhà phát triển đó và bất kỳ khóa, token và mã nguồn nào nằm trên máy.

Những gì thực sự đã được công bố, và những gì nó đã làm

Sản phẩm phát hành là cline 2.3.0 và nó nhỏ. Dấu thời gian của chính npm registry đặt 2.3.0 tại 11:26:51 UTC ngày 17 tháng 2 năm 2026 và bản 2.4.0 sạch tại 19:23:08 UTC cùng ngày, thời gian phơi nhiễm mà khuyến cáo của Cline ước tính khoảng tám giờ, cho đến khi 2.3.0 bị deprecated lúc 11:30 sáng PT. package.json của gói có thêm một dòng, một script postinstall với nội dung npm install -g openclaw@latest. Khuyến cáo của Cline, GHSA-9ppg-jx86-fqw7, nêu rằng không có tệp gói nào khác bị thay đổi và dist/cli.mjs giống hệt từng byte với bản dựng 2.2.3 hợp pháp.

OpenClaw là một framework tác nhân AI mã nguồn mở thực sự, không phải phần mềm độc hại, và khuyến cáo của Cline nói rõ điều đó: đây là một dự án hợp pháp, nhưng việc cài đặt nó không được cho phép hoặc không phải chủ đích. Endor Labs, đơn vị đã phân tích tarball, đánh giá tác động tổng thể là thấp với lý do việc cài đặt không khởi động daemon Gateway của OpenClaw. Bài viết của StepSecurity đo lường mặt còn lại: một bản cài đặt toàn cục để lại framework trên đĩa với bất kỳ thông tin xác thực và quyền truy cập tệp nào mà người dùng cài đặt có, và thiết kế của OpenClaw, một gateway cục bộ thường trực với API vận hành, khiến nó trở thành thứ có giá trị cao khi tìm thấy ở đó. Hai đánh giá không mâu thuẫn. Một bên mô tả những gì đã chạy trong khoảng thời gian đó; bên kia mô tả những gì bị bỏ lại phía sau.

Số lượng là con số duy nhất phải được xử lý cẩn thận. StepSecurity báo cáo rằng phiên bản bị xâm phạm đã được tải xuống khoảng 4.000 lần trước khi bị ngừng hỗ trợ, và The Register đã nhắc lại con số đó. Endor Labs đặt số lượt tải xuống hàng tháng của cline trong giai đoạn từ 19 tháng 1 đến 17 tháng 2 là 418.545, phản ánh lưu lượng thông thường của gói chứ không phải bản dựng độc hại. Cả hai con số đều không đếm máy: số lượt tải xuống không phải là số nhà phát triển bị ảnh hưởng, và chưa bên nào công bố con số cơ sở cài đặt cho 2.3.0. Nhóm Threat Intelligence của Microsoft cho biết trên X rằng họ quan sát thấy một "mức tăng nhỏ nhưng đáng chú ý" trong các bản cài đặt OpenClaw vào ngày 17 tháng 2 phát sinh từ tập lệnh cài đặt Cline, như The Hacker News đưa tin.

Hồ sơ tư vấn của GitHub cho GHSA-9ppg-jx86-fqw7 không có CVE và không có CWE, và mức độ nghiêm trọng của nó là Low. Mức đó nói về payload vô hại, chứ không nói về việc đánh cắp thông tin xác thực, và nó nằm một cách kỳ lạ bên cạnh mức nghiêm trọng của kho lưu trữ cho chính sự cố. Bản tư vấn ghi nhận 2.3.0 là phiên bản bị ảnh hưởng và 2.4.0 là bản sửa lỗi.

Tiết lộ mà Cline không trả lời

Dòng thời gian trước khi công bố của Khan là phần trong hồ sơ ít liên quan đến mô hình nhất và liên quan nhiều nhất đến quy trình. Anh ấy đã gửi một GHSA thông qua tính năng báo cáo lỗ hổng riêng tư của GitHub vào ngày 1 tháng 1 năm 2026 và gửi email đến đầu mối an ninh được liệt kê trên trang tin cậy của Cline cùng ngày. Anh ấy đã gửi thư theo dõi cho một nhà phát triển của Cline vào ngày 8 tháng 1. Anh ấy đã thử nhắn tin trực tiếp cho CEO của Cline trên X vào ngày 18 tháng 1. Anh ấy đã viết lại vào ngày 7 tháng 2 và không nhận được gì ngoài một số ticket tự động. Anh ấy đã công bố vào ngày 9 tháng 2.

Cline đã hợp nhất bản sửa lỗi, pull request 9211, khoảng ba mươi phút đến một giờ sau đó. PR này xóa ba tệp quy trình làm việc, claude-issue-triage.yml, claude-pr-review.yml và cline-pr-review.yml, đồng thời loại bỏ bộ nhớ đệm khỏi publish.yml, publish-nightly.yml, npm-nightly.yaml và npm-main.yaml, tổng cộng bảy tệp, với các bước cài đặt giờ được thực hiện vô điều kiện vì không còn lượt trúng bộ nhớ đệm nào để phụ thuộc vào.

Phản hồi công khai của Cline vào ngày 10 tháng 2, được trích dẫn trong bài đăng của Khan, đã chấp nhận phát hiện này và liệt kê các biện pháp giảm thiểu ngay lập tức: gỡ bỏ các quy trình đánh giá của bot đối với issue và PR, gỡ bỏ actions/cache khỏi các quy trình xuất bản xử lý thông tin xác thực phát hành, và xoay vòng các thông tin xác thực liên quan bao gồm token của bot, nhà cung cấp và xuất bản. Phản hồi cũng thừa nhận cách xử lý: "chúng tôi thừa nhận rằng thời gian phản hồi của chúng tôi đối với báo cáo ban đầu của bạn là không thể chấp nhận được. Một báo cáo được gửi vào ngày 1 tháng 1 lẽ ra không cần phải công bố công khai vào ngày 9 tháng 2 mới được giải quyết."

Ngày 11 tháng 2, Cline cho biết đã hoàn tất việc luân chuyển toàn bộ VSCE_PAT, OVSX_PAT và NPM_RELEASE_TOKEN, đồng thời một cuộc kiểm toán mọi bản phát hành trên cả ba kênh phân phối từ ngày 21 tháng 12 năm 2025 đến ngày 9 tháng 2 năm 2026 phát hiện rằng mọi phiên bản trên Marketplace và OpenVSX đều ánh xạ tới một bản phát hành GitHub có gắn thẻ và cả 41 phiên bản npm đều nhất quán với mã nguồn. Công ty kết luận rằng không có bản phát hành trái phép nào được công bố "trong khoảng thời gian phơi nhiễm được cho là". Sáu ngày sau, công ty đính chính, trong thông điệp được trích dẫn ở trên: token npm chưa bị thu hồi, và 2.3.0 đã được phát hành bằng token đó.

Đã xác lập, được quy kết, chưa giải quyết

• Đã được xác lập. Cấu hình quy trình làm việc là công khai và đã được công bố trước bản sửa lỗi. Khan đã tái hiện prompt injection trên một bản sao (mirror) của kho lưu trữ. Cline đã hợp nhất bản khắc phục và phát hành khuyến cáo xác nhận việc phát hành 2.3.0, dòng postinstall được thêm vào, tệp nhị phân CLI không thay đổi, cửa sổ tám giờ và lỗi token. Dấu thời gian của npm registry cho 2.3.0 và 2.4.0 khớp với thời gian trong khuyến cáo. Cơ sở lưu trữ chấm bản ghi ở mức nghiêm trọng, độ tin cậy A, với tổn hại thực tế được ghi nhận và không có cờ tranh chấp.

• Có quy kết, chưa được xác lập. Ai đã phát hành 2.3.0 vẫn là một quy kết còn bỏ ngỏ. Bài phân tích pháp chứng do Michael Bargury và một công cụ điều tra tự động tên Raptor công bố ngày 19 tháng 2 nêu tên một tài khoản GitHub, glthub-actions, và báo cáo với độ tin cậy cao rằng tài khoản này đã fork cline/cline, mở issue 8904 vào ngày 28 tháng 1 năm 2026 lúc 03:51 UTC với tiêu đề bị chèn, và dùng một commit trên fork để chạy payload từ một gist. Khan xác nhận rằng các tài khoản gcbrun và Dev11940518 là của chính anh ta và glthub-actions không phải. Tài khoản đã bị xóa hoặc đình chỉ khi bài viết được công bố, và Cline chưa nêu tên ai. Hãy coi danh tính này là phát hiện của bên thứ ba.

• Bị tranh cãi về bản chất, không phải về sự thật. Bargury đánh giá sự việc này khớp với một màn trình diễn nghiên cứu bảo mật hơn là một chiến dịch độc hại, viện dẫn payload lành tính và lịch sử của đối tượng nhắm vào một kho lưu trữ tự động hóa New Relic. Cline gọi đây là một lần xuất bản trái phép, còn Khan viết rằng kẻ đã xuất bản 2.3.0 "theo suy đoán" là cùng một người đã đầu độc các bộ nhớ đệm. Chưa ai chứng minh được có ý định gây hại, và cũng chưa ai chứng minh được là không có.

• Chưa được giải quyết. Ghi chú trước khi công bố của chính Khan rất thận trọng về một điểm mà các bài đưa tin sau này đôi khi làm đơn giản hóa: từ ngày 31 tháng 1 đến ngày 3 tháng 2 năm 2026, nhiều lần chạy hàng đêm đã thất bại với bước Post Checkout không tạo ra đầu ra nào, đây là dấu hiệu xâm phạm của Cacheract, và quy trình phân loại là con đường rõ ràng nhất nhưng chưa được chứng minh là điểm xâm nhập cho hoạt động đó. Cũng không bên nào công bố bằng chứng rằng token của Marketplace hoặc OpenVSX đã bị sử dụng; hiện vật duy nhất mà bất kỳ ai đưa ra là bản dựng npm.

Điều gì đã thay đổi sau đó?

Bản khắc phục đã được triển khai ở nhiều lớp cùng lúc, và đáng để gọi tên từng lớp vì chúng giải quyết những phần khác nhau của sự cố. Quy trình mà người ngoài có thể truy cập đã bị xóa thay vì thu hẹp. Bộ nhớ đệm đã bị gỡ khỏi bốn quy trình phát hành nắm giữ bí mật phát hành, thay vì gỡ khỏi toàn bộ kho lưu trữ, và đây chính là thay đổi phá vỡ bước chuyển hướng then chốt. Thông tin xác thực đã được luân chuyển, và sau bản sửa ngày 17 tháng 2, token npm đúng đã bị thu hồi. Khuyến cáo của Cline nêu rằng việc phát hành npm hiện dùng provenance OIDC qua GitHub Actions, và phân tích siêu dữ liệu của StepSecurity cho thấy vì sao điều đó quan trọng: các bản phát hành hợp lệ vốn đã mang chứng thực provenance, còn 2.3.0 là ngoại lệ bị phát hành bởi một tài khoản người. Lỗ hổng là đường dẫn token dài hạn vẫn mở song song với trusted publishing, đúng là điều Endor Labs lập luận rằng người bảo trì nên đóng lại. Cline đã công bố GHSA-9ppg-jx86-fqw7, đánh dấu 2.3.0 là deprecated với thông điệp rằng không nên cài đặt nó, và hướng người dùng đến 2.4.0 trở lên.

Các khuyến nghị về cấu trúc của Khan đi xa hơn những gì đã được triển khai, và đáng được ghi nhận là của anh ấy, chứ không phải của Cline: loại bỏ Bash, Write và Edit khỏi mọi quy trình phân loại, chỉ để lại cho nó việc đọc tệp và các lệnh gọi GitHub CLI cụ thể mà nó cần; không bao giờ khôi phục bộ nhớ đệm trong một job nắm giữ bí mật phát hành production; và cấp cho các bản phát hành nightly không gian tên registry riêng cùng một danh tính phát hành chuyên dụng phi production, để một token nightly bị đánh cắp hoàn toàn không thể phát hành một bản release ổn định.

Khoảng cách tám ngày giữa bản sửa lỗi và lần phát hành độc hại chính là chi tiết khiến bản ghi này đáng được lưu giữ. Mọi bước trong chuỗi đều là một kỹ thuật đã biết; Khan đã công bố công cụ đầu độc bộ nhớ đệm, và nghiên cứu PromptPwnd của Aikido Security vào tháng 12 năm 2025 đã ghi nhận cùng kiểu cấu hình sai trong phân loại xử lý. Điều kết hợp chúng thành một sự cố chuỗi cung ứng là một quy trình cho phép văn bản của người lạ đi tới shell, một bộ nhớ đệm dùng chung với các job nắm giữ khóa phát hành, và một lần luân chuyển token bỏ sót một thông tin xác thực. Mỗi bản sửa trong ba bản sửa lỗi lẽ ra đã đủ để phá vỡ chuỗi; bản thứ ba đến muộn tám ngày.