Kubernetes 2026년 9월 CVE 대응: 권한과 플랫폼으로 패치 우선순위 정하기

Kubernetes 보안 공지가 나오면 가장 먼저 보이는 것은 CVE 번호와 점수다. 그러나 실제 대응 순서는 점수만으로 정할 수 없다. 어떤 구성 요소가 취약한지, 공격자가 이미 어떤 권한을 가져야 하는지, 특정 운영체제나 기능이 필요한지, 그리고 공격이 성립했을 때 어느 신뢰 경계가 넘어가는지를 함께 봐야 한다.

2026년 9월 23일 Kubernetes Security Response Committee는 서로 다른 두 취약점을 공개했다. CVE-2026-2270은 StatefulSet controller의 confused-deputy 문제이며, CVE-2026-76654는 Windows node에서 subPath symlink가 공격자 통제 UNC share를 가리킬 때 발생하는 NTLM coercion 문제다.[10][11] 두 공지는 모두 Medium으로 평가됐고 고정 patch version도 같지만, 취약한 구성 요소와 공격 전제, 조사할 증거, 업그레이드 대상은 다르다.[10][11]

이 글의 목표는 두 CVE를 하나의 “Kubernetes 긴급 패치”로 뭉뚱그리지 않는 것이다. 영향 버전과 fixed version을 원문 그대로 기록한 뒤, 노출 여부를 권한과 플랫폼으로 판정하고, 탐지와 완화, 업그레이드 이후 검증을 분리한다. 공식 공지가 제공하지 않은 피해 규모나 악용 현황은 추정하지 않는다.

먼저 결론: 같은 fixed version, 다른 노출 조건

두 취약점의 version boundary는 같지만 패치할 binary가 다르다.

첫 번째 취약점은 Linux 또는 Windows worker라는 구분보다 controller와 Kubernetes API 권한 경계를 먼저 봐야 한다. 두 번째 취약점은 Windows node라는 플랫폼 조건이 명시돼 있으므로 Linux-only cluster에는 같은 공격 경로가 적용되지 않는다.[10][11]

따라서 패치 우선순위도 한 줄짜리 cluster version 목록으로 끝나지 않는다. kube-controller-manager가 영향 버전인지, Windows kubelet이 존재하는지, 해당 권한과 기능이 누구에게 열려 있는지를 별도 자산으로 계산해야 한다.

영향 버전과 fixed version을 branch별로 읽는다

두 공지가 제시한 영향 범위는 다음과 같다.[10][11]

표의 >=는 각 maintenance line 안에서 읽어야 한다. 예를 들어 1.35 계열 운영자는 1.35.9 이상 patch release를 목표로 삼고, 1.36 계열 운영자는 1.36.5 이상을 목표로 삼는다. 서로 다른 minor line의 숫자를 하나의 전역 비교식처럼 해석해 “1.35.9가 1.34.12보다 최신이므로 모든 조건을 만족한다”는 식으로 inventory를 만들면 변경 범위와 지원 정책을 혼동하게 된다.

CVE-2026-2270에서 확인할 대상은 control plane의 kube-controller-manager다. worker node의 kubelet version만 확인해서는 이 CVE의 patch 상태를 증명할 수 없다.[10] 반대로 CVE-2026-76654의 대상은 Windows node의 kubelet이다. API server나 controller manager만 올리고 Windows kubelet을 남겨 두면 이 CVE의 공식 mitigation을 적용한 것이 아니다.[11]

관리형 Kubernetes를 사용한다면 control plane version 표기와 실제 보안 fix 적용 상태를 공급자에게 확인할 필요가 있다. 다만 이 글의 두 원문 공지는 공급자별 backport나 별도의 build identifier를 설명하지 않는다. 그러므로 공급자 고유 버전이 표의 upstream patch number와 다를 때는 “비슷해 보인다”는 이유로 fixed라고 판정하지 말고, 해당 공급자가 어느 fix를 포함했다고 보증하는지 별도로 확인해야 한다.

CVE-2026-2270: StatefulSet controller가 namespace 경계를 넘는 경로

공지가 말하는 취약점

