Zapscape란 무엇이며 KVM 호스트를 보호하는 방법

요약

전체 버전으로 이동 ↓

개요: 발견자인 김현우(@v4bel)가 ‘Zapscape’라고 명명한 CVE-2026-64561은 리눅스 KVM x86 섀도 메모리 관리 유닛(SMU)에서 발생하는 ‘use-after-free’ 취약점입니다. 두 가지 페이지 오류 경로는 섀도 페이지를 회수하기 ‘전’에 섀도 루트를 검증하는 대신 ‘후’에 검증하므로, KVM은 루트 회수 과정에서 이미 무효화된 영역 아래에 매핑을 계속 생성하게 됩니다. 그 결과 게스트에서 호스트로의 완전한 탈출이 발생합니다. 공개된 PoC는 단순히 모든 공동 테넌트 VM을 중단시키는 패닉(panic)을 유발하는 데 그치지 않고, 호스트에서 루트 권한으로 코드를 실행하는 경로를 보여줍니다. 이 섹션으로 이동 →

예상되는 영향: 이 연구원은 공격자가 제어하는 게스트 환경에서 호스트 커널 코드 실행으로 이어지는 경로를 보고했는데, 이는 가상 머신에서 호스트로 완전히 탈출하는 것을 의미합니다. 같은 보고서에서는 두 가지 추가적인 결과도 설명하고 있는데, 하나는 영향을 받은 머신에서 실행 중인 모든 워크로드를 중단시키는 호스트 패닉이고, 다른 하나는 호스트의 일반 계정에서 시작되는 별도의 로컬 권한 상승 경로로, 여기서 /dev/kvm 전 세계 사용자가 쓰기 권한을 가집니다. 이 섹션으로 이동 →

중요도: 레드햇은 이 취약점을 CWE-825 항목 하에서 CVSS 3.1 기본 점수 7.0을 부여하며 ‘중요(Important)’ 등급으로 분류합니다. 이 취약점을 악용하려면 게스트 커널 권한, 중첩 가상화, 그리고 호환되는 호스트 구성이 필요합니다. 레드햇은 이 취약점의 영향을 가상화 환경에서의 불안정성 및 서비스 거부(DoS)로 규정하고 있는데, 이는 연구자의 평가보다 상당히 완화된 표현입니다. 이 섹션으로 이동 →

누가 위험에 노출되는가: 커밋을 통해 도입된 변경 사항이 포함된 커널에서 중첩 가상화가 활성화된 상태로 KVM을 실행 중인 호스트 f95eec9bed76 리눅스 5.9에서 발생하며, 아직 업스트림 수정 사항이 반영되지 않았습니다 2abd5287f083. 중첩된 페이지 테이블을 사용하는 AMD SVM 시스템이 가장 직접적으로 접근할 수 있습니다. 인텔 시스템의 경우, 1단계 게스트에 노출되려면 4단계 및 5단계 EPT 페이지 탐색이 모두 필요하기 때문에, 이 경로는 Ice Lake-SP 및 그 이후 버전으로 제한됩니다. 이 섹션으로 이동 →

확인된 사항: 공개된 개념 증명(PoC)은 당사의 테스트 결과, CloudLinux 기반 커널에서 게스트-호스트 탈출을 유발하지 않았습니다. 수정 없이 해당 커널에서 실행되지 않으며, 내부 재현 테스트에서는 지금까지 1단계 게스트의 충돌만 발생했습니다. 이 탈출 시도는 신뢰할 만한 것으로 간주하되, 전체 시스템에 걸친 침해 사례로 간주해서는 안 됩니다. 이 섹션으로 이동 →

지금 해야 할 일: 우선 해당 호스트가 조사 대상에 포함되는지 여부를 확인하십시오.

cat /sys/module/kvm_amd/parameters/nested 2>/dev/null
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null

A 1 또는 Y 이는 로드된 KVM 모듈이 중첩 가상화를 허용함을 의미하며, 이로 인해 호스트가 잠재적인 공격 표면에 포함되게 됩니다. 다만 커널 패치 상태, 호스트 CPU 기능, L1에 노출된 가상 CPU 모델, 그리고 신뢰할 수 없는 게스트가 L2를 생성할 수 있는지 여부 등이 여전히 중요한 요소이므로, 이것만으로는 악용 가능성을 입증할 수는 없습니다.

