Lỗ hổng thoát sandbox nghiêm trọng trong Wasmtime đã được khắc phục qua các bản phát hành mới nhất

Các nhà bảo trì của runtime WebAssembly Wasmtime đã phát hành các bản vá bảo mật khẩn cấp vào ngày 19 và 20 tháng 10 năm 2026 để xử lý hai lỗ hổng nghiêm trọng. Những lỗi này, được đánh giá 9.9/10 trên thang điểm CVSS, có thể cho phép một module độc hại phá vỡ sandbox và thực thi mã tùy ý trên hệ thống máy chủ.

Chuyện gì đã xảy ra

Bytecode Alliance, tổ chức bảo trì Wasmtime, đã xác định hai lỗi riêng biệt trong Cranelift, trình biên dịch mặc định dùng để chuyển đổi WebAssembly thành mã máy. Lỗ hổng đầu tiên, được theo dõi dưới mã CVE-2026-115889, ảnh hưởng đến các cài đặt Wasmtime trên mọi kiến trúc bộ vi xử lý. Lỗi thứ hai, CVE-2026-115893, chỉ cụ thể đối với các hệ thống ARM64 (aarch64). Cả hai vấn đề đều cho phép thoát sandbox nếu kẻ tấn công có thể cung cấp một module WebAssembly được thiết kế đặc biệt cho runtime dễ bị tổn thương.

Rủi ro là cấp bách nhất đối với các nền tảng biên dịch và chạy mã do người dùng cung cấp, chẳng hạn như môi trường tính toán serverless. Ví dụ, các dịch vụ như nền tảng Compute của Fastly dựa vào Wasmtime để cô lập mã của khách hàng. Mặc dù các thông báo không nêu tên nạn nhân cụ thể hay chi tiết về quyền truy cập sau khi khai thác, nhưng tiềm năng xâm phạm toàn bộ máy chủ là rất nghiêm trọng. Tính đến ngày 26 tháng 10, chưa có báo cáo về các cuộc khai thác đang hoạt động, và cả hai lỗi đều không xuất hiện trong danh mục Các lỗ hổng bị khai thác đã biết (Known Exploited Vulnerabilities) của CISA.

Tình trạng hỗ trợ đóng vai trò quan trọng trong mức độ phơi nhiễm. Chỉ các dòng phát hành 36, 48, 49 và 50 hiện đang nhận được các bản cập nhật bảo mật. Các dòng cũ hơn, bao gồm nhánh LTS 24.x đã kết thúc hỗ trợ vào ngày 20 tháng 8 năm 2026, sẽ không nhận được bản sửa lỗi. Người dùng trên các phiên bản không được hỗ trợ phải nâng cấp lên một dòng được hỗ trợ để giảm thiểu những rủi ro này.

Cách thức hoạt động

CVE-2026-115889 bắt nguồn từ một lỗi tràn số nguyên trong cách Cranelift theo dõi các giá trị bên trong một hàm. Trong các phiên bản trước 43.0.0, trình biên dịch lưu trữ các số theo dõi này trong các trường 24-bit. Nếu một hàm đủ lớn hoặc phức tạp để vượt quá giới hạn này, giá trị sẽ âm thầm bị tràn trong các bản build release. Điều này khiến Cranelift tham chiếu đến các giá trị sai, dẫn đến nhầm lẫn kiểu (type confusion) và tạo ra mã máy vi phạm các ràng buộc của sandbox. Bản sửa lỗi mở rộng các trường này lên 32 bit, một thay đổi ban đầu được hợp nhất vào tháng Hai vì lý do hiệu suất nhưng đã được backport sang dòng LTS 36.x vào ngày 19 tháng 10 cho mục đích bảo mật.

