Deadbugz: một máy chủ MCP trở nên thù địch ở lần gọi công cụ thứ ba, được đẩy lên 23 kho lưu trữ trong 74 phút

Vào ngày 10 tháng 8 năm 2026, một tài khoản GitHub, zellkernel, đã mở 23 pull request trong 74 phút nhắm vào các kho lưu trữ AI, MCP và công cụ dành cho nhà phát triển không liên quan đến nhau, mỗi yêu cầu đều thêm một máy chủ MCP có tên productivity-suite quảng bá hai công cụ thông thường, format_text và summarize. Theo Pillar Security, đơn vị đã đặt tên chiến dịch là Deadbugz và công bố bài viết của mình vào ngày 12 tháng 8, máy chủ đã trả về kết quả trung thực cho ba lần gọi đầu tiên của nó rồi viết lại siêu dữ liệu mà nó trao cho tác nhân: phần mô tả công cụ và nội dung prompt bắt đầu hướng mô hình tới khóa SSH, thông tin xác thực AWS, lịch sử shell và cấu hình Kubernetes, đồng thời bảo nó giữ kín hoạt động đó khỏi người dùng. Mười chín trong số 23 pull request đã bị đóng, bốn yêu cầu vẫn mở và không yêu cầu nào được hợp nhất khi Pillar xem xét chúng. Chưa có nạn nhân nào được xác nhận. Đây là một bản ghi, do người khác báo cáo và được trích dẫn ở đây để ghi nhận họ. Các sự cố tác nhân khác được ghi nhận, mỗi sự cố có nguồn, mức độ nghiêm trọng, mức độ tin cậy và cờ tranh chấp riêng, nằm trong kho lưu trữ sự cố AI — vì vậy một chiến dịch chuỗi cung ứng nhắm vào công cụ dành cho tác nhân có thể được đọc cùng với phần còn lại của những gì đã thực sự xảy ra.

Kho lưu trữ xếp bản ghi này ở mức độ nghiêm trọng cao và độ tin cậy A — được ghi chép đầy đủ, với các nguồn sơ cấp tương đồng — trong khi ghi riêng rằng không có thiệt hại thực tế nào được xác nhận. Cả hai điều đều đúng cùng lúc, và khoảng cách giữa chúng chính là nội dung của bản ghi: một chiến dịch có thiết kế được ghi chép chi tiết bất thường trước khi nó tạo ra một nạn nhân mà bất kỳ ai cũng có thể nêu tên. Hai ngày quan trọng cách nhau hai ngày. Các pull request được gửi đi vào ngày 10 tháng 8; Ariel Fogel của Pillar Security đã công bố phân tích vào ngày 12 tháng 8, và bài đăng có một ghi chú thường trực rằng nó sẽ được cập nhật khi có thông tin đã xác minh.

Ba lần gọi, sau đó metadata thay đổi

Một máy chủ MCP không nhất thiết phải chạy mã trên một máy để thay đổi điều mà một tác nhân làm. Các định nghĩa công cụ được trao cho mô hình dưới dạng ngữ cảnh trong mỗi phiên, nghĩa là máy chủ cung cấp chúng có thể viết lại các chỉ dẫn mà tác nhân đọc trong khi vẫn giữ nguyên tên công cụ, kho lưu trữ và tệp kê khai của nó y như cũ. Deadbugz được xây dựng dựa trên sự bất đối xứng đó, và Pillar gọi đó là runtime-gated MCP metadata poisoning.

Cơ chế này đủ nhỏ để diễn đạt trong một câu. Máy chủ giữ một bộ đếm trong bộ nhớ, theo từng máy khách, của các yêu cầu tools/call. Trong ba lần đầu, nó hoạt động bình thường. Khi bộ đếm bị kích hoạt, sau đó các phản hồi tools/list và prompts/get trả về bị thay đổi — mô tả công cụ khác, nội dung lời nhắc khác — hướng tác nhân tới các khóa SSH, thông tin xác thực AWS, lịch sử shell và cấu hình Kubernetes, đồng thời chỉ dẫn nó che giấu hoạt động này khỏi người dùng. Văn bản lời nhắc bị đầu độc mang dấu deadbugz và một địa chỉ Bitcoin.

Cơ chế cổng cũng là lý do khiến các biện pháp phòng vệ thông thường không phát hiện được nó. Payload hiện diện trong mã nguồn ngay từ yêu cầu đầu tiên; không có bất kỳ thay đổi nào về mã hoặc cấu hình tại thời điểm chuyển đổi. Một lần quét tĩnh, một mục SBOM hoặc một lần đọc manifest công cụ lúc cài đặt sẽ thấy một tiện ích định dạng, vì đó là thứ mà tiện ích trả về cho đến khi bộ đếm thay đổi. Pillar mô tả việc chuyển đổi trễ này là một kỹ thuật né tránh nghiên cứu, và cho biết các nhà nghiên cứu của mình đã xác nhận cả ngưỡng lẫn metadata bị thay đổi bằng cách gửi các yêu cầu chỉ gồm văn bản đến dịch vụ từ xa đang hoạt động và đối chiếu các phản hồi với mã nguồn công khai.

