CVE-2026-18953: Transform MCP Server của AWS không có ranh giới ghi

Amazon đã công bố bản tin bảo mật 2026-075-AWS vào ngày 5 tháng 8 năm 2026 cho CVE-2026-18953, một lỗ hổng duyệt đường dẫn trong công cụ get_resource của awslabs.aws-transform-mcp-server, máy chủ Model Context Protocol mã nguồn mở chạy trên máy của chính nhà phát triển để trợ lý AI có thể điều khiển các tác vụ AWS Transform và truy xuất các sản phẩm đầu ra của chúng. Các phiên bản 0.1.0 đến 0.1.4 không hạn chế đủ tên đường dẫn, và tham số savePath có thể ghi tệp ra ngoài thư mục làm việc dự kiến — mà bản khuyến cáo GitHub trong kho lưu trữ của Amazon nói rằng "có thể dẫn đến thực thi mã cục bộ." Amazon chấm điểm 8,6, mức Cao. Bản sửa lỗi là phiên bản 0.1.5, và không có biện pháp khắc phục tạm thời nào ở phía máy chủ hoặc chỉ bằng cấu hình, vì đường dẫn mã dễ bị tổn thương có mặt trong cấu hình mặc định. Chưa có nguồn công khai nào ghi nhận ai đó đã khai thác lỗ hổng này. Bản ghi đầy đủ, cùng với các mức độ nghiêm trọng và độ tin cậy của nó, nằm trong Orca AI Incident Archive cùng với các sự cố MCP và runtime tác nhân được ghi nhận trong cùng tháng.

Một máy chủ MCP ghi tại nơi lập trình viên làm việc

Các máy chủ Model Context Protocol là lớp cung cấp cho trợ lý những công cụ có thể gọi được, và máy chủ này được cố ý thiết kế để chạy cục bộ. Bản tin của Amazon mô tả nó là "một máy chủ MCP mã nguồn mở chạy cục bộ trên máy của nhà phát triển và cho phép các trợ lý do AI điều khiển tương tác với AWS Transform để chạy các tác vụ chuyển đổi mã và truy xuất các tạo phẩm của chúng." Phần mô tả gói của nó trên Python Package Index cho biết nó phơi bày vòng đời Transform thông qua 19 công cụ, quản lý không gian làm việc chuyển đổi, tác vụ, trình kết nối, tác vụ có con người trong vòng lặp, tạo phẩm và trò chuyện, đồng thời bao quát hiện đại hóa mainframe, di chuyển VMware, hiện đại hóa .NET và các chuyển đổi mã tùy chỉnh.

Vị trí đó chính là điều khiến lỗ hổng này trở nên đáng kể. Một máy chủ trên hạ tầng của chính nhà cung cấp mà xử lý sai tên tệp sẽ làm hỏng kho lưu trữ của nhà cung cấp. Trường hợp này chạy dưới danh nghĩa nhà phát triển, trong thư mục home của nhà phát triển, bên cạnh cấu hình shell và khóa SSH của họ, và tác động mà Amazon mô tả không phải là một bản tải xuống bị hỏng mà là "thực thi mã cục bộ." Mọi điểm số gắn với CVE đều thống nhất ở một điểm: vectơ tấn công là cục bộ, không phải qua mạng.

Công cụ được nêu trong bản tư vấn chính là công cụ đưa một artifact của job xuống đĩa. get_resourcenhận một savePathchỉ định nơi tệp sẽ được lưu. Lỗi nằm ở chỗ không có gì ngăn cản đường dẫn đó trỏ đến một nơi khác.

Tệ đến mức nào, và theo phép tính của ai?

Có ba điểm số được gắn với CVE này và chúng không khớp nhau. Amazon, cơ quan đánh số đã gán CVE, đánh giá nó ở mức 8.6 Cao trên CVSS v3.1 với vectơ CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — cục bộ, độ phức tạp thấp, không yêu cầu đặc quyền, yêu cầu tương tác người dùng, phạm vi thay đổi, tác động cao đến tính bảo mật, tính toàn vẹn và tính sẵn sàng. Mục nhập của NIST trong Cơ sở dữ liệu Lỗ hổng Quốc gia mang điểm số chính v3.1 của riêng mình là 8.8 trên một vectơ khác, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H: yêu cầu đặc quyền thấp, không yêu cầu tương tác người dùng. Cả hai đều nằm trong dải Cao. Sự bất đồng nằm ở các điều kiện tiên quyết — liệu tác nhân đã cần một chỗ đứng từ trước hay chưa, và liệu có phải thuyết phục một người hay không — chứ không phải ở mức độ nghiêm trọng của hậu quả.