CVE-2026-2270은 StatefulSet controller의 confused-deputy 취약점이다. 한 namespace에서 StatefulSet과 ControllerRevision 객체에 write permission을 가진 사용자가 cross-namespace Pod를 만들 수 있다.[10] 공격자는 만들어지는 Pod의 metadata와 specification을 제어할 수 있으며 namespace도 선택할 수 있다.[10]

여기서 “StatefulSet을 사용할 수 있다”는 표현은 너무 넓다. 공지가 명시한 전제는 StatefulSet뿐 아니라 ControllerRevision 객체에도 namespace-scoped write permission이 있다는 것이다.[10] read 권한만 있는 사용자, StatefulSet write만 있고 ControllerRevision write는 없는 사용자, 두 객체를 모두 쓸 수 있지만 신뢰된 자동화 identity만 존재하는 환경은 같은 노출도로 분류하면 안 된다.

취약점의 핵심은 공격자가 직접 target namespace에 Pod create 권한을 받았다는 데 있지 않다. 제한된 namespace의 객체를 조작하고 StatefulSet controller가 가진 권한을 대리 경로로 이용해 다른 namespace에 Pod를 생성하게 만드는 데 있다. 그래서 RBAC review에서 target namespace의 직접 Pod create 권한만 찾으면 중요한 전제를 놓친다.

공격이 성립하고 유지되는 조건을 나눈다

공격 경로에는 적어도 다음 조건이 필요하다.

1. 공격 주체가 어떤 namespace에서 StatefulSet 객체를 쓸 수 있다.
2. 같은 공격 주체가 그 namespace에서 ControllerRevision 객체도 쓸 수 있다.
3. 취약한 kube-controller-manager가 해당 객체를 처리한다.
4. 조작 결과가 victim namespace를 선택하는 Pod metadata와 specification으로 이어진다.
5. 생성된 cross-namespace Pod를 즉시 삭제되지 않게 유지하려면 victim namespace에 이미 존재하는 StatefulSet의 UID를 참조해 유효한 StatefulSet OwnerReference를 구성해야 한다.[10]

마지막 조건은 특히 정확히 읽어야 한다. 공지는 유효한 OwnerReference가 없으면 cross-namespace Pod가 garbage collector에 의해 즉시 삭제된다고 설명한다.[10] 이것은 취약점이 무해하다는 뜻이 아니다. “Pod가 생성될 수 있는가”와 “그 Pod가 계속 남는가”는 다른 판정이다. 대응팀은 장시간 Running 상태인 이상한 Pod만 찾지 말고 짧게 생성됐다 삭제되는 흔적도 조사 범위에 포함해야 한다.

반대로 유지 조건을 공격 전제 전체와 섞어서도 안 된다. victim namespace의 StatefulSet UID를 참조하는 것은 생성된 Pod가 garbage collection을 피하기 위한 조건이다.[10] UID를 확보하지 못하면 어떠한 cross-namespace 생성 시도도 없었다고 단정할 근거는 되지 않는다.

노출 판정

다음 순서로 cluster를 분류하면 단순 version scan보다 대응 범위가 선명해진다.

1단계: controller version kube-controller-manager가 공지의 affected range에 있으면 다음 단계로 간다. fixed range라면 version 증거를 남기고 사후 검증 대상으로 분류한다.

2단계: 결합된 write permission 사용자, 그룹, service account, 자동화 도구 가운데 같은 namespace에서 StatefulSet과 ControllerRevision을 모두 쓸 수 있는 주체를 찾는다. role 이름이나 직무명으로 추정하지 말고 실제 적용 권한을 기준으로 확인한다.

3단계: 신뢰 수준 그 권한이 제한된 platform controller에만 있는지, 일반 개발자·CI job·namespace 관리자에게도 위임됐는지 구분한다. 이미 넓게 배포된 credential이나 외부 입력을 처리하는 자동화 identity가 권한을 가졌다면 조사 우선순위를 높인다.

4단계: victim UID 접근 가능성 공격 주체가 다른 namespace의 StatefulSet UID를 얻거나 추측이 아닌 실제 값으로 참조할 수 있는 경로가 있었는지 확인한다. 다만 이 단계는 지속 가능한 Pod의 전제이며, 앞선 세 단계의 노출을 없애 주는 조건으로 사용하지 않는다.

