Plugin4Shell: Bốn tác nhân lập trình AI tin tưởng một bản ghim mà chúng chưa từng kiểm tra

Vào ngày 17 tháng 9 năm 2026, AIR Security, một startup xây dựng công cụ bảo mật cho các tác nhân AI doanh nghiệp, đã công bố nghiên cứu mô tả Plugin4Shell — một lỗ hổng thực thi mã từ xa không cần nhấp chuột trong bốn tác nhân lập trình AI: Claude Code của Anthropic, Codex của OpenAI, GitHub Copilot và Gemini CLI của Google. Lỗi này không nằm trong bất kỳ mô hình nào. Nó nằm ở thao tác git checkout mà mỗi tác nhân thực hiện khi cài đặt plugin, và ở chỗ không tác nhân nào trong bốn tác nhân xác minh rằng mã nó nhận được chính là mã nó đã ghim. Hai trong bốn tác nhân đã có bản vá vào thời điểm nghiên cứu được công bố. Hai tác nhân còn lại thì chưa. Sự cố này là một mục trong Orca AI Incident Archive, nơi ghi nhận nó là một lỗ hổng chuỗi cung ứng mức độ nghiêm trọng cao và không có báo cáo khai thác nào.

Các tác nhân thực sự đã làm sai điều gì

Mỗi agent bị ảnh hưởng cài đặt plugin từ một marketplace và mỗi marketplace ghim một plugin vào một git commit cụ thể — một SHA gồm 40 ký tự — sau khi plugin đã được đánh giá. Việc ghim đó chính là toàn bộ mô hình bảo mật: người đánh giá phê duyệt một phiên bản bất biến và agent được kỳ vọng sẽ tiếp tục chạy phiên bản đó ngay cả khi kho lưu trữ phía sau nó thay đổi về sau. AIR mô tả lỗ hổng này là một kiểu vượt qua cơ chế ghim SHA của plugin. Agent checkout đúng commit mà marketplace đã ghim nhưng không bao giờ xác minh rằng working tree mà nó nhận được chính là commit đó. Theo lời các nhà nghiên cứu, agent “checkout đúng commit mà marketplace đã ghim nhưng không bao giờ xác minh rằng nó đã đến đúng đó, vì vậy kẻ tấn công kiểm soát repo của plugin khiến thao tác checkout phân giải thành mã độc trong khi việc ghim vẫn trông như được tuân thủ.”

Git lấp vào khoảng trống đó. Khi một tên vừa là một nhánh hợp lệ vừa là một đối tượng commit, git sẽ ưu tiên nhánh và chỉ in ra cảnh báo về sự nhập nhằng. Kẻ tấn công kiểm soát kho lưu trữ của plugin sẽ tạo một nhánh có tên đúng bằng chuỗi SHA 40 ký tự hex đã được ghim, trỏ nhánh đó vào mã độc, và biến nó thành nhánh mặc định của kho lưu trữ. Một lệnh clone thông thường sau đó sẽ kéo nhánh đó về máy cục bộ dưới cái tên có dạng SHA, và lệnh checkout tiếp theo sẽ phân giải tới nhánh đó. Bản thân commit đã được ghim có thể vẫn không bị đụng tới, nên không có gì ở phiên bản đã được xem xét trông có vẻ sai. Theo AIR, phải thỏa mãn hai điều kiện: nhánh mang tên SHA phải là nhánh mặc định, vì một nhánh không mặc định chỉ được fetch như một remote-tracking ref và lệnh checkout sẽ quay về commit thật; và máy chủ git phải chấp nhận tên nhánh 40 ký tự hex. GitHub từ chối thẳng những tên như vậy. Bitbucket và các máy chủ git tự lưu trữ thì không.

Gemini CLI thất bại theo một con đường khác. Nó đã tìm nạp commit được ghim, ghi lại commit đó vào tệp FETCH_HEAD của kho lưu trữ, rồi chạy thao tác checkout FETCH_HEAD — một thao tác checkout không nhất thiết phải đọc tệp đó. Một kho lưu trữ có nhánh mặc định tự nó được đặt tên là FETCH_HEAD sẽ chuyển hướng thao tác checkout đến nội dung do kẻ tấn công kiểm soát và âm thầm loại bỏ commit đã được tìm nạp. Bài mô tả của Cybersecurity News về cơ chế này khớp với mô tả của AIR, bao gồm cả sự phân biệt giữa hai biến thể.

Tại sao không ai phải nhấp vào bất cứ thứ gì

