Rủi ro bảo mật từ một gói npm giả mạo đã xuất hiện trong cửa sổ 27 phút, khi package tanstack bị lợi dụng để đánh cắp file môi trường của lập trình viên ngay sau khi cài đặt. Vụ việc cho thấy rủi ro bảo mật trong chuỗi cung ứng phần mềm có thể đến từ một tên gói trông hợp lệ nhưng không liên quan đến dự án gốc.
Gói npm giả mạo và cơ chế thực thi
Gói độc hại được đăng ký dưới tên unscoped “tanstack” trên npm, sau đó được ngụy trang thành SDK video hợp lệ có tên “TanStackPlayer”. Bên trong package là một postinstall script chạy tự động khi người dùng thực hiện npm install, không đưa ra cảnh báo rõ ràng.
Phiên bản sạch trước đó là 2.0.3 từ tháng 3/2026 và không chứa hook này. Theo phân tích, tác nhân không cần chiếm tài khoản maintainer, không khai thác lỗ hổng, và cũng không cần lừa CI theo cách phức tạp; chỉ cần đăng ký tên gói, chèn script và chờ cài đặt.
Diễn biến triển khai trong thời gian ngắn
Chiến dịch chỉ kéo dài trong khoảng từ 17:08 đến 17:35 UTC, với bốn phiên bản được đẩy lên liên tiếp: 2.0.4, 2.0.5, 2.0.6 và 2.0.7. Trước khi bị phát hiện, package này đã ghi nhận khoảng 19.830 lượt tải trong tháng trước đó, làm tăng số lượng hệ thống có thể bị ảnh hưởng.
Gói này không có liên hệ với tổ chức gốc TanStack, dù hệ sinh thái liên quan có lượng sử dụng rất lớn. Một lập trình viên nhập nhầm npm install tanstack thay vì npm install @tanstack/query có thể vô tình kích hoạt hành vi trộm dữ liệu ngay lập tức.
Phân tích postinstall script và hành vi exfiltration
Các phiên bản độc hại đều chứa hook postinstall, đây là cơ chế được npm thực thi tự động sau khi cài đặt package. Gói độc hại thu thập nội dung file trong thư mục dự án, sau đó gửi ra ngoài qua Svix, một nền tảng webhooks hợp lệ.
Việc dùng relay của bên thứ ba khiến lưu lượng rò rỉ dữ liệu khó bị chặn bằng các quy tắc mạng thông thường. Dữ liệu bị đánh cắp gồm file nội dung lẫn metadata hệ thống như Node.js version, nền tảng và kiến trúc máy.
Với thông tin này, payload exfiltrated có thể được dùng ngay cho các bước tiếp theo trong tấn công mạng, nhất là khi các file môi trường thường chứa bí mật truy cập quan trọng.
Thay đổi hành vi giữa các phiên bản
Version 2.0.4 nhắm trực tiếp vào .env và .env.local, nhưng cơ chế opt-out bị comment lại nên không có đường thoát cho người dùng.
Version 2.0.5 chuyển tạm sang README.md và AGENTS.md, có khả năng để kiểm tra webhook nhận dữ liệu có hoạt động hay không.
Version 2.0.6 là biến thể nguy hiểm nhất. Nó bỏ hẳn việc chọn file cụ thể và dùng hàm collectEnvFiles() để quét toàn bộ file bắt đầu bằng .env, gồm .env.local, .env.production, .env.staging và .env.development.
Version 2.0.7 quay lại mục tiêu .env và .env.local, đồng thời thêm dependency tự tham chiếu đến 2.0.6 trong package.json. Điều này cho thấy tác nhân đang theo dõi kết quả và tinh chỉnh payload theo thời gian thực.
Ảnh hưởng đến hệ thống và loại dữ liệu nhắm tới
Các file bị nhắm tới thường chứa AWS access keys, GitHub personal access tokens, npm publish tokens, chuỗi kết nối cơ sở dữ liệu, API keys cho Stripe, OpenAI, Twilio, và OAuth client secrets.
Nếu bị exfiltrate, các bí mật này có thể dẫn tới chiếm quyền điều khiển tài khoản, rò rỉ dữ liệu, hoặc tiêu tốn tài nguyên cloud trái phép. Trong môi trường CI, hook postinstall cũng chạy khi dùng npm ci, làm tăng nguy cơ lan rộng sang pipeline.
IOC và dấu hiệu cần kiểm tra
- Package name:
tanstack - Phiên bản độc hại:
2.0.4,2.0.5,2.0.6,2.0.7 - Phiên bản sạch trước đó:
2.0.3 - Endpoint liên quan đến exfiltration:
api.svix.com - Hook thực thi:
postinstall - File đích điển hình:
.env,.env.local,.env.production,.env.staging,.env.development
Lệnh kiểm tra và rà soát môi trường
Để kiểm tra lock file và lịch sử cài đặt trong dự án, có thể dùng lệnh sau:
grep -r "tanstack" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/nullNếu phát hiện bất kỳ version nào trong dải 2.0.4 đến 2.0.7, cần coi toàn bộ environment files có mặt tại thời điểm cài đặt là đã bị xâm nhập.
Trong CI pipeline, cần kiểm tra job logs ở bước cài đặt, vì postinstall cũng được kích hoạt khi chạy npm ci. Các secret đã inject vào môi trường build phải được rotate ngay sau đó.
Các bước ứng phó kỹ thuật cần thực hiện
Ưu tiên rà soát package lock, lịch sử cài đặt và log CI để xác định có tồn tại lỗ hổng chuỗi cung ứng theo nghĩa thực tế từ package độc hại hay không. Đồng thời, theo dõi lưu lượng outbound HTTPS tới api.svix.com trong khoảng thời gian cài đặt để xác nhận khả năng exfiltration.
Do dữ liệu mục tiêu chủ yếu là file môi trường và bí mật ứng dụng, việc thay đổi key/token cần bao gồm các thông tin sau:
- AWS access keys
- GitHub PAT
- npm publish token
- Database credentials
- API keys
- OAuth client secrets
Tham khảo thêm nguồn phân tích gốc tại Aikido Security và cơ sở dữ liệu CVE/NVD tại NVD.
