Veeam KB4966 대응 가이드 - Linux 커널 CVE-2026-98432 영향 범위와 패치 방법

2026년 11월 6일, Veeam에서 CVE-2026-98432에 대한 영향 범위와 대응 방법을 정리한 KB4966을 공개했습니다.

이번 이슈는 Veeam Backup & Replication 자체 코드의 취약점이라기보다 Linux 커널의 TCP/IPv4 연결 처리 과정에서 발생하는 문제입니다. CVSS 점수는 **9.8(Critical)**이고, 원격에서 비정상적인 TCP 패킷을 통해 커널 메모리 손상이나 서비스 중단을 유발할 수 있는 Use-After-Free 취약점입니다.

Veeam 환경에서 특히 주의할 부분은 Backup Server가 Windows여도 Linux 기반 Helper Appliance가 별도로 배포될 수 있다는 점입니다. VSA뿐 아니라 Linux Infrastructure Appliance, Windows 기반 VBR의 Helper, Recovery Media, Cloud Appliance까지 각각 확인해야 합니다.

핵심 요약: VSA/VIA 13.1은 Veeam Updater, Windows 기반 VBR 13.1의 Linux Helper는 Private Fix, 고객이 직접 구축한 Linux Repository/Proxy는 OS 제조사 커널 보안 패치가 대응 경로입니다. Kasten 컨테이너 자체에는 Linux 커널이 없으므로 Kasten 이미지 패치가 아닌 Kubernetes Node OS를 확인해야 합니다.

어떤 취약점인가요?

CVE-2026-98432는 Linux 커널의 IPv4 TCP 연결 설정 과정에서 메모리가 해제된 뒤에도 참조되는 Use-After-Free 문제입니다. Red Hat 보안 공지에서는 인증되지 않은 원격 공격자가 특수한 타이밍의 TCP 트래픽을 이용해 시스템 충돌(DoS), 메모리 손상, 잠재적인 원격 코드 실행을 유발할 수 있다고 설명합니다.

중요한 점은 모든 Veeam 제품이 동일한 방식으로 취약한 것은 아니다라는 것입니다. Linux 커널을 실제 포함하거나 사용하는 구성요소인지, OS를 Veeam이 관리하는지, 고객이 직접 관리하는지에 따라 조치가 달라집니다.

또한 Multipath TCP(MPTCP)를 사용하지 않는다고 해서 안전하다고 판단할 수 없습니다. Red Hat과 Ubuntu 모두 MPTCP 비활성화를 완전한 해결책으로 보지 않으며, 수정된 커널을 적용하는 것이 기본 대응입니다.

영향 범위를 제품별로 구분하면

VIA에서 관리되는 Hardened Repository, Linux Repository, Proxy, Gateway, Mount Server, WAN Accelerator, CDP Proxy, NFS Share 같은 역할도 확인 대상입니다.

반면 고객이 일반 RHEL·Ubuntu·Rocky Linux 등을 설치하고 그 위에 Veeam Repository/Proxy 역할만 추가했다면, 해당 OS 커널은 Veeam Updater가 아닌 Linux 배포판의 보안 업데이트를 기준으로 판단해야 합니다.

1. Veeam Software Appliance / Infrastructure Appliance 13.1

Veeam KB4966에 따르면 VSA/VIA 13.1에는 2026년 11월 2일부터 수정 커널이 Veeam Repository에 제공되고 있습니다.

이번 이슈에 대응하는 안내 커널 버전은 다음과 같습니다.

5.14.0-570.60.1+27.2.el9_6_ciq

이 값은 VSA/VIA 13.1용 수정 커널 기준입니다. 다른 Linux 배포판이나 다른 커널 계열에 그대로 적용하는 버전 번호는 아닙니다. 이후 더 새로운 보안 커널이 설치된 환경이라면 동일한 문자열이 아니더라도 제조사의 패치 상태와 업데이트 이력으로 판단해야 합니다.

Host Management Console에서 업데이트

1. Veeam Backup Server의 Host Management Console에 로그인합니다.

2. 좌측 Updates 메뉴를 선택합니다.

3. Check for updates를 선택합니다.

4. 필요한 업데이트를 확인합니다.

5. Install Updates Now를 눌러 설치합니다.

6. 안내된 경우 Appliance를 재부팅합니다.

7. History에서 설치 결과를 확인합니다.

아래는 Veeam 공식 Help Center의 Updates 화면 예시입니다. 이미지에 표시된 과거 날짜와 패키지 용량은 CVE-2026-98432 패치 결과가 아니라 메뉴 설명용 예시입니다.