Cùng một checkout lại được chạy trong quá trình tự động cập nhật plugin chạy nền, vốn là mặc định trong Claude Code và Codex. Đó chính là điều khiến cuộc tấn công trở thành zero-click thay vì chỉ âm thầm: khi một marketplace nâng một SHA đã được ghim lên một phiên bản mới thông thường, mọi agent đã cài plugin đó sẽ chạy lại checkout mà không có lời nhắc và không cần người dùng thao tác. Ý của AIR là nạn nhân không cần phải cài đặt bất cứ thứ gì một cách bất cẩn. Họ chỉ cần đã cài một plugin, từ một marketplace mà họ tin tưởng, đã được đánh giá và ghim đúng như thiết kế dự định.

Có hai cách để đạt được vị trí đó, và không cách nào đòi hỏi phải kiểm soát chợ ứng dụng. Thứ nhất, kẻ tấn công phát hành một plugin thực sự vô hại vượt qua được vòng kiểm duyệt, xây dựng lượng người dùng cài đặt, phát hành một bản cập nhật bình thường, và chỉ sau đó mới tạo ra nhánh được đặt tên độc hại. Thứ hai, kẻ tấn công chiếm đoạt kho lưu trữ đằng sau một plugin do người khác viết và đã được chợ ứng dụng tin tưởng, rồi đẩy phiên bản độc hại ra cho tất cả những ai đã cài đặt nó.

Những con số đằng sau hai hướng đi đó đến từ công trình trước đây của AIR, không phải từ Plugin4Shell. Trong một chiến dịch mà công ty gọi là The Story of Skills, họ nói rằng một plugin do họ xây dựng đã lan tới hơn 26.000 agent trước khi bị gỡ. Trong SkillJacking, họ báo cáo rằng 925 kỹ năng đang được sử dụng tích cực đã bị tiếp quản từ những người bảo trì ban đầu, tiếp cận 134.000 agent. Tiêu đề bài đăng của AIR về Plugin4Shell tuyên bố “hàng triệu agent bị ảnh hưởng”; nghiên cứu không đưa ra con số nào về các bản cài đặt bị phơi nhiễm, và chưa có bên thứ ba nào công bố con số đó.

Dòng thời gian và nơi các bản sửa lỗi đã được áp dụng

AIR cho biết họ đã phát hiện ra lỗ hổng vào tháng 5/2026 cùng với các mã khai thác proof-of-concept hoạt động được nhắm vào cả bốn tác tử, và đã công bố cho từng nhà cung cấp vào tháng sau theo hình thức công bố phối hợp. Anthropic đã xác nhận bản sửa lỗi trong Claude Code 2.1.179 vào ngày 17 tháng 6. Google nói với AIR vào ngày 4 tháng 8 rằng sẽ không phát hành bản sửa lỗi nào, vì Gemini CLI đang bị ngừng phát triển. Codex 0.146.0 đã được xác minh là đã sửa vào ngày 12 tháng 8. Microsoft vẫn chưa phát hành bản sửa lỗi cho GitHub Copilot.

Các phiên bản vá là xác nhận công khai duy nhất rằng lỗ hổng là có thật trong hai sản phẩm đã khắc phục nó. Mục nhật ký thay đổi đã công bố của Anthropic cho 2.1.179 liệt kê việc xử lý mất kết nối, cuộn trong WSL2, sửa lỗi glob trong sandbox và giao diện, và không đề cập đến pinning, xác minh plugin hay bất kỳ bản sửa lỗi bảo mật nào. Theo bài viết của The Next Web, The Hacker News cũng đưa ra nhận định tương tự. Tính đến thời điểm công bố nghiên cứu, chưa có mã định danh CVE nào được gán, và ghi chú nghiên cứu của Cloud Security Alliance về lỗ hổng này nhắc lại rằng không có mã định danh nào tồn tại ba tháng sau khi các nhà cung cấp được thông báo.

Bốn nhà cung cấp, ba câu trả lời khác nhau

Google đã đi xa hơn việc từ chối vá lỗi. Họ đã ngừng hỗ trợ Gemini CLI, nghĩa là các bản cài đặt hiện có vẫn bị phơi nhiễm chừng nào người ta còn tiếp tục chạy chúng. Lời khuyên của họ là chuyển sang Antigravity, môi trường phát triển tác nhân mới hơn, mà AIR nói rằng cuộc tấn công không chạm tới vì nó không có cơ chế ghim SHA cho plugin trên marketplace để bị vượt qua.

