2026년 9월 패치 튜스데이 — SSTP 원격코드실행(CVSS 9.8)과 Hyper-V 크리티컬 우선 패치

패치 튜스데이 노트를 매달 훑는 입장에서 말하면, 이번 9월 건은 우선순위 판단이 비교적 쉬운 편이다. 보통은 "크리티컬이 수십 개인데 뭘 먼저 하냐"로 골치가 아픈데, 이번엔 CVSS 9.8짜리 무인증 RCE 하나가 목록 맨 위에서 확실하게 손을 들고 있다. SSTP다. 나머지는 그 뒤에 줄 세우면 된다.

이번 패치에서 가장 급한 게 뭔가?

CVE-2026-73009, 즉 Windows SSTP(Secure Socket Tunneling Protocol) 원격코드실행이다. CVSS 기본 점수 9.8로 이번 릴리스 최고치이고, 무엇보다 인증이 필요 없다. 공격자가 계정을 갖고 있을 필요도, 사용자가 뭔가를 클릭할 필요도 없다. 취약한 SSTP 엔드포인트로 특수하게 조작한 패킷을 보내는 것만으로 원격에서 코드가 실행된다. 사전 인증 RCE(pre-auth RCE)는 랜섬웨어 그룹과 초기 침투 브로커가 가장 좋아하는 유형이라, 실전 악용까지의 시간이 짧을 가능성이 높다.

여기서 핵심은 "네가 SSTP를 켜놨는지"다. SSTP는 TCP 443, 즉 HTTPS와 같은 포트를 쓴다. 그래서 방화벽 로그만 봐서는 평범한 웹 트래픽과 구분이 잘 안 된다. RRAS(라우팅 및 원격 액세스) VPN을 굴리는 조직이 특히 위험하다.

이번 릴리스에서 운영자가 실제로 신경 써야 할 크리티컬만 추린 표다. 나머지 다수 패치는 이 넷을 처리한 뒤에 정기 사이클로 밀어도 된다.

SSTP가 뭐길래 CVSS 9.8인가?

SSTP는 마이크로소프트가 만든 VPN 터널링 프로토콜이다. PPP 트래픽을 SSL/TLS 채널에 실어 TCP 443으로 흘려보낸다. 443을 쓰는 이유는 명확하다. 카페·호텔·기업 방화벽 대부분이 HTTPS는 열어두니까, 다른 VPN 프로토콜(예: IKEv2의 UDP 500/4500)이 막힌 망에서도 SSTP는 잘 뚫린다. 편의성이 곧 노출 면적이 된 셈이다.

문제는 이 프로토콜을 처리하는 서버 측 파서에 있다. 무인증 RCE라는 건, 인증 핸드셰이크가 끝나기 전에 공격자 입력이 취약한 코드 경로에 닿는다는 뜻이다. 개인적으로 이런 "핸드셰이크 이전 파싱" 취약점을 제일 무서워한다. 접근 통제로 막을 수가 없기 때문이다. 포트가 열려 있으면 그냥 도달한다.

Hyper-V 크리티컬 3종은 뭘 노리나?

세 취약점 모두 게스트 VM 안의 코드가 호스트(하이퍼바이저) 쪽 메모리를 망가뜨리는 계열이다. 클라우드나 VDI, 멀티테넌트 가상화처럼 "신뢰할 수 없는 워크로드를 같은 호스트에 태우는" 환경에서 특히 치명적이다. 게스트 하나만 장악해도 호스트를 넘보는 길이 열리면, 그 호스트 위 다른 모든 VM이 위험해진다.

• CVE-2026-69603 — 힙 기반 버퍼 오버플로. 가상화 스택이 게스트가 넘긴 데이터를 힙 버퍼에 담다가 경계를 넘는 유형. 전형적인 메모리 손상 → 코드 실행 경로다.
• CVE-2026-80083 — 신뢰할 수 없는 포인터 역참조. 게스트가 제어하는 값이 포인터로 그대로 역참조되는 케이스. 잘 엮으면 호스트 메모리 읽기/쓰기로 이어진다.
• CVE-2026-72961 — 가상 TPM 버퍼 오버플로. vTPM(가상 신뢰 플랫폼 모듈) 처리 경로의 오버플로다. vTPM은 보안을 위해 켜는 기능인데, 그 처리기가 공격면이 됐다는 게 아이러니다. Windows 11 요구사항 때문에 vTPM을 켠 VM이 많아졌다는 점도 신경 쓰인다.

