쿠버네티스 보안 취약점 2026, Ingress-NGINX와 NFS·SMB CSI 기준

목차 (Agenda)

2026년 쿠버네티스 보안 취약점, 무엇이 문제인가

쿠버네티스 보안 취약점은 이제 API Server나 kubelet 같은 Core보다, 클러스터에 붙여 쓰는 Ingress Controller와 CSI Driver 같은 확장 컴포넌트에서 더 자주 나옵니다. 쿠버네티스 공식 CVE Feed에 2026년 등록된 항목만 봐도 ingress-nginx 관련 취약점이 6건이고, 스토리지 드라이버인 NFS·SMB CSI Driver의 경로 조작 취약점도 함께 올라와 있습니다(Kubernetes Official CVE Feed).

이 글은 그중 운영 영향이 큰 세 가지, CVE-2026-4342(Ingress-NGINX 설정 주입), CVE-2026-3864(NFS CSI 경로 조작), CVE-2026-3865(SMB CSI 경로 조작)를 다룹니다. 각 취약점이 어떤 원리로 발생하는지, 어떤 버전에서 고쳐졌는지, 패치 외에 운영자가 무엇을 점검해야 하는지를 순서대로 정리합니다.

세 취약점은 공격 방식은 다르지만, 컨트롤 플레인만 지켜서는 클러스터가 안전해지지 않는다는 점에서 같습니다. 핵심 정보는 다음 표와 같습니다(Kubernetes Security Advisory).

구분	CVE-2026-4342	CVE-2026-3864	CVE-2026-3865
대상	ingress-nginx	CSI Driver for NFS	CSI Driver for SMB
유형	NGINX 설정 주입	subDir 경로 조작	subDir 경로 조작
주요 위험	코드 실행, Secret 노출	NFS 디렉터리 삭제·변경	SMB 디렉터리 삭제·변경
CVSS 3.1	8.8 High	6.5 Medium	6.5 Medium
공격 권한	낮음(Ingress 생성)	높음(PV 생성)	높음(PV 생성)
수정 버전	v1.13.9, v1.14.5, v1.15.1	v4.13.1	v1.20.1
공개일	2026년 3월 19일	2026년 3월 17일	2026년 4월 10일

점수만 보면 Ingress-NGINX 쪽이 급해 보이지만, 스토리지 두 건도 권한 설정이 느슨한 클러스터에서는 데이터 손실로 바로 이어질 수 있습니다.

CVE-2026-4342는 어떻게 코드 실행으로 이어지나

CVE-2026-4342는 ingress-nginx가 Ingress 리소스를 읽어 NGINX 설정 파일을 만드는 과정에서, 특정 어노테이션 조합으로 임의의 설정을 끼워 넣을 수 있는 취약점입니다. 주입된 설정은 ingress-nginx Controller 권한으로 실행되므로, 공격자는 컨트롤러 컨텍스트에서 코드를 실행할 수 있습니다(Kubernetes Security Advisory).

피해가 커지는 이유는 컨트롤러가 가진 권한입니다. 기본 설치 구성에서 ingress-nginx Controller는 클러스터 전체의 Secret을 읽을 수 있습니다. 컨트롤러가 장악되면 웹 트래픽 조작을 넘어, 데이터베이스 비밀번호나 인증서 같은 Secret까지 노출될 수 있습니다.

공격 조건도 까다롭지 않습니다. CVSS 벡터상 필요한 권한은 ‘낮음’으로, Ingress 리소스를 만들 수 있는 사용자라면 시도할 수 있습니다. 개발팀에 네임스페이스 단위로 Ingress 생성 권한을 넓게 열어 둔 조직일수록 위험합니다.

이 문제는 한 번의 실수가 아닙니다. 2025년 3월에는 Admission Controller를 통한 원격 코드 실행 취약점 CVE-2025-1974(CVSS 9.8, 일명 IngressNightmare)가 공개됐고, 파드 네트워크에 접근할 수 있으면 인증 없이도 공격이 가능했습니다. 2026년에도 CVE-2026-1580, CVE-2026-24512, CVE-2026-3288 등 설정 주입 취약점이 이어졌습니다. 사용자 입력으로 NGINX 설정을 동적으로 만드는 구조 자체가 계속 공격 표면이 되고 있다는 뜻입니다.

Ingress-NGINX 지원 종료, 패치로 해결되지 않는 이유