Lập trường của GitHub lại khác. Một người phát ngôn của GitHub nói với The Register rằng nền tảng này không cho phép người dùng tạo tên nhánh hoặc tên thẻ giống với SHA của commit, và rằng "biện pháp giảm thiểu này bảo đảm lỗ hổng được báo cáo không thể bị khai thác trên GitHub." AIR tranh cãi về phạm vi của biện pháp giảm thiểu đó chứ không phải sự tồn tại của nó: các nhà nghiên cứu nói với The Register rằng marketplace có thể được lưu trữ trên các nền tảng khác như Bitbucket, và GitHub Copilot vẫn hỗ trợ marketplace từ những nền tảng đó, nên biến thể dùng tên nhánh vẫn có thể tiếp cận được đối với người dùng Copilot. AIR cũng cho biết tài liệu của chính Anthropic liệt kê Bitbucket và git tự vận hành là các phần phụ trợ marketplace hợp lệ; tài liệu marketplace hiện tại của Anthropic mô tả việc thêm một marketplace từ URL kho lưu trữ git, chứ không chỉ từ GitHub. Microsoft không phản hồi yêu cầu bình luận của The Register, và AIR cho biết họ chưa nhận được phản hồi nào từ Microsoft kể từ khi báo cáo vấn đề vào tháng 6, với lý do là khối lượng công bố lỗ hổng mà công ty đang xử lý.

Đây là bất đồng về phạm vi ảnh hưởng, không phải về việc lỗi có tồn tại hay không. Biện pháp giảm thiểu của GitHub là một hạn chế ở cấp máy chủ; phát hiện của AIR là việc kiểm tra phải diễn ra bên trong agent, vì pin được phân giải ở phía client.

Điều gì đã được xác lập, và điều gì chưa.

• Đã xác lập: bài viết của AIR đưa ra các lệnh git chính xác, quy tắc phân giải ưu tiên ref hơn object, hai điều kiện mà thủ thuật nhánh yêu cầu, và biến thể FETCH_HEAD riêng cho Gemini CLI. The Register, Help Net Security, Cybersecurity News, InfoWorld và The Next Web đều đưa tin theo cùng cách.

• Đã xác lập: hai phiên bản đã được vá. Anthropic đã xác nhận Claude Code 2.1.179 vào ngày 17 tháng 6 năm 2026 và Codex 0.146.0 của OpenAI đã được xác minh là đã khắc phục vào ngày 12 tháng 8 năm 2026, theo dòng thời gian công bố thông tin của AIR.

• Đã xác nhận: hai sản phẩm không có bản vá tại thời điểm công bố. Google sẽ không vá Gemini CLI và đang ngừng cung cấp nó; Microsoft chưa phát hành bản sửa lỗi cho Copilot.

• Chưa được xác lập: tái tạo độc lập. Mọi tài liệu đã công bố đều bắt nguồn từ bài đăng blog của chính AIR, và ghi chú nghiên cứu của Cloud Security Alliance nêu rõ rằng không mô tả việc xác thực kỹ thuật bởi bên thứ ba hoặc tái tạo độc lập lỗ hổng này. Vì lý do đó, kho lưu trữ xếp mức độ tin cậy của bản ghi này ở mức B.

• Chưa xác định: có bao nhiêu bản cài đặt thực sự bị phơi nhiễm. “Hàng triệu” là cách AIR mô tả trong tiêu đề, không phải một con số được đo đạc.

• Chưa được xác định:liệu việc cập nhật một agent bị ảnh hưởng có gỡ bỏ một plugin đã được hoán đổi hay không, hay chỉ ngăn lần hoán đổi tiếp theo. Không có nguồn công bố nào giải quyết được điều này.

• Chưa được xác lập:bất kỳ việc sử dụng nào trong thực tế. Không có nguồn nào trong hồ sơ báo cáo việc khai thác, thăm dò hoặc cơ sở hạ tầng của kẻ tấn công, và kho lưu trữ ghi nhận thiệt hại thực tế là sai. Đó là sự thiếu vắng báo cáo, không phải bằng chứng cho thấy không có gì xảy ra.

Một đợt kiểm tra của bên thứ ba quả có thu hẹp bức tranh thực tiễn. The Next Web, khi tóm tắt các đợt kiểm tra của The Hacker News, đưa tin rằng các plugin trong danh mục cộng đồng của Anthropic và trong các danh mục mặc định của Claude Code và Copilot đều trỏ đến các kho GitHub, và rằng tính năng tự động cập nhật được bật theo mặc định chủ yếu đối với những marketplace tích hợp sẵn đó. Vì GitHub từ chối các tên nhánh có dạng SHA, biến thể dùng tên nhánh khó tiếp cận hơn đối với người dùng vẫn dùng các danh mục mặc định. Lập luận đó không bao quát biến thể FETCH_HEAD của Gemini CLI, vốn không phụ thuộc vào cách máy chủ đặt tên nhánh.

