Wasmtime 취약점 패치 버전 — 36.0.19·48.0.7·49.0.4, 9.9점 샌드박스 탈출 두 건은 컴파일러에서 나왔다

이번 구멍은 상자의 벽이 아니라 상자를 짓는 기계에서 났다. 웹어셈블리(Wasm) 실행기 Wasmtime을 관리하는 바이트코드 얼라이언스가 2026년 10월 19일 CVSS 9.9점짜리 취약점 두 건을 공개했다. 두 건 모두 Wasm 코드를 기계어로 바꾸는 크레인리프트(Cranelift) 컴파일러에서 나왔다. 공격자가 조작한 Wasm 모듈을 올리면 컴파일러가 코드를 잘못 만들어, 모듈이 샌드박스 밖 메모리에 손을 대거나 원하는 코드로 점프할 수 있다.

결론부터: 36.0.19, 48.0.7, 49.0.4 중 자기 계열에 맞는 버전으로 올리면 이번 두 건을 포함해 10월에 나온 Wasmtime 권고 29건이 모두 해결된다. 실제 공격 보고는 아직 없다.

1. 내 버전은 영향을 받나

x86 서버에서 43 이상을 쓰면 이번 9.9점 두 건 중 ARM64 건은 해당하지 않는다. 하지만 같은 날 함께 나온 중간·낮음 등급 권고 4건과 10월 14일·10월 2일 권고가 있어서 최신 패치로 올리는 것이 가장 단순하다. 아마존 그래비톤이나 애플 실리콘 같은 ARM64 위에서 돌린다면 CVE-2026-115893이 직접 해당한다.

2. 두 취약점은 어떻게 작동하나

Wasm의 안전은 두 겹이다. 언어 규칙상 모듈은 자기 메모리 칸 밖을 볼 수 없고, 실행기는 그 규칙을 지키는 기계어를 만들어 낸다. 이번 두 건은 두 번째 겹, 즉 규칙을 기계어로 옮기는 단계의 실수다. 원본 코드는 규칙을 지켰는데 번역이 틀려서 벽에 구멍이 생긴다. 타입 혼동이 어떻게 메모리 접근으로 이어지는지는 「타입 혼동 취약점이란」에서 다뤘다.

점수가 10점이 아니라 9.9점인 것은 공격자가 '모듈을 올릴 수 있는 권한'을 가져야 하기 때문이다(권한 요구 낮음). CVSS 점수가 이렇게 갈리는 원리는 「CVSS란」에서 설명했다.

3. 누가 서둘러야 하나

Wasmtime은 '남의 코드를 안전하게 가둬 돌리는 상자'로 쓰인다. 그래서 위험은 누가 모듈을 넣을 수 있느냐로 갈린다. 패치가 당장 어렵다면 해커와이어 정리 기준으로 신뢰할 수 없는 Wasm을 컴파일하는 서비스를 따로 격리하고, CPU·메모리 제한을 걸어 두는 것이 임시 대책이다. 다만 근본 해결은 업데이트다.

4. 10월에만 권고 29건 — 세 번의 묶음

한 달에 세 번 묶음 패치가 나왔다. 10월 14일 묶음의 파일시스템 탈출 건은 별개 문제다. 웹어셈블리 시스템 인터페이스(WASI)가 허락한 폴더 밖 파일에 손댈 수 있는 취약점이었다. 같은 달 노드JS(「Node2Shell」)와 PHP(「PHP2Shell 취약점 패치 버전」)에서도 원격 코드 실행 취약점이 나왔다. 실행 환경 전반의 패치 주기가 빨라지고 있다.

5. 남은 것과 확인되지 않은 것

• 실제 공격: 보고된 것은 없다. 10월 26일 기준 CISA KEV 목록에 없다.
• 24.x 계열: 이번 권고 패치 목록에 없다. 24.x를 쓰고 있다면 지원 상태부터 확인해야 한다.
• 취약점 번호 혼선: 10월 14일 파일시스템 탈출 건에 대해 일부 취약점 데이터베이스가 다른 CVE 번호와 패치 버전을 적었다. 깃허브 권고 원문을 기준으로 삼는 것이 안전하다.
• 웹어셈블리 자체: 왜 Wasm이 서버와 AI 플러그인의 '가두는 상자'로 쓰이는지는 같은 날 「웹어셈블리(Wasm)란」에서 정리했다.