패치 버전이 나왔더라도 Ingress-NGINX는 이제 업데이트로 버틸 수 있는 컴포넌트가 아닙니다. 쿠버네티스 SIG Network와 Security Response Committee는 2025년 11월 Ingress-NGINX 은퇴를 발표했고, 2026년 3월 이후로는 새 릴리스, 버그 수정, 보안 패치를 모두 제공하지 않습니다(Kubernetes Blog).

기존 배포는 계속 동작하고 설치 파일도 남아 있습니다. 그래서 당장 장애는 없지만, 앞으로 새 취약점이 발견돼도 공식 패치는 나오지 않습니다. 앞서 본 것처럼 이 컴포넌트는 한 해에만 여러 건의 설정 주입 취약점이 나온 이력이 있습니다.

따라서 판단 기준은 “지금 잘 돌아가는가”가 아니라 “다음 취약점이 나오면 대응할 수 있는가”입니다. 쿠버네티스 프로젝트는 대안으로 Gateway API를 우선 권고하고, 유지보수 중인 다른 Ingress Controller로 옮기는 방법도 제시합니다.

CVE-2026-3864는 NFS 스토리지에 어떤 영향을 주나

CVE-2026-3864는 쿠버네티스 CSI Driver for NFS가 subDir 값을 충분히 검증하지 않아 생기는 경로 조작(Path Traversal) 취약점입니다. 공격자가 PersistentVolume의 volumeHandle에 ../ 같은 문자열을 넣으면, 드라이버가 볼륨을 정리할 때 원래 관리 대상이 아닌 상위 디렉터리까지 건드리게 됩니다(Kubernetes Security Advisory).

정상 상태라면 CSI Driver는 NFS Export 안의 지정된 하위 디렉터리만 다뤄야 합니다. 경로 검증이 빠지면 볼륨 삭제 작업이 다른 팀의 데이터 디렉터리 삭제로 바뀔 수 있습니다. 쿠버네티스는 이 취약점을 CVSS 6.5 Medium으로 평가했고, v4.13.1에서 수정했습니다.

일반 파드 사용자 권한만으로는 공격할 수 없습니다. NFS CSI Driver를 참조하는 PersistentVolume을 직접 만들 수 있는 높은 권한이 필요합니다. 다만 멀티테넌트 클러스터이거나 RBAC가 넓게 열려 있다면 이 조건이 생각보다 쉽게 충족됩니다. 점수는 Medium이어도, 데이터 무결성과 가용성에는 직접적인 피해를 줄 수 있습니다.

CVE-2026-3865, SMB CSI Driver도 같은 구조인가

CVE-2026-3865는 CSI Driver for SMB에서 발견된, 3864와 같은 원리의 경로 조작 취약점입니다. SMB CSI Driver를 참조하는 PersistentVolume의 volumeHandle에 ../를 넣으면, 삭제나 정리 과정에서 드라이버가 SMB 서버의 다른 디렉터리를 삭제하거나 변경할 수 있습니다(Kubernetes Security Advisory).

평가 점수는 CVSS 6.5 Medium이고, 수정 버전은 v1.20.1입니다. 공식 권고안은 업그레이드와 함께 다음 점검을 안내합니다.

볼륨 점검 — SMB CSI Driver를 쓰는 PersistentVolume의 volumeHandle에 ../ 같은 문자열이 있는지 확인합니다.
로그 점검 — CSI Controller 로그에서 의도한 경로 밖의 디렉터리 작업이 있었는지 확인합니다.
권한 제한 — PersistentVolume 생성 권한을 신뢰할 수 있는 관리자에게만 줍니다.
Export 점검 — 드라이버가 접근할 수 있는 SMB Export가 의도한 디렉터리로 한정돼 있는지 확인합니다.

같은 점검 항목은 NFS CSI Driver에도 그대로 적용됩니다.

세 취약점의 공통점, 확장 컴포넌트가 공격 표면이 됐다

세 사례의 공통점은 사용자가 쿠버네티스 API로 넣은 값이 높은 권한을 가진 컴포넌트로 넘어가면서 충분히 검증되지 않았다는 것입니다. Ingress-NGINX에서는 어노테이션 값이 NGINX 설정 생성으로, CSI Driver에서는 볼륨 경로 값이 외부 파일시스템 작업으로 이어졌습니다.

과거 쿠버네티스 보안의 중심은 API Server, RBAC, 컨테이너 이미지, Pod Security였습니다. 지금은 Ingress Controller, Admission Controller, CSI Driver처럼 클러스터와 외부 네트워크·스토리지를 잇는 확장 계층이 주요 공격 표면입니다. 이 계층은 높은 권한으로 동작하기 때문에, 취약점 하나가 클러스터 밖의 기업 데이터 손상으로 번질 수 있습니다.

