LXD·MicroCloud 인증 우회 취약점(CVSS 10), snap 패치 확인

오늘 회사 우분투 서버 PM 작업했는데 또?

LXD·MicroCloud가 원격 관리 접속자의 신원을 확인할 때, 접속자 본인의 인증서가 아니라 함께 제출된 다른 인증서까지 믿어 버리는 결함이다.[1] 공격자가 HTTPS 관리 API에 네트워크로 접근할 수 있고 이미 신뢰된 클라이언트의 공개 인증서를 확보했다면, 그 클라이언트의 개인키 없이도 신분을 사칭해 그 권한으로 원격 관리 API를 사용할 수 있다.[1] 그 결과 클러스터와 관리 중인 가상머신에 접근할 수 있고, 사칭한 사용자의 권한에 따라 호스트의 최고 관리자(root) 권한까지 얻을 수 있다.[1][3] MicroCloud에서는 클러스터에 새 멤버가 합류할 때 공개 TLS 인증서를 가로챈 뒤 그 멤버로 사칭할 수 있다.[1]

이번 CVE-2026-112816의 수정 snap은 이미 나왔다.[1] apt와 unattended-upgrades는 deb 패키지를 갱신하므로, 정기 점검에서 apt 패치를 마쳤어도 별도로 갱신되는 LXD snap의 패치 완료를 뜻하지는 않는다.[4][5] 설치된 snap의 채널과 실제 버전을 확인하고 해당 채널의 수정본을 적용해야 한다.[1]

먼저 볼 것: 아래 순서로 확인한다

• LXD·MicroCloud 설치 여부
• 추적 채널과 버전
• 해당 채널의 수정본
• 갱신 후 실제 설치 버전

무엇이 문제인가: 공개 인증서로 관리자를 사칭하는 인증 우회

LXD·MicroCloud의 상호 TLS(mTLS)는 접속한 클라이언트의 인증서와 키 소유 증명을 확인하는 절차다. 이번 결함은 신뢰할 클라이언트인지를 판단할 때, 실제 키 소유를 증명하는 말단(리프) 인증서가 아니라 클라이언트가 보낸 체인 안의 임의 인증서까지 신뢰 저장소와 대조한 데 있다. 그 결과 신뢰된 클라이언트의 공개 인증서가 체인에 들어 있으면 그 클라이언트로 인증될 수 있었고, 공격자는 그 클라이언트의 개인키 없이도 신원을 사칭할 수 있었다.[1]

다만 공격에는 HTTPS API에 네트워크로 도달할 수 있고, 이미 신뢰된 클라이언트의 공개 인증서를 확보했다는 조건이 붙는다. 사칭한 사용자의 권한에 따라 영향이 달라지며, Canonical은 호스트의 root 접근까지 가능할 수 있다고 설명한다. MicroCloud에서는 조인하는 클러스터 멤버의 공개 TLS 인증서를 가로챈 뒤 그 멤버로 인증할 수 있다고 밝혔다.[1]

LXD 문서상 기본 구성은 로컬 Unix 소켓을 사용하며 네트워크에 노출되지 않는다. 따라서 Ubuntu를 쓴다는 이유만으로 모두 같은 노출 상태라고 말할 수 없다. 원격 API를 사용하거나 MicroCloud를 운영하는 환경은 설치 상태와 접근 경로를 우선 점검할 필요가 있다. 기본값 설명을 실제 운영 서버의 설정 확인 대신 사용해서도 안 된다.[6]

NVD에 수록된 Ubuntu CNA 제공 점수는 CVSS 4.0 10.0, Critical이다. 반면 Ubuntu CVE 트래커의 우선순위는 medium으로 표시된다. 서로 다른 분류이므로 medium을 근거로 점수를 낮춰 읽거나, 반대로 10.0을 실제 공격 발생의 증거로 읽으면 안 된다.[2][3]

apt 보안 업데이트를 했는데 왜 LXD를 다시 봐야 하나?