세 개를 따로 볼 것 없이 "Hyper-V 호스트는 이번 달에 무조건 패치" 한 줄로 기억하면 된다. 게스트 탈출(VM escape) 계열은 단독으로도 크리티컬이지만, 이미 게스트 하나를 확보한 공격자에게는 권한 상승의 사다리가 된다.

그래서 뭘 먼저 패치해야 하나?

노출 형태별로 우선순위를 나누면 판단이 빨라진다. 내가 실제로 쓰는 분류다. "인터넷에 뭘 열어놨나"가 1차 기준이고, "그 위에 남의 워크로드가 도나"가 2차 기준이다.

한 가지 현장 팁. "우리는 SSTP 안 써요"라고 자신하는 조직 치고 실제로 RRAS 설정을 열어본 곳이 드물다. 예전에 IKEv2만 쓰는 줄 알았던 게이트웨이가 SSTP도 같이 수신하고 있던 걸 뒤늦게 발견한 적이 있다. 자신하지 말고 아래 명령으로 실제 상태를 확인하는 게 맞다.

지금 당장 점검하는 법

패치를 밀기 전에 "내가 취약한 상태인지"부터 5분이면 확인할 수 있다. 관리자 PowerShell에서 아래를 돌려보자. 먼저 RRAS/SSTP 수신 여부.

# 1) RRAS(원격 액세스) 역할이 설치·구동 중인가
Get-Service RemoteAccess | Select-Object Name, Status, StartType

# 2) SSTP 터널이 활성화돼 있는가 (RemoteAccess 모듈)
#    TunnelType 목록에 Sstp가 있으면 SSTP 수신 중이라는 뜻
Get-VpnServerConfiguration | Select-Object -ExpandProperty TunnelType

# 3) 443을 수신(LISTEN)하는 프로세스 확인 — SSTP는 TCP 443 사용
Get-NetTCPConnection -State Listen -LocalPort 443 |
    Select-Object LocalAddress, LocalPort, OwningProcess

다음은 Hyper-V 호스트인지 확인. 서버와 클라이언트(Win10/11) 각각 확인법이 조금 다르다.

# 서버: Hyper-V 역할 설치 여부
Get-WindowsFeature -Name Hyper-V | Select-Object Name, InstallState

# 클라이언트(Win10/11): Hyper-V 선택 기능 상태
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All |
    Select-Object FeatureName, State

# 호스트가 맞다면 구동 중인 VM 목록 (vTPM 사용 VM도 함께 점검)
Get-VM | Select-Object Name, State
Get-VMSecurity -VMName * 2>$null | Select-Object VMName, TpmEnabled

패치는 정석대로 Windows Update로 이번 달 누적 업데이트를 적용하면 세 Hyper-V CVE와 SSTP CVE가 함께 닫힌다. 자동화 환경이라면 PSWindowsUpdate로 밀고, 적용 후 설치 이력을 확인한다.

# PSWindowsUpdate로 이번 달 보안 업데이트 설치 (모듈 미설치 시: Install-Module PSWindowsUpdate)
Import-Module PSWindowsUpdate
Get-WindowsUpdate -Category "Security Updates" -AcceptAll -Install -AutoReboot

# 적용 확인: 최근 설치된 업데이트 이력 (설치일 내림차순)
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

패치를 못 하면 뭐라도 해야 한다

유지보수 창을 당장 못 여는 서버도 있다. 그럴 때 임시 완화책은 "공격면 자체를 없애는 것"이다. 완치가 아니라 지혈이라는 걸 잊지 말고, 패치 전까지의 시간 벌기로만 써라.

• SSTP 수신 중단. SSTP VPN을 당장 안 써도 되면 터널 타입에서 SSTP를 빼거나, 인터넷에서 오는 443 인바운드를 VPN 게이트웨이 앞단에서 차단·제한한다. IKEv2 등 대체 프로토콜로 임시 전환.
• 노출 최소화. 관리용/VPN 엔드포인트를 아는 IP 대역이나 조건부 접근 뒤로 숨긴다. 인터넷 전체에 열어둘 이유는 거의 없다.
• Hyper-V는 격리로 시간 벌기. 신뢰할 수 없는 게스트가 도는 호스트라면, 패치 전까지 해당 워크로드를 별도 호스트로 분리하거나 중단을 검토한다. 게스트 탈출은 "같은 호스트에 남의 코드가 있을 때" 위험하니, 그 전제를 깨는 게 완화다.