Điểm CVSS v4.0 của Amazon cho cùng CVE đó là 6.3, mức Trung bình, trên CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H. Hãy đọc các chỉ số tác động: không có gì trên chính hệ thống dễ bị tổn thương, mọi thứ đều ở mức cao trên hệ thống phía sau. Đó chính là dáng dấp của một kiểu traversal thoát ra khỏi ranh giới của chính công cụ — thiệt hại giáng vào bất cứ thứ gì công cụ có thể chạm tới, nên nó nằm ở cột hệ thống con và hệ thống dễ bị tổn thương nhận điểm bằng không.

Việc CISA làm giàu thông tin cho CVE, đề ngày 6 tháng 8 năm 2026, ghi nhận một quyết định SSVC với Exploitation: none, Automatable: no, Technical Impact: total. Bản ghi của NVD được sửa đổi lần cuối vào ngày 23 tháng 10 năm 2026 và vẫn mang cả điểm 8.6 lẫn 8.8 song song với nhau. Không tài liệu nào coi tài liệu kia là sai.

Mã dễ bị tổn thương đã làm gì và 0.1.5 đã thay đổi những gì

Mô tả của Amazon về cơ chế này chỉ là một câu và rất thận trọng: công cụ này "không hạn chế đầy đủ tên đường dẫn", điều có thể cho phép "một tác nhân phụ thuộc ngữ cảnh" "ghi các tệp tùy ý ra ngoài thư mục làm việc dự định thông qua tham số savePath." Bản khuyến cáo không định nghĩa tác nhân, không nói điều gì kích hoạt việc ghi và không mô tả một vụ khai thác thành công trông như thế nào. Nó chỉ nói rằng kết quả "có thể dẫn đến thực thi mã cục bộ."

Mô tả công khai chi tiết nhất về cơ chế này không phải của Amazon. Đó là một kho lưu trữ proof-of-concept nhỏ, ronamosa/CVE-2026-18953, được công bố trên GitHub vào ngày 8 tháng 8 năm 2026 theo Apache-2.0 — hai commit, không có star và không có fork tại thời điểm viết — trong đó chứa các bản sao nguyên văn của phiên bản dễ bị tổn thương và đã được vá của file_validation.py và chạy cả hai qua cùng các đầu vào.

Cách nó diễn giải 0.1.4 là như sau: validate_write_path() đã phân giải savePath bằng realpath và expanduser, đã từ chối một danh sách từ chối ngắn gồm các vị trí (~/.aws, ~/.ssh, ~/.gnupg, ~/.docker, ~/.aws-transform-mcp, /etc/shadow, /etc/passwd), và loại bỏ các thành phần thư mục khỏi tên tệp được cung cấp. Nó không bao giờ giới hạn đường dẫn đã phân giải vào bất kỳ thư mục cơ sở hay thư mục làm việc nào. Một danh sách chặn các tên tệp nhạy cảm — .bashrc, .zshrc, authorized_keys, id_rsa — đã được áp dụng cho thao tác đọc nhưng không áp dụng cho thao tác ghi.

Kho lưu trữ này minh họa ba thao tác ghi mà nó cho phép: một đường dẫn tuyệt đối không cần duyệt thư mục chút nào, một lối thoát tương đối ../../, và một tên tệp ẩn mà đường dẫn đọc lẽ ra đã từ chối. Cả ba đều rơi vào bên trong một thư mục tạm do script tạo ra, và đầu ra mẫu của nó hiển thị dropped_by_absolute_path.sh, dropped_by_traversal.sh và một .bashrc bên dưới một thư mục home giả; thư mục home thật không bao giờ bị chạm tới. Phiên bản 0.1.5 bổ sung ranh giới còn thiếu: một thư mục cơ sở lấy từ $AWS_TRANSFORM_MCP_WRITE_DIR hoặc thư mục làm việc lúc khởi động của máy chủ, mà mọi thao tác ghi đã được phân giải đều phải nằm bên dưới, cộng với danh sách chặn tên tệp được áp dụng cho đường dẫn ghi đã phân giải cuối cùng. Trình xác thực đã sửa sẽ báo lỗi "Write path must be within the working directory" cho cả ba.

