CVE-2026-12411: LXD DevLXD 장치 패치로 열리는 게스트 간 볼륨 접근

같은 LXD 프로젝트 안의 게스트는 서로의 저장소 볼륨에서 떨어져 있다는 전제로 운영을 설계합니다. Canonical LXD의 DevLXD 장치 수정 처리기에 이 전제를 흔드는 접근 통제 결함이 보고됐습니다. CVE-2026-12411은 공유 프로젝트와 볼륨 관리 기능이라는 구성 조건에, CVE 레코드가 지정한 6.6 이상 6.9 미만 버전 범위가 겹치는 환경에서 게스트 간 교차 볼륨 접근을 가능하게 합니다.

개요

CVE-2026-12411은 Canonical LXD의 devLXDInstancePatchHandler 컴포넌트에 보고된 접근 통제 결함입니다. 신뢰하지 않는 게스트가 조작한 장치 PATCH 요청을 /dev/lxd로 보내면, 다른 게스트가 소유한 사용자 정의 스토리지 볼륨을 마운트하고 읽고 덮어쓸 수 있습니다. 이 경로는 프로젝트에서 security.devlxd.management.volumes가 활성화된 상태에서 열립니다. CVE 레코드는 영향 범위를 6.6 이상 6.9 미만으로, 해결책은 6.9 이상 업그레이드로 기재합니다. Canonical은 이 내용을 Cross-guest volume hijack via DevLXD device patch 권고와 CVE Program의 CVE-2026-12411 레코드에 정리했습니다.

권고문이 지목하는 공격자의 조건은 자기 인스턴스 범위로 한정된 일반 DevLXD 신원이고, 피해 게스트는 아무 동작도 하지 않습니다. 프로젝트 안의 게스트에서 코드를 실행할 수 있는 상황을 상정하면, 마지막 방어선은 높은 권한이 아니라 저장소 격리였던 셈입니다. 이번 결함은 그 격리가 실제로 성립하지 않았던 지점을 짚습니다.

영향 범위

• 신뢰하지 않는 게스트가 공유 LXD 프로젝트에서 실행되는 환경
• 그 프로젝트에서 security.devlxd.management.volumes가 활성화된 상태
• 공격에 사용하는 게스트가 자기 인스턴스 범위로 한정된 일반 DevLXD 신원을 가진 상태
• CVE 레코드가 기재한 버전 범위인 6.6 이상 6.9 미만, 해결책은 6.9 이상 업그레이드

CVE 레코드가 지정한 영향 버전 범위 안에서, 권고문이 제시한 두 구성 조건까지 함께 성립하면 같은 프로젝트의 다른 게스트가 소유한 사용자 정의 볼륨을 읽거나 덮어쓸 수 있습니다. 공격에 필요한 것은 자기 인스턴스 범위로 한정된 일반 DevLXD 신원뿐이고, 피해 게스트의 동작은 요구되지 않습니다. 버전 조건을 빼고 구성 조건만으로 성립한다고 보기는 어렵고, 반대로 버전이 영향 범위에 있어도 두 구성 조건이 갖춰지지 않으면 권고문이 기술한 이 공격 환경에 해당하지 않습니다.

권고문이 지목하는 영향 환경은 위 조건을 갖춘 공유 프로젝트입니다. 제공된 근거는 그 밖의 구성에서의 동작이나 별도 영향까지는 다루지 않습니다.

버전 측면에서는 CVE 레코드가 6.6 이상 6.9 미만을 영향 범위로, 6.9 이상 업그레이드를 해결책으로 명시합니다. 같은 구성이라도 영향 버전 범위에 남아 있는 배포와 이미 6.9 이상으로 올라간 배포에서 판단이 갈리는 지점입니다. 다만 각 배포의 패키지에 수정이 언제, 어떤 형태로 반영됐는지는 이번 근거로 확인되지 않으므로, 실제 적용 가능성은 각 배포의 공지에서 별도로 확인해야 합니다.

기술적 분석

장치 PATCH 요청에서 놓친 소유 관계