5단계: 생성 흔적 ControllerRevision과 StatefulSet 변경, controller가 만든 cross-namespace Pod, OwnerReference, 빠른 garbage collection을 시간 순서로 연결해 조사한다.

detection: 공식 IOC와 운영 가설을 구분한다

공지는 제품별 탐지 query, log signature, 알려진 악성 값, exploitation indicator를 제공하지 않는다.[10] 따라서 특정 query 하나를 “공식 탐지법”이라고 소개해서는 안 된다. 실무 탐지는 취약점의 전제를 inventory와 audit evidence로 역산하는 방식이 된다.

우선 사전 탐지는 다음 질문에 답해야 한다.

• affected kube-controller-manager가 어느 control plane에 남아 있는가.
• StatefulSet과 ControllerRevision write permission이 함께 부여된 주체는 누구인가.
• 그 권한은 어느 namespace에 적용되는가.
• 해당 identity의 credential이 사람, CI, operator 중 어디에서 사용되는가.
• 권한이 최근 확대됐거나 예상보다 넓게 binding된 곳이 있는가.

사후 조사는 단일 이벤트보다 연쇄를 본다.

• StatefulSet 또는 ControllerRevision의 비정상적인 생성·갱신이 있었는가.
• 그 직후 다른 namespace에 예상하지 않은 Pod 생성이 있었는가.
• Pod의 spec과 metadata가 정상 StatefulSet rollout에서 기대한 값과 다른가.
• OwnerReference가 실제 victim namespace StatefulSet UID를 가리키는가.
• 생성 직후 garbage collection된 Pod나 반복된 생성 시도가 있는가.

이 목록은 공지가 제공한 IOC가 아니라 공지에 적힌 공격 전제에서 도출한 조사 가설이다. 로그 보존 범위나 audit 설정에 따라 확인할 수 없는 항목이 있을 수 있다. 확인 불가를 “이상 없음”으로 바꾸지 말고 evidence gap으로 기록해야 한다.

CVE-2026-76654: Windows kubelet의 UNC symlink와 NTLM coercion

공지가 말하는 취약점

CVE-2026-76654는 Windows node에서 Pod의 volumeMounts.subPath가 공격자 통제 network share를 가리키는 symbolic link로 설정됐을 때 발생한다.[11] kubelet이 symlink를 resolve하는 과정에서 UNC path로 해석된 target을 거부하지 않고, 해당 share에 NTLM 인증을 시도한다.[11]

그 결과 공격자는 kubelet이 실행되는 account의 NetNTLMv2 hash를 얻을 수 있다.[11] 공지는 공격자가 그 hash를 crack해 대응 password를 얻으려 시도하거나, node가 domain-joined인 경우 relay해 node를 impersonate하려 시도할 수 있다고 설명한다.[11]

여기서 세 가지를 구분해야 한다.

• symlink가 존재한다는 사실
• kubelet이 공격자 share에 NTLM 인증을 시도했다는 사실
• 확보한 hash의 cracking 또는 relay가 성공했다는 사실

앞 단계가 관찰됐다고 뒤 단계의 성공까지 자동으로 입증되는 것은 아니다. 반대로 최종 계정 악용 증거가 없다고 outbound 인증 시도 자체를 무시해서도 안 된다. 조사 보고서는 “구성이 가능했다”, “인증 시도가 확인됐다”, “hash가 노출됐을 수 있다”, “후속 악용이 확인됐다”를 서로 다른 증거 수준으로 기록해야 한다.

공격 전제

이 CVE는 다음 조건이 겹칠 때 우선 조사 대상이 된다.

1. cluster에 Windows node가 있다.
2. 그 node의 kubelet이 affected version이다.
3. 공격자가 Pod volume mount의 subPath 경로를 이용할 수 있다.
4. 그 subPath가 symbolic link이며 공격자가 통제하는 UNC network share로 resolve된다.
5. kubelet이 그 target을 resolve하면서 NTLM 인증을 시도한다.[11]

relay를 이용한 node impersonation 위험을 평가할 때는 Windows node의 domain join 여부를 추가로 확인한다. 공지는 domain-joined node를 relay 조건과 연결한다.[11] 따라서 Windows node가 없으면 이 공지의 명시된 플랫폼 조건에 해당하지 않고, Windows node는 있지만 domain에 가입하지 않은 경우에도 공지가 설명한 relay 시나리오와 hash cracking 시나리오를 분리해 기록해야 한다.