Không có chi tiết nào trong số đó xuất hiện trong bản khuyến cáo, và kho lưu trữ không tuyên bố rằng nó đến từ đó. Hãy coi danh sách từ chối, việc kiểm tra tên tệp chỉ đọc và bản sửa thư mục cơ sở là một bản tái dựng từ mã nguồn, chứ không phải một phát hiện chính thức thứ hai. Điều mà kho lưu trữ bổ sung ngoài bản khuyến cáo là một lời giải thích về việc ai có thể cung cấp đường dẫn: vì nhiệm vụ của máy chủ là kéo nội dung công việc và tác vụ vào ngữ cảnh của trợ lý, nên bên chọn savePath không nhất thiết phải là người đang ngồi ở bàn phím. Một trợ lý bị dẫn dắt bởi nội dung không đáng tin cậy mà nó đã lấy được qua chính công cụ đó có thể đưa ra quyết định đó. Đó là lập luận của kho lưu trữ dựa trên mã và thiết kế của công cụ, chứ không phải là tuyên bố của Amazon; "tác nhân phụ thuộc ngữ cảnh" không được định nghĩa của Amazon nhất quán với điều đó và dừng lại ở đó.

Bảy tuần giữa bản vá và bản tin

Bản sửa lỗi không đến cùng với thông báo. Lịch sử phát hành của Python Package Index — siêu dữ liệu chính thức từ kho đăng ký mà gói này được phát hành qua — ghi 0.1.4 vào ngày 20 tháng 5 năm 2026 và 0.1.5 vào ngày 17 tháng 6 năm 2026, bảy tuần trước khi bản tin 2026-075 được công bố vào ngày 5 tháng 8. Không có tệp 0.1.0 nào trên chỉ mục cả; artifact được công bố sớm nhất trong phạm vi bị ảnh hưởng là 0.1.1, được tải lên ngày 9 tháng 5 năm 2026. Do đó, một nhà phát triển cài đặt từ chỉ mục chỉ có thể đã nhận được bản dựng dễ bị tổn thương trong khoảng từ ngày 9 tháng 5 đến ngày 17 tháng 6, và bất kỳ ai theo dõi các bản phát hành đều đã dùng mã đã được vá vào giữa tháng 6.

Amazon không nói khi nào họ biết về vấn đề này, khi nào báo cáo đến, hay tại sao bản phát hành đóng vấn đề đó lại được tung ra. Người duy nhất được nêu tên trong hồ sơ là Drew Raines, được cả bản tin và tư vấn GitHub cảm ơn "vì đã hợp tác về vấn đề này thông qua quy trình công bố vấn đề có phối hợp." GHSA-66mr-jr63-2jgw được công bố trong kho lưu trữ awslabs/mcp của Amazon vào ngày 5 tháng 8 năm 2026, cùng ngày với bản tin; hồ sơ CVE được đặt trước lúc 13:44 UTC và được công bố lúc 19:33 UTC cùng ngày.

Vậy là ngày sửa lỗi đã được xác lập, còn lý do thì chưa. Một phiên bản đã vá nằm trên registry bảy tuần trước khuyến cáo bảo mật thì khớp với một lần sửa lặng lẽ rồi sau đó là công bố phối hợp — nhưng đó chỉ là suy luận từ hai mốc thời gian, và không tài liệu nào nói rõ điều đó.

Những gì hồ sơ chứng minh, và những gì hồ sơ không chứng minh

Kho lưu trữ xếp mục này hạng A — được ghi chép đầy đủ, các nguồn sơ cấp đồng thuận — và không đánh dấu là đang tranh chấp. Nó lưu mục này như một hồ sơ nghiên cứu, một phát hiện lỗ hổng chứ không phải sự cố triển khai, không ghi nhận tác hại thực tế nào. Xếp hạng này nói về chất lượng tài liệu, và dựa trên bằng chứng đã xem xét, nó vẫn đúng: bản tin, khuyến cáo GitHub và bản ghi CVE là ba tài liệu do Amazon xuất bản, thống nhất về sản phẩm, các phiên bản, bản vá và phần ghi nhận đóng góp.

• Đã xác nhận. Amazon đã công bố bản tin 2026-075-AWS vào ngày 5 tháng 8 năm 2026 về CVE-2026-18953, một lỗ hổng duyệt đường dẫn CWE-22 trong cách xử lý get_resource đối với savePath trong awslabs.aws-transform-mcp-server 0.1.0 đến 0.1.4, được khắc phục trong 0.1.5, không có cách khắc phục phía máy chủ hoặc chỉ bằng cấu hình vì đường dẫn dễ bị tổn thương nằm trong cấu hình mặc định.