출력이 없는 것은 대개 해당 KVM 모듈이 현재 로드되어 있지 않음을 의미하며, 이는 ‘범위 외’와 같은 의미가 아니므로, 호스트가 실제로 어떻게 사용되고 있는지, 그리고 나중에 KVM을 로드할 수 있는지 확인해 보십시오. 아무도 중첩 기능을 켜지 않았다고 가정하기보다는 파일을 직접 읽어보십시오. 리눅스 4.20 버전부터 업스트림 KVM은 인텔과 AMD 모두에 대해 ‘nested’ 매개변수를 기본적으로 활성화해 놓았으며, 배포판 측에서 이 기본값을 원하는 방향으로 재설정할 수 있기 때문입니다.

중첩 가상화가 필요 없는 호스트에서는 이 기능을 비활성화하십시오. 이렇게 하면 전체 체인이 의존하는 필수 조건이 제거되기 때문입니다. 확인 /dev/kvm 그 작업을 진행하는 동안 권한 설정을 별도의 보안 강화 조치로 처리하십시오.

KernelCare는 재부팅이나 VM 재시작 없이 실행 중인 커널의 이 취약점을 해결합니다. 최초의 재부팅 불필요 패치가 이제 배포되었습니다. Debian 13은 메인 피드에 포함되어 있으며, Ubuntu 24.04, AWS용 Ubuntu 24.04, AWS용 Ubuntu 22.04 6.8 커널, Proxmox VE 8의 빌드는 테스트 피드에 포함되어 있으며 메인 피드로 승격될 예정입니다. 나머지 커널 계열은 아직 빌드 및 검토 중이며, 검증이 완료되는 대로 각 커널 및 피드별로 제공될 예정입니다. 해당 플랫폼용 수정된 벤더 커널이 이미 존재하는 경우 이를 적용하십시오.

Zapscape에 대한 두 가지 설명이 나돌고 있는데, 두 설명은 서로 매우 큰 차이를 보입니다. 한 연구원은 게스트 내부에서 호스트 커널 코드 실행으로 이어지는 일련의 과정을 설명하고 있습니다. 반면 레드햇은 가상화 환경에서의 불안정성을 언급하고 있습니다. 두 설명 모두 동일한 커밋에 대해 다루고 있습니다.

정직한 답은 그 둘의 중간에 있으며, 아래의 설명에서 그 이유를 알 수 있습니다. 내부에서 재현된 결과는 공개된 내용보다 범위가 더 좁습니다. 공개된 개념 증명(PoC)은 일부 환경에서 공격자가 제어하는 L1 게스트를 다운시킬 수 있는 반면, 연구원은 호스트 코드 실행으로 이어지는 구성에 따라 달라지는 경로를 문서화했습니다. 이러한 차이를 명확히 밝힐 필요가 있으며, 어느 쪽의 해석도 결함이 있는 가상화 경계를 패치하지 않은 채 방치해야 한다는 근거가 될 수는 없습니다.

중첩 가상화를 통해 가상 머신이 자체적으로 다른 가상 머신을 실행할 수 있습니다. 클라우드 고객은 이를 활용하여 하이퍼바이저를 실행하거나, 인프라 소프트웨어를 테스트하거나, CI 환경을 운영하거나, Hyper-V에 의존하는 Windows 기능을 사용할 수 있습니다.

이를 통해 3단계 구조가 형성됩니다:

• L0는 물리적 호스트입니다.
• L1은 공격자가 제어하는 게스트입니다.
• L2는 L1 내부에 생성된 가상 머신입니다.

Zapscape는 L0가 L2의 활동을 처리하는 과정에서 수행하는 메모리 관리 기능을 악용합니다. 공격자는 L1 내에서 루트 권한을 확보한 상태에서 시작하여, 취약한 KVM 경로를 제어하는 데 필요한 중첩 게스트를 생성합니다.