노출 판정

1단계: OS inventory 전체 node를 Linux와 Windows로 나눈다. Linux node 수가 많다는 이유로 Windows pool 몇 대를 inventory에서 놓치지 않는다.

2단계: kubelet version 각 Windows node의 kubelet을 branch별 affected/fixed boundary와 비교한다. control plane version을 Windows node patch 상태의 대용으로 쓰지 않는다.

3단계: domain join Windows node가 domain-joined인지 확인해 공지가 설명한 relay 경로의 조건을 별도로 표시한다.[11]

4단계: workload capability 어떤 사용자와 controller가 Windows node에 배치될 Pod의 volume과 subPath를 결정할 수 있는지 확인한다. 단순히 namespace 접근 권한이 있는지보다 실제 workload spec을 만들거나 바꿀 수 있는 경로를 본다.

5단계: network reachability와 evidence Windows node에서 공격자 통제 share로 이어질 수 있는 경로와 과거 인증 시도 흔적을 조사한다. 이 단계는 취약한 version을 fixed로 바꾸는 작업을 대신하지 않으며, 조사 범위를 정하는 데 사용한다.

detection: share 접근과 후속 악용을 분리한다

이 공지도 공식 IOC나 특정 Windows event ID, 탐지 query를 제공하지 않는다.[11] 따라서 환경에 맞는 Windows, network, identity telemetry를 사용하되 어떤 사실을 증명하는 신호인지 구분해야 한다.

조사 질문은 다음처럼 구성할 수 있다.

• affected Windows kubelet이 어느 node에 남아 있었는가.
• 해당 node로 스케줄된 Pod 중 subPath를 사용한 workload는 무엇인가.
• 관련 경로가 symlink였고 UNC target으로 resolve될 수 있었는가.
• Windows node에서 승인되지 않은 network share로 연결 또는 인증 시도가 있었는가.
• kubelet 실행 account와 연결된 비정상 인증, relay 의심, 계정 사용 흔적이 있었는가.
• 의심 시점 이후 같은 identity가 다른 시스템에서 사용됐는가.

subPath 사용만으로 exploitation을 선언해서는 안 된다. Windows라는 플랫폼, symlink, attacker-controlled UNC target, kubelet의 인증 시도가 함께 연결돼야 공지가 설명한 경로에 가까워진다.[11] 반대로 outbound share 접근 기록이 없더라도 telemetry가 수집되지 않았거나 보존 기간이 짧다면 “악용되지 않음”을 증명한 것이 아니다.

mitigation과 detection은 서로 대체하지 않는다

두 공지가 제시한 공식 mitigation은 fixed version으로 업그레이드하는 것이다.[10][11] CVE-2026-2270의 fix는 StatefulSet에서 spec field만 ControllerRevision으로부터 복원되도록 변경한다.[10] CVE-2026-76654의 fix는 Windows에서 UNC symlink target을 kubelet이 거부하도록 변경한다.[11]

공식 mitigation을 구성 요소별로 쓰면 다음과 같다.

• CVE-2026-2270: kube-controller-manager를 1.34.12, 1.35.9, 1.36.5, 1.37.1 또는 해당 branch의 그 이상 fixed version으로 업그레이드한다.[10]
• CVE-2026-76654: Windows node의 kubelet을 1.34.12, 1.35.9, 1.36.5, 1.37.1 또는 해당 branch의 그 이상 fixed version으로 업그레이드한다.[11]

패치 전 임시 통제는 “공식 fix와 동등한 우회책”이 아니라 공격 전제를 줄이는 보상 통제로 취급해야 한다. 예를 들어 첫 번째 CVE에서는 불필요한 StatefulSet·ControllerRevision 결합 write permission을 제거하거나 신뢰된 identity로 제한할 수 있다. 두 번째 CVE에서는 영향을 받는 Windows workload의 subPath 사용과 untrusted network share 접근 경로를 제한할 수 있다. 그러나 두 공지는 이런 통제를 완전한 mitigation으로 보증하지 않으며, 공식 권고는 업그레이드다.[10][11]