• Đã xác lập. Các điểm số và mức độ phân kỳ của chúng: 8.6 High từ Amazon với tư cách là cơ quan cấp số CVE, 8.8 High từ NIST với tư cách là điểm chính của NVD, 6.3 Medium trên CVSS v4.0, và quyết định SSVC ngày 6 tháng 8 của CISA rằng chưa quan sát thấy khai thác nào và không có đường tự động hóa nào.

• Đã xác lập. Các ngày phát hành trên Python Package Index và ghi nhận công lao của Drew Raines cho việc phối hợp công bố thông tin.

• Được suy ra từ mã nguồn, bởi một bên thứ ba.Danh sách từ chối, danh sách chặn tên tệp chỉ đọc, thư mục gốc bị thiếu và _ALLOWED_WRITE_BASE bản sửa đều đến từ kho lưu trữ proof-of-concept ronamosa, nơi bất kỳ ai cũng có thể so sánh khác biệt giữa các bản sao được nhúng của hai phiên bản trình xác thực.

• Suy ra từ dấu thời gian và thiết kế. Rằng 0.1.5 là một bản phát hành bảo mật có chủ đích, và rằng một trợ lý bị dẫn dắt bởi nội dung không đáng tin cậy có thể cung cấp đường dẫn độc hại. Amazon không nêu cả hai điều này.

• Chưa được xác định.Mọi hành vi khai thác trên thực tế. Mục "Exploitation: none" của CISA được ghi ngày 6 tháng 8, tức hai ngày trước khi bản proof-of-concept công khai xuất hiện, nên nó chỉ phản ánh thời điểm đó chứ không nói gì về những gì sau đó. Chưa có số lượng người dùng bị ảnh hưởng, thông báo cho khách hàng hay dữ liệu đo từ xa nào được công bố.

• Chưa được xác lập.Đưa tin độc lập. Không có cơ quan truyền thông chính thống nào có vẻ đã đưa tin về CVE này. Hồ sơ công khai gồm ba tài liệu của Amazon, các nội dung bổ sung của NIST và CISA cho những tài liệu đó, các trang theo dõi nhắc lại hồ sơ, và một kho lưu trữ proof-of-concept nhỏ được mô tả ở trên.

Những gì đã thay đổi và những gì cần kiểm tra

Cách khắc phục của Amazon là tăng số phiên bản và không gì khác: nâng cấp lên 0.1.5 trở lên, và “đảm bảo mọi mã đã fork hoặc mã phái sinh đều được vá để tích hợp các bản sửa lỗi mới.” Mệnh đề thứ hai mới là mệnh đề có sức lan tỏa. Máy chủ là mã nguồn mở, và một bản fork đã nhúng bộ xác thực 0.1.4 sẽ thừa hưởng lỗ hổng mà không thừa hưởng khuyến cáo; bản tin yêu cầu những người vận hành mã phái sinh mang thay đổi vào đó, nghĩa là bản phát hành thượng nguồn không đến được bản sao do người khác duy trì.

Kho lưu trữ bằng chứng khái niệm gợi ý một điều mà bản khuyến cáo từ chối đưa ra. Theo đó, những người vận hành không thể nâng cấp ngay lập tức nên chạy máy chủ với thư mục làm việc của nó được đặt thành một thư mục trống chuyên dụng và coi bất kỳ tệp nào mà nó có thể ghi vào là đã bị xâm phạm. Lập trường của Amazon thì nghiêm ngặt hơn: hoàn toàn không có giải pháp thay thế nào ở phía máy chủ hay chỉ dựa vào cấu hình. Xét theo chính lời giải thích của kho lưu trữ, gợi ý đó cũng mong manh, vì mã dễ bị tổn thương vốn dĩ chưa bao giờ giới hạn việc ghi trong thư mục làm việc. Ở chỗ hai bên bất đồng, chỉ thị chỉ nâng cấp của nhà cung cấp vẫn có hiệu lực.

Điều hữu ích ở bản ghi này không phải là điểm số của nó. Mà là hình dạng của nó: một máy chủ MCP cục bộ, một lần tải xuống artifact với đích đến do người gọi cung cấp, và không có ranh giới nào giữa hai thứ đó. Phép kiểm tra quan trọng không phải là ngày bản tin mà là phiên bản được ghim — 0.1.5 trở lên, và cùng thay đổi đó được mang vào bất kỳ fork nào đã sao chép validator.