Lỗi cụ thể cho ARM64, CVE-2026-115893, liên quan đến lệnh br_table, dùng để xử lý các rẽ nhánh đa hướng. Khi một chỉ số nằm ngoài phạm vi bảng, runtime sẽ nhảy đến một đích mặc định. Trên ARM64, Cranelift triển khai điều này bằng cách sử dụng một lệnh rẽ nhánh với tầm nhảy hạn chế khoảng 1 MiB. Nếu một br_table chứa nhiều hơn khoảng 256.000 đích, bảng nhảy sẽ vượt quá phạm vi này, khiến việc rẽ nhánh trỏ đến một vị trí bộ nhớ không mong muốn. Điều này cho phép một module được thiết kế đặc biệt chuyển hướng việc thực thi sang mã tùy ý. Bản vá sửa đổi luồng điều khiển để định tuyến các chỉ số ngoài phạm vi thông qua chính bảng nhảy và giới hạn kích thước br_table ở mức 65.520 đích.

Chi tiết chính

• CVE-2026-115889 ảnh hưởng đến tất cả các kiến trúc; CVE-2026-115893 chỉ ảnh hưởng đến các hệ thống ARM64.
• Cả hai lỗ hổng đều có điểm CVSS là 9.9, cho thấy mức độ nghiêm trọng cao.
• Các phiên bản đã được sửa lỗi bao gồm 36.0.19, 48.0.7, 49.0.4 và 50.0.0.
• Dòng LTS 24.x không còn được hỗ trợ và không nhận được bản vá; người dùng phải di chuyển sang phiên bản khác.
• Dependabot có thể không cảnh báo về lỗi ARM64 vì GitHub thiếu một mục đã được xem xét cho nó.
• Phiên bản framework Spin 4.2.4 đã cập nhật lên Wasmtime 50.0.0 vào ngày 21 tháng 10.

Tại sao điều này quan trọng

Đối với các kỹ sư xây dựng nền tảng thực thi WebAssembly không đáng tin cậy, những lỗi này đại diện cho sự thất bại cơ bản của cơ chế cô lập. Sandbox là cơ chế phòng thủ chính trong các kiến trúc như vậy. Nếu một module có thể thoát ra, nó sẽ giành được đặc quyền của tiến trình máy chủ, tiềm năng cho phép rò rỉ dữ liệu, di chuyển ngang (lateral movement) hoặc gián đoạn dịch vụ. Việc một lỗi tồn tại từ năm 2020 nhấn mạnh khó khăn trong việc kiểm tra logic trình biên dịch cấp thấp, đặc biệt là đối với các trường hợp ngoại lệ cụ thể theo kiến trúc.

Ngoài ra, việc phụ thuộc vào các công cụ tự động như Dependabot có thể mang lại cảm giác an toàn giả tạo. Vì GitHub yêu cầu các mục đã được xem xét để kích hoạt cảnh báo, và lỗi ARM64 thiếu một mục như vậy vào cuối tháng 10, một số nhóm có thể vẫn không nhận thức được mức độ phơi nhiễm của mình. Điều này nhấn mạnh nhu cầu xác minh thủ công cây phụ thuộc so với các thông báo chính thức từ nhà cung cấp, đặc biệt là đối với các thành phần hạ tầng quan trọng như runtime.

Bạn có thể làm gì

• Xác định phiên bản Wasmtime hiện tại của bạn và kiểm tra xem nó có nằm trong các phạm vi bị ảnh hưởng được liệt kê trong thông báo hay không.
• Nâng cấp lên 36.0.19, 48.0.7, 49.0.4 hoặc 50.0.0 tùy thuộc vào dòng phát hành của bạn.
• Nếu bạn sử dụng Wasmtime như một thư viện, hãy xây dựng lại ứng dụng của bạn với phiên bản đã được vá; việc cập nhật công cụ CLI là không đủ.
• Di chuyển khỏi các dòng phát hành không được hỗ trợ như 24.x, vì chúng sẽ không nhận được các bản sửa lỗi bảo mật trong tương lai.
• Chạy cargo-audit để kiểm tra RUSTSEC-2026-0380 và RUSTSEC-2026-0379 trong các tệp khóa phụ thuộc của bạn.
• Theo dõi các bản cập nhật từ các framework downstream như Spin nếu bạn không trực tiếp quản lý Wasmtime.