Skip to content
research

클라우드 호스트의 재부팅을 강제한 Linux 버그

18년 된 결함이 평범한 가상 네트워크 경로를 게스트 VM에서 호스트로 이어지는 잠재적 경로로 변모시켰습니다. 이 긴박한 상황은 클라우드 제공업체가 격리에 대해 생각하는 방식의 사각지대를 드러냈으며, 게스트가 스스로 설치할 수 없는 패치가 필요했습니다.

Aki Tanaka
클라우드 호스트의 재부팅을 강제한 Linux 버그

샌드박스 챌린지에서 발견된 보안의 구멍

지난 주말, 치명적인 Linux 버그로 인해 전 세계 호스팅 기업의 수천 명의 엔지니어가 서버를 재부팅하기 위해 분주히 움직였습니다. 이 결함은 신뢰할 수 없는 가상 머신(VM)이 격리 경계를 침범하고, 권한을 상승시키며, 기본 물리적 호스트를 장악하여 동일한 물리적 서버에 있는 다른 워크로드를 위험에 빠뜨릴 수 있게 했습니다.

CVE-2026-99999(CVSS 9.3 치명적)로 추적되는 PwnEscape라는 이름의 이 취약점은 Vercel의 100만 달러 규모 샌드박스 챌린지에서 드러났습니다. pwn.ai의 연구원들은 AI 보조 코드 분석을 활용하여 단 3일 만에 이 탈출 경로를 식별했으며, 이는 취약점 발견의 강력한 새로운 지평을 보여주었습니다.

pwn.ai의 실험실 시연은 호스트 머신에 대한 완전한 루트 권한을 획득하여 이론적인 익스플로잇을 확인했습니다. 그러나 이 개념 증명이 모든 클라우드 제공업체나 VM이 운영 환경에서 실제로 공격받았음을 의미하지는 않습니다. Linux 커널 버전 5.10에서 7.2까지 백포트된 이 수정 사항은 단순히 게스트 VM을 업데이트하는 것이 아니라 호스트 커널 자체를 패치하고 재부팅해야 합니다.

하이퍼바이저가 아닌 네트워크를 통해 이루어진 탈출 경로

놀랍게도 CVSS 점수 9.3의 치명적인 CVE-2026-99999로 추적되는 이 취약점은 하이퍼바이저 자체에 존재하지 않았습니다. 대신 이 결함은 Linux 호스트의 IPv4 네트워킹 코드, 특히 skb_checksum_help와 체크섬 오프로드 메타데이터 처리 과정에 깊숙이 자리 잡고 있었습니다. 이 예상치 못한 위치로 인해 공격은 기존의 가상화 경계를 우회할 수 있었습니다.

GPT-5.6 Sol의 도움을 받은 pwn.ai의 연구원들은 TOCTOU(time-of-check/time-of-use) 취약점을 악용했습니다. 게스트 VM이 호스트로 비정상적인 네트워크 패킷을 보냈습니다. 호스트의 초기 검증은 해당 패킷을 안전한 것으로 간주했으나, 이후의 지연된 처리 단계에서 게스트가 안전성 검사 이후에 패킷의 중요한 부분을 변경할 수 있었습니다.

이러한 검증 후 조작은 호스트가 자신의 메모리를 손상시키고 민감한 호스트 메모리 조각을 반복적으로 유출하도록 유도했습니다. 실험실 환경에서 pwn.ai 팀은 이 메모리 유출을 완전한 게스트-호스트 루트 코드 실행으로 발전시켜 물리적 머신에 대한 완전한 제어권을 입증했습니다. 2008년 Linux 2.6.27부터 존재했던 이 치명적인 코드는 18년 동안 패치되지 않은 상태였습니다.

수정 사항이 제공업체들을 재부팅 경쟁으로 몰아넣은 이유

이 치명적인 취약점의 공개는 클라우드 업계 전반에 즉각적인 긴박함을 불러일으켰습니다. 수정 사항은 10월 14일 업스트림 Linux에 반영되었고, 이어 10월 15일에 상세 보고서와 CVE-2026-99999가 공개되었습니다. 이는 호스팅 기업들이 하이퍼바이저를 재부팅하는 긴급 유지보수 물결을 일으켰습니다.