# (임시) SSTP만 비활성화하고 IKEv2로 제한 — 서비스 영향 확인 후 적용
Set-VpnServerConfiguration -TunnelType IKEv2

# (임시) 인터넷 인바운드 443을 신뢰 IP로만 허용하는 방화벽 규칙 예시
New-NetFirewallRule -DisplayName "Restrict-SSTP-443" -Direction Inbound `
    -Protocol TCP -LocalPort 443 -RemoteAddress 203.0.113.0/24 -Action Allow

방화벽 규칙을 만질 땐 443이 SSTP 전용이 아니라 웹 서비스와 겸용일 수 있다는 점을 반드시 확인하자. 아무 생각 없이 443을 다 막으면 멀쩡한 웹 서비스까지 같이 죽는다. 이거로 새벽에 장애 콜 받아본 사람 여기 있다.

자주 묻는 질문

CVE-2026-73009는 얼마나 위험한가요?

이번 9월 패치 튜스데이에서 가장 위험하다. CVSS 9.8에 인증이 필요 없는 원격코드실행이라, 취약한 SSTP 엔드포인트에 특수 패킷을 보내는 것만으로 공격자가 코드를 실행할 수 있다. 사용자 상호작용도 필요 없어 대량 스캔·자동 악용 대상이 되기 쉽다. 인터넷에 SSTP를 노출한 서버라면 최우선 비상 패치 대상이다.

우리가 SSTP를 쓰는지 어떻게 확인하나요?

관리자 PowerShell에서 Get-Service RemoteAccess로 RRAS 구동 여부를 보고, Get-VpnServerConfiguration의 TunnelType 목록에 Sstp가 있는지 확인하면 된다. SSTP는 TCP 443을 쓰므로 Get-NetTCPConnection으로 443 수신 프로세스도 같이 점검하라. "안 쓰는 줄 알았는데 켜져 있던" 경우가 흔하니 설정을 실제로 열어봐야 한다.

Hyper-V CVE 3종은 왜 함께 묶어 보나요?

CVE-2026-69603, 80083, 72961 모두 게스트 VM에서 트리거해 호스트에 영향을 주는 메모리 손상 계열이기 때문이다. 대응도 동일하게 "Hyper-V 호스트 9월 누적 업데이트 적용"으로 한 번에 닫힌다. 특히 신뢰할 수 없는 워크로드를 같은 호스트에 태우는 멀티테넌트 환경에서 위험하다.

SSTP와 Hyper-V 중 뭘 먼저 패치해야 하나요?

인터넷에 노출된 SSTP/RRAS 서버가 1순위다. 무인증 원격 공격이 가능해 실전 악용까지의 시간이 가장 짧다. 그다음이 멀티테넌트 Hyper-V 호스트다. 단일 테넌트 사내 Hyper-V나 SSTP 미사용 자산은 정기 사이클로 밀어도 된다.

당장 패치할 수 없으면 어떻게 하나요?

공격면을 임시로 제거하라. SSTP는 터널 타입에서 제외하거나 443 인바운드를 신뢰 IP로 제한하고, IKEv2 등으로 임시 전환한다. Hyper-V는 신뢰할 수 없는 게스트를 별도 호스트로 격리한다. 어디까지나 패치 전까지의 시간 벌기이며 완치가 아니다.

SSTP 클라이언트만 쓰는 PC도 위험한가요?

CVE-2026-73009의 주 공격면은 SSTP를 수신하는 서버(RRAS) 쪽이다. 사내에서 접속만 하는 클라이언트 PC는 이 취약점의 1차 표적이 아니다. 다만 모든 시스템은 이번 달 누적 보안 업데이트를 정기적으로 적용해 다른 패치까지 함께 받는 게 맞다.

정확한 KB 번호는 어디서 확인하나요?

OS 빌드마다 KB가 다르므로 마이크로소프트 업데이트 카탈로그나 릴리스 정보에서 자신의 빌드에 해당하는 9월 누적 업데이트 KB를 확인하라. 적용 후에는 Get-HotFix -Id KB번호로 설치를 검증하고, WSUS/Intune 환경이면 링 배포로 서버부터 우선 적용하는 것을 권한다.

출처

분석·검증 근거: CrowdStrike, "Patch Tuesday Analysis — September 2026". 원문: crowdstrike.com/en-us/blog/patch-tuesday-analysis-september-2026. CVE별 정확한 영향 범위와 KB 매핑은 마이크로소프트 보안 업데이트 가이드에서 자신의 OS 빌드 기준으로 반드시 재확인하라.