Veeam Host Management Console → Updates 화면 — 출처: Veeam Help Center (공식 UI 예시, 이번 CVE 패치 완료 화면 아님)

기본 설정에서 Veeam Updater는 12시간마다 Repository를 확인합니다. KB4966은 Mandatory Update가 기본적으로 Backup Server 현지 시간 기준 가장 가까운 일요일 오후 2시에 자동 설치된다고 안내합니다. 즉 '자동으로 설치될 테니까 당장 확인하지 않아도 된다'고 판단하기보다 현재 설치 이력을 확인하는 것이 좋겠습니다.

로컬 Mirror Repository를 사용하는 폐쇄망에서는 Mirror가 동기화된 뒤에야 업데이트가 전달됩니다. 또한 Infrastructure Appliance에 Custom Update Configuration을 적용했다면 해당 장비의 Host Management Console에서도 별도로 확인해야 합니다.

업데이트 목록이 비어 있다면?

업데이트 항목이 보이지 않는다고 해서 곧바로 실패라고 단정할 수 없습니다. 이미 설치된 상태일 수 있으므로 History 탭에서 패키지 업데이트 및 재부팅 이력을 확인합니다.

Veeam Updater History의 설치 성공 및 세부 단계 확인 예시 — 출처: Veeam Help Center (기존 업데이트 예시 화면)

작업 중 재부팅이 필요한 경우 Console·Web UI 연결이 일시적으로 끊길 수 있습니다. 운영 Job 실행 여부와 유지보수 시간을 확인한 뒤 진행해야 합니다.

2. Windows 기반 VBR 13.1: Linux Helper Appliance 확인

Backup Server가 Windows라고 해서 이번 Linux 커널 취약점과 무관한 것은 아닙니다. VBR은 특정 복구·테스트 작업에서 Linux 기반 Helper Appliance를 사용하기 때문입니다.

KB4966에서 안내한 Linux Helper 사용 사례는 비 Windows 게스트 OS 파일 복구, Virtual Lab의 Proxy Appliance, Linux Workload의 Microsoft Azure 복구, Helper를 사용하는 Amazon EC2 및 Google Compute Engine 복구입니다.

이러한 Helper는 자체 Linux 커널을 포함하므로 Windows Backup Server의 OS 업데이트만으로 해결되지 않습니다.

Windows VBR 13.1 Private Fix 설치 전 확인

Windows 기반 VBR 13.1은 반드시 13.1.2.57 Build를 먼저 설치한 다음 KB4966의 Private Fix를 적용해야 합니다.

1. VBR Console의 Main Menu → Help → About에서 현재 Build를 확인합니다.

2. 이전 Build라면 공식 업데이트 경로를 따라 13.1.2.57을 설치합니다.

3. Veeam KB4966의 Private Fix 다운로드 항목을 확인합니다.

4. Veeam My Account 또는 공식 KB를 통해 제공된 파일의 SHA256을 검증합니다.

5. 백업 및 복구 Job과 유지보수 시간을 확인하고, KB 안내에 맞춰 적용합니다.

6. 패치 후 Helper Appliance 재배포가 필요한 구성을 확인합니다.

2026년 11월 7일 KB에 안내된 파일명과 해시는 다음과 같습니다.

Filename:
VeeamBackup&Replication_13.1.2.57_20261105_PrivateFix.exe

SHA256:
63772D1ED2E9759E028F4D9693321E952B7D6D1FED4BAFC1C3C76D4DF2D0BE2B

Windows PowerShell에서 다운로드 파일의 해시는 아래와 같이 확인합니다.

Get-FileHash -Path "C:\Temp\VeeamBackup&Replication_13.1.2.57_20261105_PrivateFix.exe" -Algorithm SHA256

파일 해시는 패치를 적용하는 시점의 최신 공식 KB와 다시 대조해야 합니다. 패치 재배포가 있었다면 파일명과 해시가 바뀔 수 있습니다.

아래 이미지는 Veeam Software Appliance의 일반적인 Upload a Hotfix 기능을 설명하는 공식 화면입니다. Windows VBR용 EXE 패치를 이 UI에 업로드하라는 뜻이 아니며, Windows에서는 KB4966의 전용 적용 절차가 우선입니다.

Veeam Host Management Console의 Private Hotfix 업로드 UI 예시 — 공식 Help Center 화면. 이번 Windows VBR용 EXE 설치 화면은 아닙니다.

Windows VBR 12.3은 어떻게 해야 하나요?