패키지 관리 경로가 다르기 때문이다. Ubuntu의 unattended-upgrades는 APT 저장소와 deb 패키지를 대상으로 동작한다. LXD 문서는 snap 패키지 관리를 권장하며, 이번 Canonical 공지도 수정 snap과 snap 갱신 명령을 안내한다. apt 작업의 성공이나 자동 보안 업데이트 로그만으로 LXD snap의 수정 여부를 확인할 수는 없다.[1][4][5]

snap도 기본적으로 추적 중인 채널에 새 버전이 나오면 자동으로 갱신된다. 그렇다고 자동 갱신을 켜 두었다는 사실이 곧 이번 수정본의 설치 증거가 되지는 않는다. hold나 갱신 일정이 설정되어 있을 수 있고, 이번 LXD 수정본은 공지상 candidate에서 stable로 점진 배포 중이다. 자동 갱신 설정과 실제 설치 버전을 구분해야 한다.[1][4]

Ubuntu CVE API의 USN 목록이 비어 있고 archive의 lxd 패키지가 일부 릴리스에서 DNE로 표시되는 것도 snap 설치본이 안전하다는 뜻은 아니다. 확인할 대상은 배포판 패키지 표만이 아니라 그 서버에 설치한 LXD snap이다.[2]

10월 30일 다룬 CVE-2026-98432의 커널·apt 점검과 달리, 이번 글의 대상은 이미 수정본이 배포된 snap LXD와 채널별 적용 상태다.

설치 여부와 추적 채널은 어떻게 확인하나?

먼저 각 서버에서 설치된 snap의 버전과 Tracking을 확인한다. 아래는 LXD 공식 snap 관리 문서의 조회 명령이다.[4]

snap list lxd
snap info lxd

MicroCloud를 사용하는 호스트에서는 같은 snap 조회 방식으로 설치 여부와 버전을 확인한다. 설치되지 않았다는 응답과 정상 설치 출력을 구분한다.[4]

snap list microcloud

기록할 항목은 제품명, Version, Rev, Tracking이다. Version은 수정 릴리스와 비교하고, Tracking은 어느 채널의 수정본을 적용해야 하는지 판단하는 데 쓴다. 숫자가 더 커 보이는 다른 트랙으로 무작정 옮기는 작업과, 현재 채널 안에서 보안 수정본을 받는 작업은 다르다.[4]

LXD 클라이언트와 서버 버전도 확인할 수 있다. 원격 대상을 사용하는 환경이라면 어느 서버에 대한 출력인지 함께 확인한다.[9]

lxc version

어느 버전으로 바뀌어야 하나?

아래는 Canonical 공지에 명시된 수정 snap이다. 표의 배포일은 모두 2026-10-29이며, 다른 채널의 수정 버전을 이 표에서 추정하지 않는다.[1]

설치 버전은 해당 트랙의 수정 릴리스와 대조한다. 예를 들어 5.21/stable을 추적한다면 비교 기준은 5.21.9다. 버전 문자열에 추가 식별자가 붙어 있으면 앞부분의 LXD 릴리스를 확인하고, Rev도 함께 남긴다. LXD 문서 역시 버전 문자열 앞부분이 LXD 릴리스에 해당한다고 설명한다.[4]

latest나 표에 없는 트랙을 사용 중이라면 위 숫자를 그대로 적용해 안전 여부를 단정하지 않는다. 해당 채널의 공식 릴리스 안내를 추가로 확인해야 한다.

공지의 작성 시각은 2026년 10월 28일 UTC, 한국 시각으로는 10월 29일 새벽이다. NVD 공개일은 10월 30일 UTC로, 한국에서는 10월 31일 새벽에 해당한다. 뉴스가 나온 날과 수정 snap 배포일이 다르다는 점도 구분해 두자.[1][3]

실제 업데이트는 어떻게 적용하나?

현재 추적 채널 안에서 최신 버전으로 갱신하는 것이 기본이다. 운영 변경 절차에 따라 영향과 작업 시간을 확인한 뒤 적용한다. Canonical 보안 공지와 LXD 문서가 안내하는 명령은 다음과 같다.[1][4]