Một bản sửa lỗi phải trông như thế nào

Bản sửa được AIR khuyến nghị là một phép khẳng định duy nhất: sau khi checkout, hãy phân giải commit thực sự có trong working tree và hủy bỏ trừ khi nó bằng SHA đã được ghim. Các nhà nghiên cứu nhấn mạnh rằng nó phải kiểm tra HEAD đã được phân giải thay vì ref đã được yêu cầu, vì chính sự khác biệt đó là thứ mà biến thể Gemini CLI lách qua, và rằng nó phải chạy bên trong agent, vì chiếc ghim được phân giải ở phía client và không marketplace nào có thể thực thi đảm bảo mà nó quảng cáo.

Lời khuyên thực tế dành cho các nhóm vận hành những agent này, được rút ra từ AIR, Cybersecurity News và phần bình luận của chuyên gia trên InfoWorld:

• Cập nhật Claude Code lên 2.1.179 trở lên và Codex lên 0.146.0 trở lên. Việc cập nhật là biện pháp giảm thiểu hoàn chỉnh duy nhất khi có bản vá.

• Tắt tính năng tự động cập nhật plugin trên mọi agent không có bản vá. Điều này làm giảm lỗ hổng từ zero-click xuống cài đặt lại thủ công, tức là giảm mức độ phơi nhiễm chứ không phải sửa lỗi.

• Hãy chuyển khỏi Gemini CLI thay vì chờ một bản vá mà Google đã nói sẽ không đến.

• Kiểm tra kiểm kê plugin và hạn chế nguồn marketplace khi có thể. AIR lưu ý rằng marketplace có thể làm giảm nhẹ biến thể tên nhánh bằng cách chỉ cho phép các host từ chối tên có dạng SHA, trên thực tế là chỉ còn GitHub, nhưng việc này cấm các host mà các agent chính thức hỗ trợ và không có tác dụng gì đối với biến thể Gemini.

• Hãy coi máy trạm là ranh giới phơi nhiễm. Các plugin kế thừa quyền của agent, nên một vụ khai thác thành công sẽ chạm tới mã nguồn, khóa SSH, thông tin đăng nhập đám mây, token CI/CD và các kho nội bộ bằng chính quyền hạn của nhà phát triển. Pareekh Jain, chuyên gia phân tích chính tại Pareekh Consulting, nói với InfoWorld rằng các nhóm bảo mật nên xem xét nhật ký EDR, git, CI/CD, cloud IAM và xác thực để tìm các tiến trình bất thường, tệp plugin không mong đợi, kho đã bị thay đổi và hoạt động git đáng ngờ — và nói thêm rằng những bước này giảm rủi ro mà không khắc phục lỗ hổng cốt lõi, mà ông cho là do mã của nhà cung cấp. "Doanh nghiệp có thể đặt các biện pháp kiểm soát quanh việc sử dụng plugin," ông nói với InfoWorld, "nhưng họ không thể khắc phục một lỗ hổng trong cách agent lập trình xác thực đoạn mã mà nó check out."

Vì sao lỗi pinning lại là lỗi quan trọng nhất

SHA pinning là câu trả lời của ngành cho đúng kiểu chiếm quyền kiểm soát mà AIR đã từng chứng minh: nếu một kho công khai bị xâm phạm, agent vẫn tiếp tục chạy hash đã được kiểm toán thay vì kéo về bất cứ thứ gì kẻ tấn công đã đẩy lên. Plugin4Shell không phá vỡ hash. Nó cho thấy các agent đã phân giải pin thành một tên nhánh chỉ trông giống hash, và không bao giờ so sánh kết quả. Mọi thứ nằm sau giả định đó — quy trình đánh giá, allowlist nội bộ, niềm tin mà nhà phát triển đặt vào một phiên bản đã pin — đều kế thừa lỗi này.

Điều mà hồ sơ không ủng hộ là tuyên bố rằng có bất cứ thứ gì đã bị lấy đi. Đây là một lỗ hổng đã được phát hiện và, trong hai trong bốn trường hợp, đã được khắc phục; không có nguồn nào trong đó báo cáo về một vụ xâm nhập, và các sản phẩm chưa phát hành bản vá vẫn đang chờ. Câu hỏi còn bỏ ngỏ là câu hỏi kém thỏa đáng nhất: đối với bất kỳ ai đã chạy một plugin trên một agent chưa được vá, không có cách nào được công bố để biết liệu mã đã chạy có phải là mã mà họ đã phê duyệt hay không.