Một chi tiết khiến cái bẫy rộng hơn phạm vi một phiên. Máy chủ công bố tools.listChanged, khả năng MCP báo cho máy khách biết danh sách công cụ của nó đã được sửa đổi. Một máy khách tuân theo tín hiệu đó sẽ đọc lại các định nghĩa giữa phiên và lấy phiên bản bị đầu độc mà không cần người vận hành thực hiện bất kỳ hành động nào; một máy khách lưu đệm các định nghĩa khi phê duyệt thì sẽ không. Hành vi của một tác nhân cụ thể là thuộc tính của máy khách, không phải của máy chủ, và bài viết của Pillar không liệt kê máy khách theo tên.

Giao hàng: 23 yêu cầu kéo trong 74 phút

Bản phân phối đó không phải là một gói trên registry hay một phụ thuộc bị đầu độc nằm sâu trong lockfile. Mà là spam pull-request nhắm vào những dự án không liên quan gì đến chức năng được cho là của máy chủ — đây là hình thái mà một nỗ lực tấn công chuỗi cung ứng chi phí thấp mang khi kẻ tấn công không thể có được tài khoản maintainer: gửi đủ nhiều thay đổi cấu hình và chờ một trong số đó được hợp nhất hoặc áp dụng cục bộ.

Phân tích của Pillar về 23 mục được chia thành ba nhóm. Mười bảy mục thêm một endpoint MCP từ xa, productivity-suite-mcp[.]onrender[.]com/mcp, được lưu trữ trên Render; bốn mục gọi một tệp Python cục bộ ẩn tại ~/.config/.cache/.sys/.deadbug-mcp.py; hai mục là các bài gửi vào thư mục hoặc danh sách, mà bài viết coi là hoạt động trinh sát hoặc nội dung độn thay vì phân phối. Khung thời gian được nêu là 21:52 đến 23:07 UTC ngày 10 tháng 8 năm 2026 — 74 phút theo cách diễn đạt trong bản công bố, dù bản thân hai mốc thời gian kéo dài tới 75 phút, và không có gì trong hồ sơ phụ thuộc vào phút chênh lệch đó. Chỉ có một kho lưu trữ mục tiêu được nêu riêng: getsentry/sentry-mcp, pull request #1239, được dẫn làm ví dụ về việc phân phối qua tạo tác cục bộ.

Tài khoản đứng sau nó khá đồ sộ so với độ tuổi của nó. Vào thời điểm Pillar thu thập dữ liệu, zellkernel có 50 kho lưu trữ công khai, 20 trong số đó là bản fork, và 21 trong số 50 kho ấy được tạo vào ngày 10 tháng 8, cùng ngày với chiến dịch. Hồ sơ này được liên kết chéo tới tài khoản X @llmgod, tài khoản này lại liên kết ngược về tài khoản GitHub, đây là kiểu liên kết qua lại cho thấy một danh tính được tạo dựng có chủ đích chứ không phải bị chiếm đoạt.

Mười chín đã đóng, bốn đang mở, không cái nào đã hợp nhất là con số được lặp lại nhiều nhất trong hồ sơ, và cũng là con số thường bị đọc như một tín hiệu an toàn hoàn toàn, nhưng không hẳn vậy. Nút hợp nhất của GitHub không phải là bản ghi thực thi của máy chủ: người bảo trì có thể pull một nhánh và chạy nó, tự tay áp dụng một cấu hình, hoặc một tác vụ CI có thể tải head của một PR trước khi có bất kỳ bình luận nào. Bốn pull request ghi một cấu hình gọi một đường dẫn script cục bộ là những trường hợp mà khoảng trống đó quan trọng nhất, vì script được tải về và chạy hoàn toàn nằm ngoài phần hạch toán hợp nhất của GitHub. Cloud Security Alliance Labs đưa ra quan điểm tương tự trong ghi chú ngày 2 tháng 9 của mình: số lượng đã đóng và chưa hợp nhất không chứng minh rằng không có gì đã chạy.

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