영향은 다양했지만, 많은 제공업체에게 패치 작업은 광범위한 다운타임을 요구했습니다. 예를 들어 Fly.io는 거의 33시간 동안 지속된 플랫폼 전반의 순차적 호스트 재부팅을 보고했습니다. 소규모 제공업체들은 하이퍼바이저별로 패치 상태를 추적했으며, 한 업체는 99개의 하이퍼바이저 중 98개를 패치했다고 보고했습니다.

중요한 점은 모든 클라우드 서비스가 영향을 받은 것은 아니라는 것입니다. AWS는 EC2, AWS Lambda, Fargate를 포함한 관리형 서비스가 영향을 받지 않았다고 밝혔습니다. 그러나 Debian, Ubuntu, RHEL과 같은 배포판들은 사용자를 위해 5.10에서 7.2까지의 안정적인 브랜드를 포괄하는 패치된 커널을 신속하게 준비하고 릴리스했습니다.

핵심 문제는 게스트 VM뿐만 아니라 기반 물리 호스트 커널에 대한 패치가 필수적이라는 점이었습니다. 이는 공급자가 재부팅 일정을 잡아야 함을 의미하며, 이는 상당한 운영상의 부담이었습니다. 해당 취약점에 대한 더 자세한 기술적 내용은 원본 연구를 참조하십시오: PwnEscape: Guest-to-Host KVM Escape (CVE-2026-99999) | PWN.AI Security Research.

이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.

하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음

패치는 VM 내부가 아닌 호스트에 적용되어야 합니다.

운영자는 게스트가 아닌 호스트를 패치해야 합니다. 신뢰할 수 없는 가상 머신을 실행 중인 노출된 KVM 호스트를 식별한 다음, 배포판의 권고 사항에 따라 수정 사항이 포함된 커널을 설치하십시오. 이 새로운 커널로 재부팅하십시오. 게스트 OS만 업데이트하는 것으로는 호스트 침해를 방지할 수 없습니다.

즉시 재부팅할 수 없는 경우, TuxCare의 KernelCare와 같은 live patching 서비스가 대안이 될 수 있습니다. 모든 라이브 패치가 재시작의 필요성을 완전히 없애주는 것은 아니므로, 특정 커널 버전에 대한 지원 여부를 확인하고 제공업체의 지침을 참조하십시오.

CVE-2026-99999로부터 얻을 수 있는 더 넓은 교훈은 매우 중요합니다. VM 격리는 하이퍼바이저를 넘어섭니다. 보안 검토는 네트워크 경로 및 기반 IPv4 네트워킹 스택을 포함하여 게스트가 도달할 수 있는 모든 호스트 구성 요소를 포괄해야 합니다. 2008년 Linux 2.6.27에서 시작된 이 사건은 오랫동안 사용된 핵심 커널 구성 요소조차도 클라우드 인프라에 영향을 미치는 치명적인 취약점을 가질 수 있음을 강조합니다.

자주 묻는 질문

PwnEscape란 무엇인가요?

PwnEscape는 게스트 VM이 경계를 벗어나 호스트에 대한 루트 권한을 획득할 수 있음을 연구원들이 입증한 Linux 네트워킹 결함입니다.

호스팅 업체들이 서버를 재부팅한 이유는 무엇인가요?

수정 사항은 호스트 커널에서 실행되어야 합니다. 공급자는 패치된 커널을 로드하고 테넌트 간의 보호를 복구하기 위해 하이퍼바이저를 재부팅했습니다.

게스트 VM을 업데이트하면 PwnEscape가 해결되나요?

아니요. 게스트 업데이트는 취약한 호스트 커널을 패치하지 않으므로, 호스트 운영자가 수정 사항을 설치해야 합니다.

KVM 호스트를 운영하는 운영자는 무엇을 해야 하나요?

호스트 배포판의 보안 권고를 확인하고, 수정 사항이 포함된 커널을 설치한 후 재부팅하거나 지원되는 라이브 패치를 사용하십시오.

Found this useful? Share it.

For builders

Want Stork to write one of these about your product?

Send us a URL. We use the product, form a view, and publish what we actually think — in 8 languages, labeled Sponsored, with no copy approval on your side. That last part is what makes it worth quoting.

See how it works$199 · AI tools & software only

빌더를 위해

이 페이지는 지금 다른 사람의 도구를 위해 일하고 있습니다.

AI 에이전트가 읽고, 구매자가 도착합니다. 8개 언어와 MCP로 답합니다. 당신의 도구도 가질 수 있습니다 — 24시간 안에 공개.