탐지도 패치를 대신하지 않는다. 의심 이벤트가 발견되지 않았다는 결과는 취약한 binary가 fixed가 됐다는 뜻이 아니다. 반대로 patch 완료는 과거 노출 기간의 조사 필요성을 없애지 않는다. 대응 작업을 다음 세 트랙으로 분리해야 한다.

1. Exposure: affected component, 권한, 플랫폼, 기능 사용 여부를 판정한다.
2. Remediation: fixed version으로 업그레이드하고 실제 binary version을 검증한다.
3. Investigation: patch 이전 기간에 공격 전제와 일치하는 이벤트가 있었는지 확인한다.

업그레이드 우선순위: 점수가 아니라 전제의 교집합으로 정한다

두 CVE 모두 Medium이지만 모든 cluster를 같은 순서로 처리해야 한다는 뜻은 아니다. 공지의 severity는 그대로 유지하고, 내부 변경 순서는 환경별 노출 전제로 정한다.

우선순위 1: 공격 전제가 실제로 열려 있는 affected 환경

다음 환경은 먼저 처리한다.

• affected controller를 사용하며 일반 사용자, namespace 관리자, CI 또는 외부 입력을 받는 자동화가 StatefulSet과 ControllerRevision을 모두 쓸 수 있는 cluster
• affected Windows kubelet이 있고, workload 작성자가 subPath를 통제할 수 있으며, 공격자 통제 UNC share로 이어질 가능성을 배제하지 못한 cluster
• affected Windows node가 domain-joined라서 공지가 설명한 relay 기반 node impersonation 조건까지 겹치는 cluster[11]
• 위 조건에 해당하면서 audit, Windows, network telemetry가 부족해 과거 노출을 충분히 판정할 수 없는 환경

마지막 항목은 “침해됐다”는 뜻이 아니다. 관측 공백 때문에 위험을 낮게 증명할 수 없으므로 patch와 증거 보존을 먼저 진행한다는 운영 원칙이다.

우선순위 2: affected version이지만 일부 전제가 제한된 환경

예를 들면 affected controller가 있으나 두 객체의 결합 write 권한이 강하게 제한된 cluster, 또는 affected Windows node가 있으나 domain-joined가 아니고 subPath workload와 network path가 제한된 환경이다. 이런 조건은 상대적 순서를 조정할 근거가 될 수 있지만 patch 면제 근거로 사용해서는 안 된다.

권한과 구성은 바뀐다. 오늘은 신뢰된 controller만 가진 permission이 내일 새로운 CI service account에 복제될 수 있고, 사용하지 않던 Windows pool이나 subPath가 추가될 수 있다. fixed version으로 옮기지 않으면 exposure 판정을 계속 최신 상태로 유지해야 하는 운영 부채가 남는다.

우선순위 3: fixed version으로 확인된 환경

fixed version이라도 확인 작업은 남는다. controller와 Windows kubelet이 실제 대상 version으로 실행되는지, 일부 node나 control-plane replica가 이전 binary에 남지 않았는지, 업그레이드 후 기본 기능이 정상인지 검증한다. version 관리 시스템의 desired state만 보지 말고 running state를 확인한다.

변경 순서: control plane과 Windows node를 별도 작업으로 관리한다

fixed version 번호가 같다는 이유로 두 CVE를 하나의 upgrade task로 합치면 누락이 생기기 쉽다. 변경 티켓과 완료 증거를 최소 두 갈래로 나눈다.

Track A: kube-controller-manager

1. 모든 cluster의 controller maintenance line과 patch version을 수집한다.
2. affected cluster에서 StatefulSet·ControllerRevision 결합 write 권한을 inventory한다.
3. audit와 객체 변경 기록을 보존한 뒤 control plane upgrade를 수행한다.
4. 모든 controller replica가 fixed build를 실행하는지 확인한다.
5. 정상 StatefulSet 생성, update, rollback 경로가 운영 기준대로 동작하는지 확인한다.
6. patch 전 노출 기간의 의심 객체와 cross-namespace Pod 흔적 조사를 마친다.

Track B: Windows kubelet