2026년 11월 7일 기준, VBR 12.3의 Linux Helper용 Private Fix는 KB4966에 추후 제공 예정으로 표시되어 있습니다.

VBR 13.1용 Private Fix를 12.3 환경에 적용하면 안 됩니다. 해당 환경에서는 공식 KB 변경사항을 모니터링하면서 지원되는 조치가 발표되면 적용해야 합니다.

또한 Windows 기반 VBR 13.1 신규 설치의 경우, KB에 수정 사항이 포함된 Repacked 13.1.2 ISO를 My Account에서 내려받도록 안내하고 있습니다. 기존 설치 업그레이드와 신규 설치 경로를 구분하는 편이 좋겠습니다.

3. 패치 후 Helper Appliance 재배포 여부 확인

Fix 설치가 끝났더라도 기존에 실행 중인 Helper Appliance가 그대로 남아 있다면 수정된 이미지가 반영되지 않았을 수 있습니다.

작업할 때만 생성되는 Helper는 업데이트 이후 다음 작업에서 새 이미지로 배포됩니다. 반면 계속 실행되거나 보관되는 Helper는 별도 조치가 필요합니다.

Virtual Lab

Virtual Lab의 Proxy Appliance는 지속적으로 배포되는 구성입니다. Veeam에서는 각 Virtual Lab의 설정을 열고 Wizard를 끝까지 진행해 새로운 Proxy Appliance로 재배포하도록 안내합니다.

작업 전에는 SureBackup 실행 여부와 Virtual Lab 연결 구성을 확인하고, 재배포 후에는 설정 및 테스트 Job 동작을 확인해야 합니다.

Microsoft Azure Helper

Microsoft Azure의 지속 배포 Helper Appliance도 별도 재배포가 필요합니다. 공식 가이드는 기존 Helper Appliance를 제거한 뒤 다시 구성하는 절차를 안내합니다.

기존 클라우드 복구 정책 및 Helper가 사용하는 네트워크·권한 설정을 기록한 뒤 작업하는 것이 안전합니다.

중요: Updater 또는 Private Fix 설치 성공과 실제 Helper Appliance 교체 완료는 별개입니다. Virtual Lab 및 Azure Helper는 기존 배포 리소스 재구성 여부까지 확인해야 합니다.

4. Veeam Agent for Linux Recovery Media 교체

Veeam Agent for Linux는 실행 중인 Agent뿐 아니라 Recovery Media ISO/USB도 확인해야 합니다.

KB4966은 이번 업데이트가 반영되기 전에 제작된 Recovery Media에 취약한 Linux 커널이 포함돼 있을 수 있다고 안내합니다.

• Agent for Linux 13.1: Veeam Updater로 제공되는 수정 미디어 또는 공식 페이지의 최신 Recovery Media를 사용합니다.

• VBR 12.3에 포함된 Agent for Linux 계열: 관련 Private Fix 제공 상태를 최신 KB에서 확인합니다.

• 기존 ISO·USB: 업데이트 전 만들어진 부팅 미디어는 수정된 미디어로 교체해야 합니다.

Recovery Media를 교체한 뒤에는 테스트 환경에서 부팅, 네트워크, 저장소 및 복구 대상 디스크 인식까지 확인하면 좋겠습니다. 백업 Job이 정상이라고 해서 오래된 부팅 미디어의 안전성까지 보장되지는 않습니다.

5. Cloud Appliance와 Hypervisor Worker

AWS·Azure·Google Cloud Backup Appliance

Veeam Plug-In for AWS, Microsoft Azure, Google Cloud의 Backup Appliance는 Ubuntu Linux를 사용합니다. 이번 취약점의 커널 수정은 Veeam Updater를 통해 제품 업데이트와 함께 제공되므로, 각 Appliance에서 적용 가능한 업데이트를 확인해야 합니다.

단순히 VBR Console 버전만 보고 Cloud Appliance의 OS 업데이트까지 끝났다고 판단하면 안 됩니다.

Hypervisor Plug-in Worker

VBR 13.1에 포함된 Hypervisor Plug-in이 배포하는 Worker는 실행 시 Veeam Repository에서 업데이트를 받아 설치하는 방식이 안내되어 있습니다.

기존 Worker를 계속 사용하는지, 다음 Backup/Restore 작업 시 신규 Worker가 실행되는지 실제 환경에서 확인하고, 작업 성공과 업데이트 이력을 함께 점검하는 것이 좋겠습니다.

6. Kasten은 왜 컨테이너 업데이트 대상이 아닐까요?