문제는 /dev/lxd로 들어오는 장치 수정 요청을 처리하는 devLXDInstancePatchHandler에 있습니다. 요청을 보낸 신원과 대상 볼륨의 소유자가 같은 게스트인지 가리는 통제가, 특히 장치를 추가하는 경로에서 작동하지 않았습니다.

수정 사항을 다룬 pull request는 그 격차의 이유를 설명합니다. 장치를 업데이트하거나 삭제할 때는 장치 소유권을 요청 신원과 비교할 수 있지만, 장치를 추가할 때는 비교에 쓸 장치 소유권을 이용할 수 없습니다. 그래서 이 경로에서는 확인 대상을 장치에서 기반 리소스로 바꿔, 기반 리소스의 소유권이 요청 신원과 일치하는지 살피는 방식으로 고쳤습니다 (Security fixes from the 6.9 release). 소유 확인을 요청 시점의 장치 정보가 아니라 실제 자원의 소속으로 옮겼다는 점이 핵심입니다.

읽기와 덮어쓰기가 함께 허용된다는 점도 파급 범위를 넓힙니다. 유출만으로 끝나지 않고, 피해 게스트가 그 볼륨에서 읽어들이는 내용의 신뢰성까지 흔들립니다. 다만 각 볼륨이 어떤 워크로드에 연결되고 무엇을 담는지까지 이번 근거는 다루지 않으므로, 실제 피해 크기는 배포 구성마다 다르다고 보는 편이 맞습니다.

공개 PoC·익스플로잇 분석

출처는 CVE Program의 CVE-2026-12411 레코드와 Canonical 보안 권고입니다. 두 자료는 같은 기법을 서술합니다. 자기 인스턴스 범위로 한정된 일반 DevLXD 신원을 가진 공격 게스트가 조작한 장치 PATCH 요청을 /dev/lxd로 보내 다른 게스트의 사용자 정의 볼륨을 마운트한다는 설명입니다. 권고문은 공격에 필요한 것이 그 일반 DevLXD 신원뿐이라고 명시하고, 피해자는 아무 동작도 하지 않는다고 덧붙입니다. 전달된 자료에는 Canonical이 공개한 권고에서 재현 가능한 PoC가 확인됐다는 점이 포함되지만, 그 재현 절차나 코드의 구체적 세부사항은 이번 인용에 들어 있지 않습니다.

전제조건은 기법이 동작할 환경과 공격자의 신원 조건에 함께 있습니다. 공유 LXD 프로젝트에 신뢰하지 않는 게스트가 들어가 있고, 그 프로젝트에서 security.devlxd.management.volumes가 켜져 있어야 합니다. 여기에 더해 공격에 나선 게스트가 자기 인스턴스 범위로 한정된 일반 DevLXD 신원을 가지고 있어야 하고, 필요한 자격도 그 신원뿐입니다. 반대로 피해 게스트의 조작이나 관여는 요구되지 않습니다. 따라서 점검할 때 프로젝트의 게스트 신뢰 상태와 볼륨 관리 기능 설정뿐 아니라 게스트에 부여된 DevLXD 신원 범위도 함께 봐야 합니다.

입증 범위도 확인된 것과 확인되지 않은 것이 갈립니다. 권고에서 재현 가능한 PoC가 확인됐다는 점은 자료로 뒷받침되지만, 실제 환경에서의 악용 사례는 제공된 근거에서 확인할 수 없습니다. 이 확인 실패가 악용이 없었다는 뜻은 아니며, 공개 PoC의 존재와 실제 악용 여부는 따로 봐야 할 별개의 사실입니다.

운영상 의미는 여기에서 나옵니다. 자기 인스턴스 범위의 일반 DevLXD 신원으로 가능하고 피해자 개입이 필요 없다는 점, 그리고 재현 가능한 PoC가 확인됐다는 점을 함께 보면, 공유 프로젝트에서 신뢰하지 않는 게스트를 실행 중이고 영향 버전 범위에 있는 환경은 게스트 간 교차 접근 위험으로 우선 검토하는 편이 합리적입니다. 구성 조건이 갖춰지지 않았거나 이미 6.9 이상으로 올라간 환경을 같은 우선순위로 다룰 근거는 이번 자료에 없습니다.