1. Windows node와 node pool을 전부 찾고 kubelet version을 수집한다.
2. domain join, subPath 사용 workload, network share 접근 경로를 분류한다.
3. 관련 로그를 보존하고 drain·교체·upgrade 순서를 정한다.
4. Windows kubelet을 fixed version으로 올린다.
5. 모든 Windows node의 running version을 다시 수집한다.
6. 정상 volume mount는 유지되고 UNC symlink target은 거부되는지 검증한다.
7. patch 전 의심 share 접근과 identity 사용 흔적을 조사한다.

이 순서는 특정 배포판의 명령을 전제로 하지 않는다. self-managed cluster, managed service, immutable node image에 따라 실행 방법은 다르지만 완료 증거는 같아야 한다. 대상 구성 요소가 fixed code를 실제로 실행하고 있고, 정상 기능과 차단해야 할 경로를 각각 확인해야 한다.

post-upgrade verification: version 확인만으로 끝내지 않는다

CVE-2026-2270 검증

먼저 모든 kube-controller-manager instance가 목표 patch version인지 확인한다. 그다음 정상 StatefulSet workflow가 계속 동작하는지 확인한다. 공지는 fixed version이 ControllerRevision에서 StatefulSet으로 복원하는 범위를 spec field로 제한한다고 설명한다.[10] 따라서 조직의 정상 rollout과 rollback 검증을 수행하되, metadata나 namespace를 넘어서는 cross-namespace Pod 생성 경로가 차단되는지도 별도 security regression으로 확인해야 한다.

재현 시험은 production namespace와 실제 민감 service account로 수행하지 않는다. 격리된 test cluster 또는 안전한 test namespace에서 승인된 절차로 실행하고, 생성·거부·garbage collection의 결과를 기록한다. 시험 때문에 만든 객체와 권한은 검증 후 제거한다.

CVE-2026-76654 검증

모든 Windows node에서 kubelet running version을 확인한다. 공지는 fixed kubelet이 Windows에서 UNC symlink target을 거부하도록 바뀌었다고 설명한다.[11] 따라서 정상적인 volume과 subPath workload가 계속 동작하는 smoke test와, UNC target이 거부되는 security regression을 분리한다.

security regression은 조직이 통제하는 test share와 test identity만 사용한다. 실제 credential hash를 수집하거나 외부 relay 인프라를 사용해 공격 성공을 증명할 필요는 없다. 검증 목적은 fixed kubelet이 금지된 target을 거부하고, 그 거부가 운영자가 확인 가능한 형태로 남는지 보는 것이다.

잔여 위험 검증

업그레이드 뒤에도 다음 질문을 닫아야 한다.

• 일부 control-plane replica나 Windows node가 오래된 version에 남았는가.
• autoscaling 또는 node replacement가 취약한 image를 다시 공급할 수 있는가.
• rollback image가 affected patch를 포함하고 있는가.
• 임시로 축소한 RBAC가 다시 확대되지 않았는가.
• patch 이전 로그와 객체 증거가 조사 완료 전에 삭제되지 않았는가.
• 의심 evidence가 발견됐을 때 Kubernetes Security Response Committee에 연락할 절차가 있는가.

두 공지는 exploitation evidence를 발견하면 Kubernetes security contact에 알리도록 안내한다.[10][11] 내부 incident response와 증거 보존을 진행하면서 이 escalation 경로도 준비한다.

대응 체크리스트

공통 inventory

• 모든 cluster의 Kubernetes minor와 patch version을 수집했다.
• control plane의 kube-controller-manager와 worker의 kubelet을 별도 자산으로 기록했다.
• 표의 affected/fixed version을 maintenance line별로 비교했다.
• 관리형 서비스의 공급자 build가 upstream fix를 포함하는지 확인했다.
• desired version이 아니라 실제 running version을 확인했다.
• autoscaling·replacement·rollback image의 version도 확인했다.

CVE-2026-2270 exposure

• affected kube-controller-manager가 있는 cluster를 찾았다.
• StatefulSet write permission이 있는 사용자·그룹·service account를 확인했다.
• ControllerRevision write permission이 있는 주체를 확인했다.
• 두 permission이 같은 namespace에서 결합되는 주체를 계산했다.
• 일반 개발자, CI, operator, namespace 관리자 권한을 구분했다.
• victim namespace StatefulSet UID에 접근할 수 있는 경로를 조사했다.
• 빠르게 생성·삭제된 cross-namespace Pod 흔적을 포함해 조사했다.
• OwnerReference와 Pod metadata·spec을 원래 객체 변경과 연결했다.