클라우드 가상 머신 내에서 루트 권한을 획득하는 것은 드문 일이 아닙니다. 고객은 일반적으로 자신의 게스트 운영 체제를 직접 관리하며, 이 경계는 해당 접근 권한이 하이퍼바이저까지 도달하는 것을 차단하도록 설계되어 있습니다. Zapscape는 바로 이 경계 자체를 표적으로 삼습니다.

KVM은 섀도 페이지 테이블을 사용하여 게스트 메모리 액세스를 호스트 매핑으로 변환하며, 활성 MMU 페이지 할당량에 도달하면 해당 구조체를 회수합니다.

취약한 결함 경로, direct_page_fault() 그리고 FNAME(page_fault)(), 일명 is_page_fault_stale() ~전에 make_mmu_pages_available().

그 순서가 바로 버그입니다.

내부 매립 make_mmu_pages_available() KVM이 현재 사용하고 있는 루트를 제거하고 이를 무효로 표시할 수 있습니다. stale-root 검사가 이미 실행되었기 때문에, KVM은 더 이상 유효하지 않은 루트 아래에서 매핑을 계속 구축합니다. 자식 섀도 페이지는 부모의 역할을 상속받으므로 무효 상태도 함께 상속받게 되며, 무효화된 페이지는 결국 활성 MMU 페이지 목록으로 다시 돌아오게 됩니다.

그것이 불변 커밋입니다 f95eec9bed76 이를 방지하기 위해 리눅스 5.9에 추가되었습니다. 일단 문제가 발생하면, 이후 재귀적 정리 과정을 통해 mmu_page_zap_pte() 아무런 문제 없이 실행됩니다 root_count 가드 기능을 수행하며, 이미 해제된 구조물에 대해 작동합니다.

이 개념 증명(PoC)은 L1 내부의 메모리 모드를 전환하여 섀도 페이지를 에일리어싱하는 방식으로 시퀀스를 진행하며, L2의 메모리 활동은 L0를 할당량 기반 회수 과정으로 유도합니다. 이후 연구원은 이로 인해 발생한 손상을 이용해 호스트 커널 코드를 실행합니다.

이 순서 문제 자체는 2008년으로 거슬러 올라갑니다. 이 문제가 보안과 관련이 있게 된 것은 리눅스 5.9에서, 해당 문제가 위반하는 불변 조건이 도입되었을 때였습니다. 5.9 버전에서 누군가가 버그를 작성한 것은 아닙니다. 커널이 단순히 이전에는 결코 성립하지 않았던 조건에 의존하기 시작한 것뿐입니다.

이 연구원은 게스트 측 개념 증명(PoC)을 제시하고, 호스트 코드 실행에 이르는 전체 경로를 문서화했다. 다만, 이 취약점을 실제로 악용할 수 있는지는 시스템 구성에 크게 좌우된다. 이 취약점은 AMD를 대상으로 하며, 실제 운영 환경의 하드웨어가 아닌 QEMU TCG 환경 하의 특정 Linux 7.1.3 구성에서 개발되었기 때문에, 실제 호스트에 도달하려면 게스트 측 동작을 재작성하고 대상 커널 구성에 맞게 조정해야 한다.

당사의 테스트 결과, CloudLinux 기반으로 빌드된 커널에서는 완전한 권한 탈출 현상이 재현되지 않았습니다. 공개된 익스플로잇은 수정 없이 해당 커널에서 실행되지 않으며, 관찰된 결과는 L1 게스트의 충돌로, 이는 호스트 침해라기보다는 공격자 자신의 가상 머신에 대한 서비스 거부(DoS)에 해당합니다.

Enterprise Linux 8을 직접 테스트해 보려는 분들께는 주의가 필요합니다. 공개된 개념 증명(PoC)은 해당 환경에서 아무런 반응도 보이지 않으며, 심지어 시스템이 다운되지도 않으므로, 이 제품군에 대한 ‘전후 비교’의 기준이 될 수 없습니다. 아무런 반응이 없다고 단정 짓기보다는, 일반적인 KVM 테스트 스위트를 사용하여 EL8 커널을 검증하시기 바랍니다.