Veeam KB4966에서 Kasten for Kubernetes는 영향 대상 아님으로 표시되어 있습니다. 정확한 의미는 Kasten 컨테이너 이미지에 Linux 커널이 들어 있지 않다는 것입니다.

Kasten 서비스는 Kubernetes Node의 Linux 커널을 공유합니다. 따라서 Kubernetes 클러스터의 Node OS가 취약한 커널을 사용한다면 해당 OS 배포판 또는 Kubernetes 플랫폼 공급업체의 보안 업데이트가 필요합니다.

# 노드와 OS 버전 확인
kubectl get nodes -o wide

# 노드별 커널 버전 정보
kubectl get nodes -o custom-columns=NAME:.metadata.name,KERNEL:.status.nodeInfo.kernelVersion,OS:.status.nodeInfo.osImage

이 명령은 Node의 현재 커널 버전을 조회하는 용도입니다. 결과가 특정 버전이라는 사실만으로 수정 여부를 확정할 수는 없습니다. 각 Node OS 공급업체의 CVE 보안 공지와 비교해야 합니다.

앞서 eMudhra 인증서 이슈에서는 Kasten 컨테이너 내부 Trust Store 업데이트가 필요했습니다. 그러나 이번 CVE-2026-98432는 Linux 커널 자체의 취약점이므로 대응 위치가 다릅니다. 같은 Kasten 환경이라도 어떤 계층의 보안 문제인지 구분하는 것이 중요합니다.

7. 고객이 직접 관리하는 Linux Repository·Proxy는 별도로 확인

일반 Linux 서버에 Veeam Hardened Repository, Proxy, Gateway 등을 설치해 사용하는 환경이라면 OS 커널의 패치 책임은 해당 Linux OS 관리자에게 있습니다.

예를 들어 RHEL, Rocky Linux, AlmaLinux, Ubuntu, Debian 등의 서버는 Veeam Updater가 OS 전체를 대신 패치해주는 Appliance와 다릅니다. OS 배포판의 CVE 상태와 지원 커널 패키지 기준으로 판단해야 합니다.

현재 부팅 중인 커널 확인

관리 권한이 있는 Linux 서버에서 다음 명령을 실행합니다.

uname -r
cat /etc/os-release

Ubuntu·Debian 계열은 설치된 커널 이미지 패키지도 확인해둡니다.

dpkg -l 'linux-image*' | grep '^ii'

RHEL·Rocky·AlmaLinux 계열은 아래처럼 확인할 수 있습니다.

rpm -q kernel-core

uname -r는 현재 실행 중인 커널을 보여줍니다. 새 커널 패키지를 설치했더라도 아직 재부팅하지 않았다면 구 커널이 실행 중일 수 있으므로 두 값을 함께 살펴보는 것이 좋겠습니다.

Ubuntu와 Red Hat 공지 구분

Ubuntu는 2026년 11월 2일 공지에서 22.04·24.04·26.04의 수정 커널을 -proposed Pocket에서 테스트 중이라고 안내했습니다. 이는 해당 패키지가 모든 운영 서버에 일반 보안 업데이트로 제공됐다는 의미가 아닙니다.

운영 환경에서는 Ubuntu CVE 상태 페이지의 최신 상태를 확인하고, 테스트 전용 -proposed 패키지를 임의로 도입하는 대신 OS의 승인된 보안 업데이트 절차를 따라야 합니다.

Red Hat은 RHSB-2026-016에서 RHEL 8·9·10과 OpenShift 영향을 안내합니다. 커널 패치가 제공된 배포판과 Repository를 기준으로 업데이트 계획을 수립해야 합니다.

MPTCP 비활성화만으로는 해결되지 않습니다. 취약점은 IPv4 TCP 처리 경로에 존재하므로 커널 보안 업데이트가 핵심 조치입니다. 임시 패킷 필터 규칙도 트래픽 차단과 서비스 장애 위험이 있어 제조사 지침 없이 적용하지 않는 편이 좋습니다.

8. 업데이트 적용 후 어떻게 확인할까요?

이번 건은 '패치를 실행했다'와 '취약한 커널이 더 이상 실행되지 않는다'를 구분해서 확인해야 합니다.

Appliance 검증

VSA/VIA는 Veeam Host Management Console의 Updates → History에서 설치 패키지와 성공 여부를 확인합니다. 재부팅이 필요했던 경우 완료 여부를 확인하고, 관리 경로에서 허용된다면 현재 Kernel Version도 확인합니다.

uname -r

VSA/VIA 13.1의 KB 기준 수정 커널은 5.14.0-570.60.1+27.2.el9_6_ciq입니다. 이보다 새로운 패치가 설치된 환경은 단순 문자열 일치 여부가 아니라 설치 이력과 제조사의 보안 패치 상태를 같이 확인합니다.