CVE-2026-76654 exposure

• 모든 Windows node와 kubelet version을 수집했다.
• Windows node의 domain join 여부를 기록했다.
• Windows node에 배치되는 subPath workload를 찾았다.
• 누가 volume과 subPath를 생성·변경할 수 있는지 확인했다.
• symlink가 UNC network share로 resolve될 수 있는 경로를 조사했다.
• Windows node의 승인되지 않은 share 접근·인증 시도 기록을 보존했다.
• kubelet 실행 identity의 의심스러운 후속 사용을 조사했다.
• 구성 가능성, 인증 시도, hash 노출 가능성, 후속 악용 확인을 구분해 보고했다.

remediation

• kube-controller-manager를 branch별 fixed version 이상으로 올렸다.
• 모든 Windows kubelet을 branch별 fixed version 이상으로 올렸다.
• patch 전까지 불필요한 StatefulSet·ControllerRevision 결합 write permission을 축소했다.
• patch 전까지 영향을 받는 Windows workload와 untrusted share 경로를 제한했다.
• 임시 통제를 official fix와 동등한 영구 해결책으로 기록하지 않았다.
• control plane과 Windows node 변경을 별도 완료 증거로 남겼다.

post-upgrade verification

• 모든 controller replica의 running version이 fixed인지 확인했다.
• 모든 Windows node의 running kubelet version이 fixed인지 확인했다.
• 정상 StatefulSet rollout·rollback이 동작하는지 확인했다.
• 격리 환경에서 cross-namespace 생성 경로의 security regression을 확인했다.
• 정상 Windows volume과 subPath workload가 동작하는지 확인했다.
• 격리 환경에서 UNC symlink target이 거부되는지 확인했다.
• 취약한 image가 autoscaling이나 rollback으로 재유입되지 않게 했다.
• patch 이전 노출 기간의 investigation을 별도 종료 기준으로 관리했다.
• exploitation evidence 발견 시 보안 연락과 내부 incident response 절차를 준비했다.

결론

CVE-2026-2270과 CVE-2026-76654는 fixed version 표만 보면 같은 patch 작업처럼 보인다. 그러나 첫 번째는 StatefulSet controller와 namespace-scoped write permission의 결합을 다루고, 두 번째는 Windows kubelet, subPath symlink, UNC share, NTLM 인증 경로를 다룬다.[10][11] 취약한 구성 요소가 다르므로 inventory, detection, 변경 순서, 완료 증거도 달라야 한다.

대응의 출발점은 CVSS 숫자를 다시 계산하는 일이 아니다. 공식 공지의 affected version과 fixed version을 branch별로 정확히 옮기고, 공격 전제를 환경의 실제 권한과 플랫폼에 대입하는 일이다. CVE-2026-2270에서는 StatefulSet과 ControllerRevision의 결합 write permission을, CVE-2026-76654에서는 Windows node와 domain join, subPath, UNC path 조건을 확인해야 한다.[10][11]

탐지와 mitigation도 분리해야 한다. 두 공지는 fixed version으로의 업그레이드를 공식 mitigation으로 제시한다.[10][11] 권한 축소와 network 제한은 patch 전 노출을 줄이는 보상 통제일 수 있지만 fixed binary를 대신하지 않는다. 반대로 patch 완료는 과거 노출 기간에 무슨 일이 있었는지 자동으로 설명하지 않는다.

좋은 완료 보고서는 “cluster를 업그레이드했다”로 끝나지 않는다. 어떤 controller와 Windows node가 영향을 받았는지, 어떤 공격 전제가 열려 있었는지, 어느 fixed version이 실제 실행 중인지, 정상 기능과 차단 경로를 어떻게 검증했는지, patch 이전 evidence를 어떻게 조사했는지를 함께 보여 준다. 보안 공지를 운영 가능한 대응으로 바꾸는 것은 CVE 번호가 아니라 이 증거 사슬이다.

Sources

[10] https://www.openwall.com/lists/oss-security/2026/09/23/35 — CVE-2026-2270 Kubernetes advisory [11] https://www.openwall.com/lists/oss-security/2026/09/23/36 — CVE-2026-76654 Kubernetes advisory