sudo snap refresh lxd

MicroCloud 설치본도 해당 호스트에서 갱신한다. MicroCloud를 쓰는 환경은 제품 하나만 확인하고 끝내지 말고, 설치된 LXD와 MicroCloud 각각의 상태를 대조한다.[1]

sudo snap refresh microcloud

갱신 명령이 끝났으면 조회를 다시 실행한다. 명령 실행 완료와 수정 버전 도달은 별도로 확인한다.[1][4][9]

snap list lxd
snap list microcloud
lxc version

stable의 점진 배포로 원하는 수정본에 아직 도달하지 못했다면 그 호스트의 조치가 끝났다고 기록하지 않는다. 현재 채널, 실제 설치 버전, 갱신 결과를 남기고 후속 공지와 배포 상태를 확인한다. 이 글은 모든 운영 서버를 candidate로 바꾸라고 권하지 않는다. 채널 전환은 별도의 변경 판단이며, 현재 채널의 보안 업데이트와 같은 작업으로 취급하면 안 된다.[1][4]

API 노출과 클러스터는 무엇을 더 확인하나?

노출 점검과 멤버별 버전 확인을 추가한다. 일반적인 LXD 서버 설정 조회 문법과 네트워크 노출 문서에 따라 HTTPS 주소 설정을 확인할 수 있다.[6][10]

lxc config get core.https_address

값이 있다면 주소와 실제 접근 허용 범위가 운영 의도와 맞는지 살펴본다. 값 하나만으로 전체 네트워크 경로의 안전을 판정하지 말고, 클러스터나 원격 관리 구성을 함께 확인한다. 이는 일반적인 노출 점검이며, Canonical이 이 CVE의 공식 workaround로 주소 해제나 API 차단을 권고했다는 뜻은 아니다. 공지의 조치는 snap 업데이트이고, 노출 점검은 패치를 대신하지 않는다.[1][2][6]

LXD 클러스터라면 한 멤버의 출력만 보고 종료하지 않는다. 공식 문서는 모든 멤버가 같은 LXD 버전을 사용해야 하며, 가능하면 snap revision도 같게 맞추라고 안내한다. 갱신을 동기화하는 cohort 설정도 제공한다. 처음 설정하는 멤버의 수동 갱신 명령은 다음과 같다.[4]

sudo snap refresh lxd --cohort="+"

cohort를 이미 설정한 snap은 이후 갱신에도 이를 사용하므로 매번 붙일 필요는 없다. 멤버별 설치 버전과 revision을 기록하고, 모든 멤버가 목표 상태에 도달했는지 확인한다. 이 명령 하나가 클러스터 전체를 한 번에 패치하는 것은 아니다.[4]

알려진 악용이 없다면 다음 PM까지 기다려도 되나?

악용 보고가 없다는 이유만으로 수정본 적용을 미룰 근거는 되지 않는다. 다만 이미 공격이 벌어지고 있다고 과장할 이유도 없다.

2026년 11월 1일 21:33 KST 재확인 기준으로 CISA KEV에는 이 CVE가 없고, NVD의 CISA SSVC 평가도 10월 30일자 exploitation: none이다. 11월 1일자 The Hacker News는 알려진 공격 징후와 공개된 작동 익스플로잇이 없다고 보도했다. 현재 알려진 악용·작동 PoC는 없다는 범위로 읽어야 한다.[3][7][8]

KEV 미등재는 공격 불가능의 보증이 아니다. 우선순위는 실제 API 접근 범위와 운영 환경에 맞춰 정하되, Canonical이 안내한 수정본 적용과 적용 후 확인까지 마치는 것이 이번 조치의 핵심이다.[1]

PM 기록에는 apt 완료 여부 옆에 snap 제품명·추적 채널·갱신 후 버전·revision·클러스터 멤버별 확인 결과를 따로 남겨 두면 좋다. 이번 건의 종료 기준은 “Ubuntu 업데이트를 돌렸다”가 아니라 “해당 채널의 LXD·MicroCloud 수정본이 실제로 설치되었다”다.

출처