광고
10월 27일 Veeam Backup for Microsoft 365 8.6 Patch 1이 공개됐습니다. Build는 8.6.0.5011입니다. Microsoft 365 백업을 운영 중이라면 이번 패치는 단순 유지보수 업데이트로 넘기기보다 한 번 확인해둘 필요가 있습니다.
REST API 인증 우회와 설치 과정의 권한 상승 취약점이 수정됐고, SharePoint·OneDrive·Teams 백업 데이터의 정합성을 확인하는 Integrity Check 관련 오류도 함께 개선됐습니다. 특히 이전 8.5 버전에서 정합성 점검을 진행했던 환경이라면 8.6 이후 다시 확인해야 하는 부분이 있습니다.
우선 확인: Veeam Backup for Microsoft 365 8.6 P1 = 8.6.0.5011. 이번 P1에서 CVE-2026-106078과 CVE-2025-64394가 수정됐습니다. 8.6.0.1102에서 먼저 수정된 CVE 두 건도 구분해서 확인해야 합니다.
8.6 P1에서 수정된 보안 취약점
CVE | 심각도 | 주요 내용 | 수정 Build |
|---|---|---|---|
CVE-2026-106078 | Medium 6.9 | 위조된 Federation Token을 이용한 일부 REST API 인증 우회 | 8.6.0.5011 |
CVE-2025-64394 | Medium 4.3 | 설치 과정에서 낮은 권한의 로컬 사용자가 SYSTEM 권한으로 임의 파일을 쓸 수 있는 문제 | 8.6.0.5011 |
CVE-2026-106078은 인증되지 않은 공격자가 위조한 Federation Token으로 REST API 인증을 우회할 수 있는 취약점입니다. 단, 공식 설명에 따르면 Veeam Backup for Microsoft 365 백업 서비스 자체를 호출하지 않는 REST API Endpoint의 응답을 받을 수 있는 문제입니다. 이를 무조건 백업 데이터 전체 탈취나 모든 관리 기능 장악으로 확대해서 해석하면 안 됩니다.
CVE-2025-64394는 제품 설치 과정의 파일 쓰기 권한 문제입니다. 낮은 권한의 로컬 사용자가 특정 조건에서 SYSTEM 권한으로 임의 파일을 기록할 수 있고, 권한 상승이나 서비스 거부로 이어질 수 있습니다. 네트워크에서 인증 없이 즉시 악용하는 종류의 취약점과는 공격 조건이 다릅니다.
두 취약점 모두 8.6.0.1102 및 그 이전 8.x Build가 영향 범위로 안내되어 있습니다. 지원이 종료된 더 오래된 버전은 동일하게 시험된 것은 아니므로 안전하다고 판단해서는 안 됩니다.
8.6 본 릴리스의 보안 수정과 혼동하지 않기
8.6 P1의 보안 수정은 두 건이지만, 그 직전 **8.6.0.1102(2026-09-14)**에서도 중요한 취약점 두 건이 수정됐습니다.
CVE | 심각도 | 주요 내용 | 수정 시작 버전 |
|---|---|---|---|
CVE-2026-106076 | Critical 9.0 | 인증된 Organization Transfer 상대가 구성 DB에 SQL을 주입하여 PostgreSQL 서비스 계정으로 코드 실행 가능 | 8.6.0.1102 |
CVE-2026-106077 | High 8.3 | Veeam Backup for Microsoft 365 Administrator 역할 사용자가 LocalSystem 권한으로 백업 서버의 임의 파일을 읽을 수 있는 문제 | 8.6.0.1102 |
이 두 건은 8.5.0.1014 및 그 이전 8.x가 영향받는 것으로 안내되어 있습니다. 따라서 아직 8.5에 머물러 있다면 단순히 P1의 두 CVE만이 아니라 8.6에서 수정된 Critical/High 문제까지 함께 고려해야 합니다.
공식 보안 수정 이력은 Veeam KB4957과 KB4962에서 버전별로 확인할 수 있습니다.
이번 P1에서 Repository 정합성 관련 수정이 중요한 이유
보안 패치 못지않게 운영에서 신경 쓸 부분이 Integrity Check와 Repair 과정입니다.
Veeam KB4835에는 SharePoint, OneDrive, Teams 파일 및 List Attachment의 백업 콘텐츠가 손상된 상태로 저장될 수 있는 문제가 안내되어 있습니다. 이 경우 백업 작업 자체가 성공한 것으로 보이더라도 실제 Restore 후 파일이 열리지 않을 수 있습니다.
이 문제와 관련해서 KB4874는 손상 가능성이 있는 파일을 찾고, 가능한 경우 원본 Microsoft 365에서 다시 다운로드하는 절차를 제공합니다. 8.6에서는 점검 범위가 JET 기반 Repository와 Immutable Repository까지 확대됐습니다.
이번 8.6 P1에서는 Integrity Check/Repair에서 발생하던 다음 문제들이 수정됐습니다.
정상적인 SharePoint 파일의 실제 콘텐츠가 HTML 오류 페이지로 보이는 경우, Repair 이후 손상 파일로 잘못 판정될 수 있던 문제
Object Storage에서 손상 파일이 예상 위치와 다른 곳에 있으면 Repair 후에도 정상 정리가 되지 않던 문제
SharePoint 백업 Job이 진행 중인 상황에서 Integrity Check를 실행하면 일부 업로드 파일의 데이터가 제거될 수 있던 문제
잘못 배치된 손상 파일이 Repair 로그에서 중복 또는 잘못 분류되던 문제
여기서 중요한 건 P1을 설치하는 것과 기존 Repository에 저장된 데이터의 정합성을 확인하는 것은 별도 작업이라는 점입니다. 업데이트를 마쳤다고 과거 모든 Restore Point가 정상이라는 사실이 자동으로 확인되지는 않습니다.
운영 주의사항: Integrity Check와 Repair는 대상 Repository의 작업량과 잠금 상태에 영향을 줄 수 있습니다. 특히 Repair 중에는 해당 Repository의 백업·복구·관리 작업이 제한되므로 유지보수 시간을 확보해야 합니다. Object Storage의 경우 API 호출 및 데이터 재다운로드로 추가 사용량이 발생할 수 있습니다.
8.5에서 이미 Integrity Check를 실행했다면?
공식 KB4874는 8.5로 Integrity Check를 실행했던 고객에게 8.6 이상으로 업그레이드한 후 관련 Repository마다 다시 점검하도록 권고합니다.
8.5에서는 손상된 파일을 식별·복구하는 절차가 Non-Immutable Object Storage Repository로 제한되어 있었습니다. 8.6부터는 Immutable Object Storage와 JET 기반 Repository도 점검/복구 범위에 들어갑니다.
따라서 과거 8.5 점검 기록이 있다고 해서 JET Repository와 Immutable Repository까지 확인했다고 볼 수는 없습니다. 현재 저장소 종류와 당시 점검 버전을 함께 기록해두는 것이 좋겠습니다.
광고
현재 버전과 Repository 확인
먼저 Veeam Backup for Microsoft 365 Console에서 Main Menu → About으로 Build를 확인할 수 있습니다. PowerShell Toolkit에서는 다음 명령도 사용할 수 있습니다.
Get-VBOVersion결과의 ProductVersion이 8.6.0.5011인지 확인합니다.
Repository 목록은 다음과 같이 조회할 수 있습니다.
Get-VBORepository특정 Repository의 정합성을 확인해야 한다면 공식 KB4874의 절차와 조건을 확인한 후 다음 명령으로 시작할 수 있습니다.
$repository = Get-VBORepository -Name "Repository Name"
Test-VBORepository -Repository $repository"Repository Name"은 실제 환경의 Repository 이름으로 바꿔야 합니다. 명령을 실행하기 전에 해당 Repository를 사용하는 백업·복구 작업의 상태, 보존 정책, 스토리지 API 비용과 작업 시간을 먼저 확인하는 편이 안전합니다.
Veeam Backup for Microsoft 365 Console에서 PowerShell Toolkit을 여는 예시 — 출처: Veeam Help Center. 이미지에 표시된 버전은 8.6 P1을 직접 촬영한 화면이 아닙니다.
위 이미지는 Console에서 PowerShell을 여는 위치를 보여주는 공식 예시입니다. 실제 정합성 점검 결과 화면은 아니며, 예시 명령을 그대로 실행했다고 주장하는 테스트 증적도 아닙니다.
손상된 파일이 발견됐다면 Repair를 바로 실행해도 될까요?
Test-VBORepository의 결과가 손상 가능성을 보여준다면 KB4874의 Repair 절차를 따릅니다. 다만 Repair는 스토리지 데이터를 변경하는 작업이기 때문에, 단순 점검 명령과 동일하게 취급하면 안 됩니다.
대상 Repository의 활성 백업·복구 작업을 중지하고, 작업 영향과 복구 가능성을 확인한 후 유지보수 창에서 진행하는 편이 좋겠습니다.
공식 가이드에서 사용하는 Repair Module은 다음과 같습니다.
Import-Module "C:\Program Files\Veeam\Backup365\Veeam.Archiver.PowerShell.dll"Object Storage Repository의 전체 SharePoint 사이트를 대상으로 하는 예시는 다음과 같습니다.
$repository = Get-VBORepository -Name "Repository Name"
$session = Start-VBORepositoryRepairSession `
-Repository $repository `
-Type CleanMissingFilesData `
-Mode Full `
-Scope Full
Get-VBORepositoryRepairSession -Id $session.Id이 명령은 실제 운영 Repository에 그대로 실행하도록 권하는 것이 아니라 공식 절차를 이해하기 위한 예시입니다. JET Repository는 -Scope Full 사용 여부 등 구문이 다르므로 KB4874에서 저장소 유형별 명령을 확인해야 합니다.
Repair가 완료된 후에는 영향받는 데이터가 포함된 백업 Job을 다시 수행해 Microsoft 365에 남아 있는 정상 콘텐츠를 재다운로드합니다. 이후 -DetailedOutput으로 결과를 확인할 수 있습니다.
Test-VBORepository -Repository $repository -DetailedOutput상세 로그의 기본 경로는 다음과 같습니다.
C:\ProgramData\Veeam\Backup365\Logs\IntegrityVerification\원본 Microsoft 365에서 이미 삭제됐거나 더 이상 접근할 수 없는 콘텐츠라면 자동으로 복구되지 않을 수 있습니다. 복구되지 않은 파일은 별도로 식별해야 합니다.
또 한 가지, 8.6 이상에서 실행한 Integrity Check를 통해 원본 Repository가 복구된 경우에는 Backup Copy의 다음 예정 실행에서 해당 수정 파일을 다시 복사하는 동작이 안내되어 있습니다. 하지만 8.5에서 점검한 이력을 그대로 활용하는 경우에는 별도 수동 Backup Copy가 필요할 수 있으므로 버전을 구분해야 합니다.
P1에서 함께 바뀐 운영 동작
이번 P1은 보안 문제만 수정한 것이 아닙니다. 특히 Microsoft 365 API의 응답 지연과 Throttling으로 백업이 흔들렸던 환경이라면 다음 개선 사항도 참고할 만합니다.
Exchange Online이 특정 Folder Export 요청에 응답하지 않을 때, 해당 Folder를 건너뛰고 Job을 Warning으로 완료하며 Restore Point를 남기는 처리 추가
Sync Issues폴더를 읽을 수 없어도 Mailbox 전체 백업이 실패하는 대신 해당 폴더를 건너뛰는 방식 개선병렬 Microsoft Graph / SharePoint 요청의 재시도 시간을 분산해 반복적인 Throttling을 줄이는 처리
Graph Throttling 이후 JET Repository 대상 SharePoint Backup이 실패하던 문제 개선
중단됐다 재개된 Retention 작업이 이미 처리한 항목을 다시 처리하지 않도록 개선
OneDrive 데이터 이동 및 수정 이력에 따라 Explorer에서 중복 Key 오류가 발생하던 문제 수정
특히 Warning으로 끝난 백업과 완전히 정상 처리된 백업은 같지 않습니다. 어떤 폴더가 건너뛰어졌는지, 다음 Incremental Backup에서 재시도됐는지 확인하고 필요한 경우 파일 단위 복구 가능성을 따로 점검해야 합니다.
8.6 P1 업데이트 전에 확인할 것
기존 8, 8.1, 8.2, 8.3, 8.4, 8.5 또는 8.6 배포에서 8.6 P1로 업그레이드할 수 있습니다. 신규 설치에도 8.6 P1 배포본을 사용할 수 있습니다.
다만 기존에 분리 설치한 구성요소가 있다면 업데이트 범위를 같이 확인해야 합니다.
현재 Console Build와 Veeam Backup for Microsoft 365 서버 Build를 확인합니다.
Configuration Database와 Repository 구성, Encryption Password 보관 상태, 사용 중인 Backup Proxy를 점검합니다.
Backup/Copy/Restore/Integrity Check 등 실행 중인 작업이 없는지 확인하고 유지보수 시간을 마련합니다.
별도 서버에 설치된 REST API 구성요소가 있다면 수동 업데이트 대상인지 확인합니다.
원격 Backup Proxy, Explorer, Backup Repository의 업데이트 상태를 확인합니다.
PostgreSQL과 NATS는 제품 업데이트 과정에서 자동으로 버전이 올라가지 않으므로 각 구성요소의 지원 버전과 별도 업그레이드 계획을 확인합니다.
Veeam Backup for Microsoft 365에서는 Main Menu의 Upgrade 항목에서 사용 가능한 업데이트를 확인할 수 있습니다. 자동 업데이트 정책을 사용하는 경우에도 모든 구성요소가 즉시 동일한 Build로 변경된다고 가정하지 않는 편이 좋습니다.
공식 가이드에 따르면 서버의 유휴 시간에 핵심 구성요소가 업데이트되고, 원격 Proxy는 별도 유지보수 시점에 업데이트될 수 있습니다. 작업이 계속 실행되는 환경에서는 자동 업데이트가 지연되고 수동 설치를 요청할 수 있습니다.
Microsoft Entra ID 권한도 같이 살펴보기
8.6 릴리스는 Exchange Online의 EWS Retirement 이후를 대비한 Microsoft Graph 권한 변경도 포함합니다. Microsoft 365 Organization을 추가하거나 편집할 때 필요한 Entra Application 권한을 자동 반영하는 동작이 안내되어 있습니다.
이는 8.6 P1만의 신규 기능이 아니라 8.6 본 릴리스의 변경 사항입니다. 기존 Organization의 인증 방식과 앱 권한이 그대로인 경우에는 필요한 권한이 이미 부여되어 있는지 별도로 확인해두는 편이 좋겠습니다.
업데이트 후 확인할 체크리스트
Veeam Backup for Microsoft 365의 Organization 및 Job 관리 화면 예시 — 출처: Veeam Help Center. 과거 버전의 예시 UI로, 실제 8.6 P1 패치 적용 결과 화면은 아닙니다.
- ☐
Get-VBOVersion또는 Console About에 8.6.0.5011이 표시되는지 - ☐
별도로 설치한 REST API와 원격 Proxy의 업데이트가 필요한지
- ☐
기존 Microsoft 365 Organization 연결과 Entra Application 권한에 문제가 없는지
- ☐
Exchange, SharePoint, OneDrive, Teams Backup 및 Backup Copy가 정상 수행되는지
- ☐
Backup Job의 Warning이 실제로 어떤 Folder/Item을 건너뛴 것인지 확인했는지
- ☐
Repository 유형별 Integrity Check 대상과 점검 이력을 정리했는지
- ☐
8.5에서 Integrity Check를 실행한 Repository는 8.6 이상으로 다시 확인할 계획이 있는지
- ☐
Repair가 필요하다면 Repository 사용 중지 시간 및 데이터 영향 범위를 검토했는지
- ☐
Restore Point만 확인하지 않고 중요 파일의 실제 복구/열기 여부까지 점검했는지
정리
이번 Veeam Backup for Microsoft 365 8.6 P1은 REST API 인증 우회와 설치 권한 상승 취약점을 수정하면서, Integrity Check와 Repository Repair의 실제 동작도 보완한 패치입니다.
운영 중이라면 Build 8.6.0.5011 적용 여부를 먼저 확인하고, SharePoint/OneDrive/Teams 파일 정합성 점검 이력도 함께 살펴보는 것이 좋겠습니다. 특히 8.5에서 점검을 마쳤다고 생각했던 Repository는 8.6의 확대된 검사 범위를 고려해야 합니다.
패치 설치만으로 과거 백업 데이터가 모두 정상이라는 사실이 보장되지는 않습니다. 버전 확인, 백업 Job 결과, Repository Integrity Check, 실제 Restore까지 연결해서 보는 편이 안전합니다.
공식 참고자료
제품 버전 기준: Veeam Backup for Microsoft 365 8.6 P1 (8.6.0.5011), 2026년 10월 27일 공개. 화면 이미지는 공식 가이드의 UI 예시이며 운영 환경에서 실제 수행한 테스트 결과는 아닙니다.
광고