이 모든 것이 해당 커널들이 안전하다는 것을 증명하는 것은 아닙니다. 이는 해당 취약점을 정확하게 기술해야 함을 의미합니다. Zapscape는 신뢰할 수 있는 게스트-투-호스트 탈출 경로를 제시하고 있으며, 현재 공개된 익스플로잇은 취약한 코드를 포함하고 있는 모든 커널에 대해 보편적으로 적용되는 탈출 경로는 아닙니다.

이 취약점이 있는 코드 경로는 리눅스 5.9의 다음 커밋 변경 사항부터 존재합니다. f95eec9bed76, 2020년 7월 8일자, 수정 패치를 적용받지 않은 커널을 통해 2abd5287f083, 이는 2026년 7월 21일 상류에 착륙했다.

또한 접근성에는 다음이 필요합니다:

• KVM 사용 예정
• 중첩 가상화 활성화 예정
• L1 게스트 내부의 커널 수준 제어
• 해당 공격과 호환되는 호스트 CPU 및 가상 CPU 기능

SVM 및 중첩 페이지 테이블을 사용하는 AMD 호스트의 경우, 본 공개 내용에는 이미 나열된 주요 요구 사항 외에 추가적인 CPU 기능 전제 조건이 명시되어 있지 않습니다. 인텔 시스템의 경우, 4단계 및 5단계 EPT 페이지 탐색 길이가 모두 L1에 노출되는 환경에서만 접근이 가능하며, 이는 일반적으로 해당 기능이 전달되는 Ice Lake-SP 및 그 이후 버전을 의미합니다.

분석 과정에서 확인된 영향을 받았거나 잠재적으로 영향을 받을 수 있는 플랫폼 계열:

• Enterprise Linux 10, AlmaLinux 10 및 CloudLinux 10(이들 버전에서는 CentOS Stream 10 백포트가 아직 초안 단계에 있음)
• 벤더 수정 사항이 포함되지 않은 구형 Enterprise Linux 8 및 9 커널(EL8 파생 버전 포함)
• 데비안 11, 12, 13
• Ubuntu 22.04 및 24.04
• Oracle UEK7
• Proxmox VE 7 및 VE 8

이미 수정되었거나 검토 대상에서 제외된 사항:

• 다음 출처의 RHEL 8 커널 4.18.0-553.147.1.el8_10 onward, 2026년 7월 23일 발송
• 다음 출처의 RHEL 9 커널 5.14.0-687.30.1.el9_8 onward, 2026년 7월 22일 발송
• 이 결함이 보안상의 문제로 간주되게 된 리눅스 5.9 변경 사항 이전에 출시된 RHEL 6 및 RHEL 7(kernel-rt 포함)
• KVM을 실행하지 않거나, 중첩 가상화 기능이 비활성화된 상태로 KVM을 실행 중인 호스트

RHEL 관련 항목에는 주의할 점이 있습니다. 레드햇은 이 수정 사항을 다른 취약점 대응 작업과 묶어 조용히 배포했으며, 해당 에라타가 공개된 후에도 레드햇의 공개 CVE 페이지에는 RHEL 8과 RHEL 9가 여전히 영향을 받는 버전으로 기재되어 있었습니다. 변경 내역이 더 확실한 지표이며, 페이지 내용이 몇 시간 만에 변경되는 경우가 있으므로, 고객이나 감사관에게 영향을 받는 상태를 언급하기 전에 레드햇의 최신 데이터를 다시 확인하시기 바랍니다.

이와 같은 주의 사항은 보다 광범위하게 적용됩니다. 벤더 커널은 개별 변경 사항을 지속적으로 백포트하므로, 업스트림 버전 번호만으로는 취약점 노출 여부를 판단할 수 없습니다. 현재 실행 중인 커널에 대한 보안 권고 사항과 패치 적용 상태를 확인하십시오.

Zapscape의 영향을 완화하는 방법

이 버그의 모든 근본 원인은 제거할 수 있는 요소들입니다. 이 세 가지 모두 일시적인 대응책일 뿐, 근본적인 해결책의 대안이 아닙니다.

1. 중첩 가상화를 비활성화하십시오. 이 체인에서는 L1이 자체 가상 머신을 생성하고 운영해야 하므로, 이것이 가장 직접적인 방법입니다.