이번 근거로 확인하지 못한 것

• 배포별 패키지 패치 상태와 적용 방법은 확인되지 않았습니다. CVE 레코드가 지정한 6.6 이상 6.9 미만과 6.9 이상 업그레이드라는 범위와, 우리 배포에 실제로 적용 가능한 시점은 별개로 확인해야 합니다.
• 실제 환경에서의 악용 사례는 제공된 근거로 확인할 수 없습니다. 이것이 악용의 부재를 뜻하지는 않습니다.
• security.devlxd.management.volumes를 끄는 구체적 절차와 그로 인한 운영 부작용은 확인되지 않았습니다.
• 관련 장치 변경과 볼륨 접근을 추적할 수 있는 로그 위치나 탐지 규칙도 이번 근거로는 제시할 수 없습니다.

대응 방안

• 구성과 버전을 함께 확인합니다. 공유 LXD 프로젝트에 신뢰하지 않는 게스트가 돌아가고 있는지, 그 프로젝트에서 security.devlxd.management.volumes가 켜져 있는지 먼저 확인할 시점입니다. 여기에 실행 중인 LXD 버전이 CVE 레코드의 6.6 이상 6.9 미만 범위에 들어가는지를 겹쳐 봐야 합니다. 조건이 함께 성립하는 환경은 게스트 간 교차 접근 위험으로 우선순위를 올려 검토합니다.
• 6.9 이상 업그레이드를 해결책으로 둡니다. CVE 레코드는 6.9 이상 업그레이드를 해결책으로 기재합니다. 다만 배포별 패키지 반영 상태와 업그레이드 경로의 적용 가능성은 이번 근거로 확인되지 않았으므로, 각 배포의 공지를 확인해 변경 관리 절차에 따라 적용합니다.
• 수정이 들어간 경로인지 코드로 확인합니다. 장치 추가 경로에서 기반 리소스 소유권을 요청 신원과 대조하는 수정이 적용된 빌드인지 함께 확인합니다. 이 수정은 Security fixes from the 6.9 release pull request에 설명돼 있습니다.
• 기능의 필요성을 다시 봅니다. 구성 조건을 당장 걷어낼 수 없는 상황이라면, 공유 프로젝트에서 볼륨 관리 기능이 실제로 필요한지, 해제하면 어떤 운영 영향이 있는지 자체 점검합니다. 비활성화 절차와 부작용이 확인되지 않았으므로, 검증 없이 진행하지 않습니다.
• 관측 가능성을 점검합니다. 프로젝트 수준의 장치 변경 내역과 사용자 정의 볼륨 접근 기록을 조회할 수 있는지 살펴봅니다. 구체적인 로그 위치와 탐지 규칙은 이번 근거로 확정할 수 없으므로, 확인 전에는 탐지 절차로 단정하지 않습니다.

정리하면, 버전 확인과 구성 확인을 갈라서 할 필요는 없습니다. 6.6 이상 6.9 미만 범위에 있는지, 그리고 신뢰하지 않는 게스트가 있는 공유 프로젝트에서 볼륨 관리 기능이 켜져 있는지를 한 번에 판단하고, 남은 위험은 6.9 이상 업그레이드 등 공급자 수정과 배포별 적용 가능성 검토로 줄이는 흐름이 현재 근거에서 가장 합리적인 순서입니다. 재현 가능한 PoC가 확인된 상태이므로, 조건이 겹치는 환경이라면 확인 자체를 늦출 이유는 없습니다.

참고자료

• Cross-guest volume hijack via DevLXD device patch
• CVE-2026-12411: Broken Access Control in Canonical LXD DevLXD API
• Security fixes from the 6.9 release

함께 읽으면 좋은 글

• CVE-2026-122159: Audio8_TTS 모델 경로 해석의 경로 순회 취약점 점검
• banks CompletionExtension의 도구 호출 해석이 importlib에서 레지스트리로 바뀐 건 — 확인되는 사실과 유보되는 판단
• 앵커 없는 ACR 호스트 검증 — docker-credential-acr-env가 Azure AD 토큰을 공격자 호스트로 보내는 구조

본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.