그래서 CVE 스캐너를 돌리는 것만으로는 부족합니다. 누가 어떤 리소스를 만들 수 있는지(RBAC), 위험한 입력을 어디서 막을지(Admission Policy), 어떤 확장 컴포넌트가 몇 버전으로 돌고 있는지(자산 관리)를 함께 관리해야 합니다.

쿠버네티스 운영자 보안 점검 체크리스트

다음 다섯 항목은 패치 여부와 관계없이 지금 바로 점검할 수 있습니다.

점검 항목	확인 방법	관련 CVE
Ingress-NGINX 사용 여부	ingress-nginx 파드 존재 여부 확인, 있으면 전환 계획 수립	4342, 1974
Ingress 생성 권한	개발자·ServiceAccount에 불필요한 Ingress 생성 권한 회수	4342
PV 생성 권한	PersistentVolume 생성은 관리자만 가능하도록 RBAC 제한	3864, 3865
CSI Driver 버전	NFS v4.13.1, SMB v1.20.1 이상인지 확인	3864, 3865
확장 컴포넌트 자산화	Ingress·CSI·CNI·Operator 버전 목록 관리, CVE Feed 정기 확인	전체

Ingress-NGINX 사용 여부는 kubectl get pods --all-namespaces --selector app.kubernetes.io/name=ingress-nginx 명령으로 확인할 수 있습니다. 결과가 나오면 해당 클러스터는 전환 대상입니다.

패치 이후에도 남는 과제, 보안 수명 주기 관리

패치는 알려진 취약점을 막을 뿐이고, 지원이 끝난 컴포넌트는 앞으로 나올 취약점을 막지 못합니다. 쿠버네티스 보안 운영은 CVE 패치, 지원 종료 컴포넌트 교체, 최소 권한 RBAC, Admission Policy, 확장 컴포넌트 자산 관리를 하나의 체계로 묶어야 합니다.

특히 쿠버네티스 공식 CVE Feed는 Core뿐 아니라 ingress-nginx, CSI Driver 같은 생태계 컴포넌트의 취약점도 함께 올립니다. JSON과 RSS로 받을 수 있으니, 사내 알림 채널에 연결해 두면 새 취약점을 놓치지 않습니다. 클러스터가 정상 동작하는지와 별개로, 쓰고 있는 모든 확장 컴포넌트가 여전히 유지보수되고 있는지를 주기적으로 확인하는 것이 핵심입니다.

자주 묻는 질문 (FAQ)

2026년 쿠버네티스 보안 취약점 중 가장 먼저 대응할 것은 무엇인가요?

Ingress-NGINX를 쓰고 있다면 그것부터입니다. CVE-2026-4342는 낮은 권한으로도 코드 실행과 Secret 노출이 가능하고, Ingress-NGINX는 2026년 3월 이후 보안 패치가 나오지 않기 때문입니다.

CVE-2026-4342 패치 버전으로 올리면 Ingress-NGINX를 계속 써도 되나요?

v1.13.9, v1.14.5, v1.15.1 이상이면 이 취약점은 막힙니다. 하지만 이후 발견되는 취약점은 공식 패치가 없으므로, 패치는 전환 전까지의 임시 조치로 보는 것이 맞습니다.

Ingress-NGINX 대신 무엇을 써야 하나요?

쿠버네티스 프로젝트는 Gateway API를 우선 권고합니다. 당장 구조를 바꾸기 어렵다면 유지보수 중인 다른 Ingress Controller로 옮기는 방법도 있습니다.

CSI Driver 취약점은 Medium 등급인데 급하게 대응해야 하나요?

PersistentVolume 생성 권한이 관리자에게만 있다면 위험은 낮습니다. 멀티테넌트 클러스터이거나 개발자·ServiceAccount에 PV 생성 권한이 있다면, 데이터 삭제로 이어질 수 있으므로 우선 대응 대상입니다.

우리 클러스터가 공격을 받았는지 확인할 수 있나요?

PersistentVolume의 volumeHandle에 ../ 같은 문자열이 있는지, CSI Controller 로그에 의도하지 않은 경로의 디렉터리 작업이 있는지 확인합니다. 흔적이 보이면 security@kubernetes.io로 신고하도록 공식 권고안이 안내합니다.