# /etc/modprobe.d/99-zapscape.conf
options kvm_amd nested=0
options kvm_intel nested=0

모듈 매개변수는 로드 시점에 읽히므로, 이를 적용하려면 실행 중인 모든 가상 머신을 중지하고 다시 로드해야 합니다. kvm_amd 또는 kvm_intel. 프로덕션 호스트에서는 이는 라이브 변경이라기보다는 시스템 부하 증가나 재부팅에 해당합니다.

플릿에서 일반적인 단일 레벨 가상 머신을 실행하는 경우, 패치를 적용하고 다음 단계로 넘어가면 됩니다. 해당 워크로드에는 중첩 가상화가 필요한 부분이 없기 때문입니다. 호스트가 의도적으로 중첩 가상화를 제공하는 경우(예: 중첩 하이퍼바이저 테넌트, 가상 머신을 부팅하는 CI 시스템, 가상화된 개발 및 테스트 환경, VBS 또는 Hyper-V를 사용하는 Windows 게스트 등)에는 이 기능을 활성화된 상태로 두고, 대신 패치 적용을 우선시하십시오. 직접 구축하지 않은 호스트를 수정하기 전에 워크로드에 미치는 영향을 먼저 평가하십시오.

2. 다음에 대한 접근을 제한합니다. /dev/kvm. 이는 기존 게스트의 공격에 대해서는 아무런 효과가 없습니다. 이는 호스트의 일반 로컬 사용자가 KVM에 직접 접근할 수 있는 별도의 경로를 차단합니다.

ls -l /dev/kvm

기기에 모드가 표시되면 0666, 이를 조이고 다음을 통해 정당한 사용자에게 접근 권한을 부여하십시오. kvm 그룹. 이 변경 사항은 단순한 방식이 아니라 udev 규칙에서 수행하십시오. chmod, udev는 다음 부팅이나 장치 이벤트 발생 시 모드를 초기화하기 때문입니다.

3. 인텔의 5단계 EPT 노출을 검토하십시오. 두 EPT 기능 모두 L1 단계에 도달하는 경우에만 해당됩니다.

grep -w ept_5level /proc/cpuinfo

출력이 없는 경우, 호스트에 공개된 인텔 경로에 필요한 5단계 EPT 기능이 없다는 의미입니다. 플래그가 존재한다면, 다음 질문은 4단계 및 5단계 EPT가 실제로 신뢰할 수 없는 L1 게스트에 도달하고 있는지 여부입니다. 왜냐하면 /proc/cpuinfo 가상 CPU 모델이 전달하는 내용이 아니라 호스트 CPU를 설명합니다. 중첩 가상화를 계속 활성화해야 하는 경우, 신뢰할 수 없는 게스트에게 5단계 EPT를 노출하는 CPU 모델은 피해야 합니다. 최신 인텔 시스템에서는 중첩 가상화를 비활성화하는 것이 여전히 더 신뢰할 수 있는 임시 대응책입니다.

보호 조치가 완료되면 다음 명령어를 사용하여 임시 구성을 제거하십시오. sudo rm /etc/modprobe.d/99-zapscape.conf 그리고 다음 유지보수 시간대에 모듈을 다시 로드하십시오.

더 픽스

업스트림 수정 내용이 커밋되었습니다. 2abd5287f083, “KVM: x86: MMU 페이지를 사용할 수 있게 한 후 유효하지 않거나 더 이상 사용되지 않는 루트 확인.”

변경 사항은 사소합니다. stale-root 검사를 다음 단계로 옮겼습니다. make_mmu_pages_available() 영향을 받은 두 단락 경로 모두에서, 총 12줄 미만의 변경 사항이 있는 arch/x86/kvm/mmu/mmu.c 그리고 arch/x86/kvm/mmu/paging_tmpl.h. 이제 KVM은 먼저 모든 회수 작업을 수행한 다음, 루트가 여전히 유효한지 확인한 후에야 작업을 계속합니다. 이를 통해 하이퍼바이저가 회수 작업으로 인해 이미 무효화된 루트 아래에 활성 매핑을 생성하는 것을 방지합니다.