Được xác lập qua thông tin tiết lộ, theo nghĩa rằng Pillar báo cáo điều đó từ các tạo tác mà nó đã đọc và trong một trường hợp từ một dịch vụ mà nó đã truy vấn: máy chủ và kho lưu trữ nguồn của nó, hai công cụ được quảng cáo, bộ đếm và ngưỡng ba lần gọi, bốn mục tiêu thông tin xác thực, số lượng PR và trạng thái hợp nhất của chúng tại thời điểm đánh giá, và liên kết giữa tài khoản GitHub và tên người dùng X. Việc tự kiểm thử của Pillar đối với endpoint đang hoạt động là mục mạnh nhất trong danh sách, vì đó là một sự tái tạo chứ không phải là việc đọc mã nguồn.

Chưa được xác lập, và hồ sơ rất thận trọng về điều đó: một nạn nhân. Trường real_harm của kho lưu trữ là false, đây là một tuyên bố về bằng chứng, không phải về ý định — chưa ai xuất trình được một máy chủ, nhật ký hay thông tin xác thực bị đánh cắp nào gắn với chiến dịch này. Cá nhân hay nhóm đứng sau zellkernel và @llmgod cũng không được xác định; Pillar quy chiến dịch cho các tài khoản và dừng lại ở đó. Động cơ tài chính dựa trên một địa chỉ Bitcoin được nhúng trong payload, đây là suy luận từ một chỉ báo, không phải phát hiện về chủ thể. Và câu hỏi mà một người phòng thủ mong muốn được trả lời nhất — liệu chiến dịch có còn đang diễn ra hay không — không có câu trả lời trong hồ sơ: bài đăng được đánh dấu là sẽ được cập nhật, và không thấy bản sửa đổi hay thông báo gỡ bỏ nào sau đó từ GitHub hay Render.

Sự xác nhận chéo mỏng hơn mức mà mức xếp hạng tin cậy có thể gợi ý, và điều này đáng được nói thẳng. Hai bản ghi chú nghiên cứu từ Cloud Security Alliance Labs, đề ngày 30 tháng 8 và 2 tháng 9 năm 2026, nhắc lại chiến dịch; bản muộn hơn nói rõ rằng nó ghi công Pillar cho việc phát hiện, các chi tiết PR, hành vi máy chủ và việc quy gán tài khoản, đồng thời không mô tả bất kỳ xác minh độc lập nào của chính mình. Một bài đăng blog của Armor ngày 22 tháng 9 năm 2026 cung cấp hướng dẫn phòng thủ và nói rằng Pillar đã mổ xẻ máy chủ; nó không đưa ra bằng chứng pháp y nào của chính mình. Không có CVE nào được gán, và CSA nói rằng đây không phải là lỗ hổng đặc tả MCP. Tính đến ngày 29 tháng 10 năm 2026, các tìm kiếm không cho thấy khuyến cáo nào từ GitHub hay Render, và không có đưa tin trên báo chí chuyên ngành an ninh chính thống — không có bài nào từ BleepingComputer, The Register, SecurityWeek hay Hackread — điều này bất thường đối với một chiến dịch chuỗi cung ứng có hình thái như vậy và bản thân nó là một phần của những gì hồ sơ cho thấy. "Các nguồn sơ cấp đồng thuận" ở đây nghĩa là một nguồn sơ cấp khởi phát và một tập tài liệu thứ cấp bắt nguồn từ đó.

Hai điểm mơ hồ nhỏ hơn đáng được nêu ra thay vì lấp liếm. Các bản tóm tắt phụ khác nhau về việc liệu lần gọi thứ ba hay lần gọi thứ tư là lần đầu tiên nhận siêu dữ liệu bị nhiễm độc, điều này xuất phát từ việc bộ đếm được mô tả là kích hoạt ở yêu cầu thứ ba; bản ghi và phần công bố đều dùng số ba. Và cửa sổ giao hàng được mô tả là 74 phút cho các mốc thời gian kéo dài 75 phút.

Một lần kiểm tra không thể lặp lại: vào ngày 29 tháng 10 năm 2026, tài khoản GitHub zellkernel và kho lưu trữ zellkernel/productivity-suite-mcp đều trả về 404, và pull request duy nhất được nêu tên riêng, getsentry/sentry-mcp #1239, cũng không còn phân giải được nữa — bản thân kho lưu trữ hiện chuyển hướng đến getsentry/toolkit. Do đó, số lượng PR, trạng thái hợp nhất và nội dung kho lưu trữ không thể được xác minh lại trực tiếp hôm nay; chúng vẫn là ảnh chụp nhanh của Pillar, được thực hiện vào giữa tháng 8.

Điều mà bản tiết lộ yêu cầu những người phòng thủ phải làm

