Ba lỗ hổng MCP TypeScript SDK: cách kiểm tra máy chủ HTTP

Một máy chủ MCP chạy tốt cho một người dùng có thể trở nên nguy hiểm khi mở qua HTTP cho nhiều nhóm. Ngày 20/10/2026, GitHub Advisory Database cập nhật ba cảnh báo mức cao cho MCP TypeScript SDK. Các lỗi không cùng nguyên nhân: một lỗi lộ tác vụ giữa phiên, một lỗi làm cạn bộ nhớ, và một lỗi giao phản hồi cho nhầm máy khách.

MCP, viết tắt của Model Context Protocol, là giao thức để ứng dụng AI gọi công cụ và lấy dữ liệu. Khi triển khai MCP qua HTTP, máy chủ phải tách rõ phiên, giới hạn đầu vào và định tuyến phản hồi đúng kết nối. Chỉ nâng gói mà giữ nguyên kiến trúc chia sẻ có thể chưa đủ.

CVE-2026-111767: tác vụ thử nghiệm không gắn với phiên tạo ra

Theo GHSA-22jm-h49p-29qw, @modelcontextprotocol/sdk từ 1.24.0 đến trước 1.32.0 không kiểm tra chủ sở hữu của tác vụ thử nghiệm lưu trong taskStore. Nếu nhiều máy khách dùng chung một InMemoryTaskStore, máy khách này có thể liệt kê, đọc hoặc hủy tác vụ của máy khách khác.

Lỗi chỉ xuất hiện khi máy chủ HTTP truyền taskStore vào McpServer hoặc Server. Dòng 2.x không bị ảnh hưởng bởi lỗi này. Bản vá là 1.32.0; biện pháp tạm thời là bỏ taskStore hoặc tạo một kho riêng cho từng phiên. GitHub chấm mức cao, CVSS 8,6.

CVE-2026-111768: một yêu cầu có thể làm cạn bộ nhớ

GHSA-46jr-4wx8-v453 mô tả yêu cầu HTTP vẫn nằm trong giới hạn mặc định 4 MiB nhưng chứa số lượng phần tử mảng hoặc khóa đối tượng rất lớn. Quá trình kiểm tra dữ liệu có thể dùng hết bộ nhớ và làm dịch vụ ngừng đáp ứng. SDK 1.x từ 1.3.0 đến trước 1.32.0 và server 2.x từ 2.0.0 đến trước 2.3.0 bị ảnh hưởng.

Nâng lên 1.32.0 hoặc 2.3.0 là chưa đủ vì maxToolInputElements mặc định tắt. Đội phát triển còn phải đặt giới hạn phù hợp cho số phần tử đầu vào và giảm maxRequestBodySize theo kích thước công cụ thực tế. Nếu lớp xác thực nằm sau SDK, kẻ gửi yêu cầu không cần đăng nhập để kích hoạt đường xử lý này.

CVE-2026-111770: chia sẻ máy chủ có thể giao nhầm phản hồi

Theo GHSA-jm63-cq47-j5jp, @modelcontextprotocol/server từ 2.0.0 đến trước 2.3.0 có thể giao phản hồi hoặc thông báo của một máy khách HTTP cho máy khách khác khi nhiều kết nối dùng chung transport hoặc cùng một server instance. Nguyên nhân liên quan va chạm mã định danh JSON-RPC giữa các máy khách.

Bản vá là 2.3.0, nhưng kiến trúc cũng phải thay đổi: tạo server và transport riêng cho từng yêu cầu hoặc từng phiên, hoặc dùng factory handler theo hướng dẫn của dự án. Máy chủ chỉ dùng stdio, tức trao đổi qua luồng vào/ra của một tiến trình cục bộ, không nằm trong phạm vi ba kịch bản HTTP nói trên.

Bảng quyết định nhanh

Checklist triển khai an toàn

1. Kiểm kê package thực tế bằng tệp khóa, không chỉ nhìn package.json; xác định đang dùng nhánh 1.x hay 2.x.
2. Xác định giao thức: stdio hay HTTP. Với HTTP, vẽ lại ranh giới phiên, nơi tạo server, transport và taskStore.
3. Nâng gói trong một nhánh riêng; chạy lại kiểm thử tương thích cho công cụ, tài nguyên, thông báo và tác vụ dài.
4. Đặt giới hạn số phần tử, kích thước thân yêu cầu và thời gian xử lý. Kiểm tra phản hồi 4xx khi vượt ngưỡng.
5. Thử đồng thời nhiều phiên có cùng JSON-RPC id để xác nhận không giao nhầm kết quả.
6. Quan sát bộ nhớ, số yêu cầu bị từ chối và lỗi phiên sau khi triển khai; chuẩn bị quay lại bản đã biết an toàn nếu ứng dụng hỏng.

Các cảnh báo không nêu bằng chứng khai thác thực tế. Vì vậy, đội vận hành nên ưu tiên theo mức phơi bày: máy chủ HTTP công khai và đa khách hàng cần xử lý trước; máy chủ stdio cục bộ có thể được kiểm kê sau. Không nên dùng tiêu đề CVE để suy ra mọi dịch vụ MCP đều đã bị xâm nhập.

Nguồn tham khảo

Nếu đội của bạn vận hành MCP qua HTTP trên VPS, hãy chuẩn bị phiên bản package, tệp khóa, sơ đồ nơi tạo server/transport và giới hạn đầu vào hiện tại. Gửi các thông tin này qua trang Thuê Cloud VPS để trao đổi cách cô lập phiên và bố trí kiểm thử tải trước khi cập nhật hệ thống đang phục vụ người dùng.