Veeam Updater 관련 로그는 공식 가이드에서 다음 경로로 안내합니다.

/var/log/veeam/veeam-updater/

Windows 기반 VBR의 Updater 관련 로그 경로는 다음과 같습니다.

C:\ProgramData\Veeam\Updater\Logs

단, 이 로그 경로는 Updater 동작 확인용이며 Windows Helper Private Fix의 적용 여부를 해당 로그만으로 증명할 수 있다는 뜻은 아닙니다. Private Fix는 KB 안내와 설치 후 구성요소 상태로 별도 검증해야 합니다.

복구 기능 테스트

• ☐

  VSA/VIA Update History에 보안 업데이트 성공이 기록됐는지

• ☐

  필요한 시스템 재부팅이 완료됐는지

• ☐

  현재 커널이 제조사 수정 버전 또는 그 이후 보안 패치 상태인지

• ☐

  Windows 기반 VBR 13.1의 Private Fix 적용 여부를 확인했는지

• ☐

  Virtual Lab Proxy 및 Azure Helper 재배포 여부를 확인했는지

• ☐

  기존 Linux Recovery Media를 수정된 이미지로 교체했는지

• ☐

  Cloud Appliance 및 Hypervisor Worker의 업데이트 상태를 확인했는지

• ☐

  Kasten을 사용하는 Kubernetes Node OS 패치 여부를 점검했는지

• ☐

  Backup/Backup Copy Job과 테스트 범위의 Restore가 정상인지

• ☐

  변경일, OS 버전, 커널 버전, 패치 로그를 운영 기록에 남겼는지

특히 Helper Appliance가 필요한 복구 기능은 실제 테스트하지 않으면 패치 후 동작을 확신하기 어렵습니다. 운영 데이터에 영향을 주지 않는 격리 환경에서 해당 복구 시나리오를 점검하는 편이 좋겠습니다.

9. 망분리 환경의 추가 확인 사항

VSA/VIA가 로컬 Repository Mirror를 사용하는 폐쇄망이라면 최신 수정 커널이 포함된 Repository 데이터가 내부 Mirror로 동기화됐는지 확인해야 합니다.

내부 Mirror가 오래된 상태라면 Updater에서 새 업데이트가 나타나지 않을 수 있습니다. 이때는 무작정 외부 인터넷으로 방화벽을 열기보다, 조직의 패치 반입 정책과 Veeam의 Mirror 동기화 절차를 확인하는 것이 우선입니다.

또한 Restart가 필요한 보안 커널 업데이트는 유지보수 시간에 실행하고, 작업 직전 Veeam Configuration Backup과 기존 Job 상태를 확인하는 편이 좋겠습니다.

정리

CVE-2026-98432의 핵심은 Linux 커널 취약점을 어떤 Veeam 구성요소가 실제로 사용하고 있는지 찾는 것입니다.

VSA/VIA는 Updater에서 수정 커널을 적용하고, Windows 기반 VBR 13.1의 Linux Helper는 전용 Private Fix를 적용합니다. 고객이 직접 구축한 Linux Repository·Proxy라면 OS 배포판의 커널 업데이트가 필요하고, Kasten의 경우 Kubernetes Node OS가 대응 대상입니다.

특히 VBR 12.3 Private Fix 제공 상태, 영구 배포된 Helper Appliance, 오래된 Linux Recovery Media는 놓치기 쉬운 부분입니다. 패치 여부를 확인할 때는 Backup Server Build만 보는 대신, 실제 복구 경로와 Helper까지 점검해두면 좋겠습니다.

공식 참고자료

• Veeam KB4966 — CVE-2026-98432 Impact Statement

• Veeam Help Center — Updating Veeam Appliances

• Veeam Help Center — Checking for Updates

• Veeam Help Center — Installing Updates

• Veeam Help Center — Viewing Update History

• Veeam Help Center — How Updates Work

• Red Hat RHSB-2026-016

• Ubuntu CVE-2026-98432 대응 공지

• Ubuntu CVE-2026-98432 상태

작성 기준: 2026년 11월 7일 / Veeam KB4966 게시일: 2026년 11월 6일. 공개 자료 기반 운영 가이드이며, 특정 운영 환경에서 실제 패치를 적용·검증한 테스트 결과가 아닙니다. Private Fix와 Linux 배포판의 제공 상태는 변경될 수 있으므로 적용 직전에 최신 공식 공지를 다시 확인해야 합니다.