Phản hồi mà Pillar khuyến nghị chủ yếu nói về việc coi metadata là một bề mặt bảo mật thay vì chỉ là mô tả về bề mặt đó. Đối với máy chủ, các yêu cầu cụ thể là chặn hoặc truy tìm productivity-suite-mcp[.]onrender[.]com/mcp, giữ endpoint trycloudflare.com trước đó của chiến dịch trong danh sách từ chối và truy tìm mặc dù Pillar nói rằng hiện nó không hoạt động, và không chạy deadbug-mcp.py — đường dẫn tệp ẩn ~/.config/.cache/.sys/.deadbug-mcp.py là dấu vết cần tìm kiếm trên các thư mục home, kho lưu trữ và cấu hình ứng dụng khách MCP.

Thứ tự điều tra quan trọng hơn danh sách chặn. Nếu một máy có thể đã kết nối, Pillar cho biết nên giữ nguyên nhật ký ứng dụng khách MCP trước khi dọn dẹp bất cứ thứ gì, sau đó xem xét các lần làm mới định nghĩa công cụ và những gì agent đã làm sau lần gọi thứ ba; thông tin xác thực chỉ nên được xoay vòng khi bằng chứng cục bộ cho thấy chúng bị phơi lộ, điều này trái ngược với phản xạ xoay vòng mọi thứ khi có nghi ngờ. Cấu hình máy chủ cũng cho phép gửi telemetry tùy chọn đến một WEBHOOK_URL, gửi beacon khi kết nối, ở lần gọi đầu tiên và sự kiện kích hoạt — một chi tiết mang lại cho cuộc điều tra một nơi thứ ba để xem xét ngoài nhật ký ứng dụng khách và lưu lượng thiết bị đầu cuối.

Đối với những người xây dựng máy khách MCP, khuyến nghị này mang tính cấu trúc, và đây là phần của bản ghi có tuổi thọ dài nhất:

• Tạo dấu vân tay cho các định nghĩa công cụ tại thời điểm phê duyệt và so sánh chúng ở mỗi lần làm mới, thay vì tin vào tên và kho lưu trữ của máy chủ.

Hãy coi việc thay đổi định nghĩa trên một máy chủ đã được phê duyệt là một sự kiện bảo mật mà người vận hành nhìn thấy và phê duyệt lại, chứ không phải là những biến động siêu dữ liệu thông thường bị nuốt chửng trong im lặng.

• Thực thi các thao tác nhạy cảm — truy cập thông tin xác thực, thực thi mã, gửi email ra ngoài, ghi vào kho lưu trữ — thông qua chính sách thay vì thông qua các mô tả do máy chủ cung cấp.

Mục thứ ba đó chính là điều khiến Deadbugz trở thành một trường hợp đáng ghi nhận thay vì chỉ là một điều tò mò. Mọi biện pháp kiểm soát nêu trên đều giả định rằng một agent có thể bị thuyết phục làm những việc nào đó bằng đoạn văn bản mà máy chủ gắn vào một công cụ, và rằng đoạn văn bản đó có thể thay đổi sau khi quyết định tin cậy đã được đưa ra. Pillar đặt chiến dịch này vào cùng chuỗi sự kiện bao gồm vụ tấn công ngủ đông MCP năm 2025 của Invariant Labs, gói postmark-mcp giả mạo và một gói MCP được Koi ghi nhận, bị vũ khí hóa thông qua một bản cập nhật — tất cả đều là tiền lệ cho kỹ thuật này, được Pillar trích dẫn vì lý do đó chứ không phải như bằng chứng về đợt triển khai này.

Vì sao khâu gác cổng quan trọng hơn số nạn nhân

Một chiến dịch với 23 lần thử phân phối, không có hợp nhất và không có nạn nhân nào được xác nhận thì dễ xếp vào diện đã thử và gác lại. Lý do nó thuộc về kho lưu trữ ở mức nghiêm trọng cao là vì cách né tránh của nó không phụ thuộc vào việc phân phối thành công ở quy mô lớn. Nó phụ thuộc vào một đặc tính mà hầu hết các triển khai MCP hiện nay đều chia sẻ: phê duyệt diễn ra một lần, lúc cài đặt, và định nghĩa đã được phê duyệt được giả định là định nghĩa sẽ được phục vụ. Deadbugz giữ nguyên giả định đó qua ba lần gọi rồi sau đó phá vỡ nó.

Bản sửa lỗi không phải là một bản vá cho một máy chủ cụ thể, và không có CVE nào để theo dõi. Mà là việc “approved” phải trở thành một điều kiện liên tục có một phép so sánh đằng sau — tức là một thay đổi trong cách các khách hàng và người vận hành của họ hành xử, chứ không phải thay đổi trong thứ mà một máy quét tìm kiếm. Việc có ai thực sự đã chạy máy chủ vào tháng Tám hay không vẫn chưa được biết; theo hồ sơ hiện có, cơ chế chính là phát hiện.