새로운 데이터 구조도 없고, 추적해야 할 영구적인 상태도 없습니다. 바로 이 점이 재부팅 없이 패치를 적용하는 데 적합한 이유이지만, 백포트 자체는 각 벤더 커널의 오류 처리 경로가 메인라인에서 얼마나 멀어졌는지에 따라 달라집니다.

KernelCare 패치 현황 및 배포

2026년 8월 11일 현재, 첫 번째 버전이 출시되었습니다:

데비안 13: 메인 피드
우분투 24.04 Noble, AWS용 우분투 24.04 Noble, AWS용 우분투 22.04 Jammy, 6.8 커널 및 Proxmox VE 8이 테스트 피드에 포함되어 있습니다.

테스트 피드 빌드는 당일 메인 피드에 반영될 예정이었으므로, 이 빌드들이 여전히 테스트용으로만 남아 있다고 가정하지 말고 해당 커널의 피드 상태를 확인해 주시기 바랍니다.

잔여 가족 구성 현황:

Enterprise Linux 9의 모든 커널은 검토 중인 패치의 적용 대상이며, 단, 수정 작업이 필요하여 별도의 작업으로 미뤄진 가장 오래된 70 시리즈 커널은 예외입니다.

• Ubuntu 24.04 패치가 준비되었으며 현재 검토 중입니다.
• 데비안 12 패치들이 검토 중이며 하드웨어 검증 결과를 기다리고 있습니다.
• Enterprise Linux 8 및 Ubuntu 22.04용 패치가 준비되었으며, 아직 검증 절차가 진행 중입니다.
• Enterprise Linux 10이 대기 중입니다

여러 제품군 전반에 걸쳐 제한 요인은 패치의 복잡성이 아니라 AMD 테스트 하드웨어였습니다. 테스트 및 배포가 완료될 때까지 커널에 따라 이용 가능 여부가 달라질 것입니다.

패치가 아직 테스트 피드에 있는 상태에서 업데이트를 서둘러 진행하고 싶다면:

kcarectl --update --prefix test

프로덕션 피드에 배포된 후, 패치는 다음 예정된 실행 시점에 적용되거나, 필요에 따라 수동으로 적용됩니다:

kcarectl --update

그런 다음 실행 중인 커널에 실제로 무엇이 로드되어 있는지 확인해 보세요:

kcarectl --patch-info | grep 'CVE-2026-64561'

빌드 타임스탬프는 두 번째 확인 기준입니다:

kcarectl --info | grep kpatch-build-time

2026년 8월 6일 또는 그 이후 날짜의 빌드는 유용한 참고 사항일 뿐, 해당 커널에서 이 특정 CVE가 해결되었음을 보장하는 것은 아닙니다. 패치 정보에 해당 CVE가 아직 기재되어 있지 않은 경우, 날짜를 근거로 삼기보다는 고객 지원팀을 통해 해당 커널에 대한 해결 여부를 확인하십시오. 어느 쪽이든, 임시 완화 조치를 제거하기 전에 반드시 확인해야 하며, 제거한 후에 확인해서는 안 됩니다.

KernelCare가 재부팅 없이 중요한 커널 취약점을 어떻게 패치하는지 알아보세요 →

연표

참조

• 김현우(@v4bel), Zapscape 관련 정보를 oss-security에 공개
• Zapscape 기술 문서 및 개념 증명, zapscape.io
• Upstream Linux 수정 사항 2abd5287f083, “KVM: x86: MMU 페이지를 사용할 수 있게 한 후 유효하지 않거나 더 이상 사용되지 않는 루트 확인”
• 리눅스 커밋 f95eec9bed76, “KVM: x86/mmu: 유효하지 않은 SP를 활성 페이지 목록에 다시 포함하지 않음”
• CVE-2026-64561에 대한 레드햇 보안 권고 및 CVE 기록
• CentOS Stream 10 백포트 병합 요청 3068, 초안 상태
• 해당되는 RHEL, AlmaLinux, CloudLinux, Debian, Ubuntu, Oracle 및 Proxmox 보안 권고 사항