Amazon EFS CSI Driver CVE-2026-85781 보안 이슈, 비기본 삭제 옵션 사용 시 디렉터리 삭제 위험
AWS는 Amazon EFS CSI Driver의 볼륨 삭제 처리 로직에서 CVE-2026-85781을 공개했다. 이 이슈는 기본 설정이 아닌 --delete-access-point-root-dir=true 옵션을 사용한 환경에서, PersistentVolume의 volume handle이 가리키는 EFS 액세스 포인트와 파일 시스템의 소유 관계를 충분히 검증하지 못하는 문제다. 그 결과 PersistentVolume 생성 권한이 있는 인증된 Kubernetes 사용자가 조작된 volume handle을 이용해, 원래 수정 권한이 없는 Amazon EFS 파일 시스템 내 디렉터리를 재귀적으로 삭제하도록 컨트롤러를 유도할 수 있다.
문제의 핵심은 EFS 자체가 아니라 CSI 드라이버의 삭제 검증 로직
원문에 따르면 이번 이슈는 Amazon EFS 서비스 자체의 접근통제 실패가 아니라, EFS CSI Driver가 볼륨 삭제 과정에서 참조 무결성을 충분히 확인하지 않은 데서 발생했다. 즉 스토리지 백엔드 자체 취약점으로 보기보다, 쿠버네티스 스토리지 컨트롤러 동작과 권한 위임 경계의 문제로 이해하는 것이 정확하다.
특히 기본값이 아닌 삭제 옵션을 켠 경우에만 문제가 드러난다는 점은 운영 환경별 노출도 차이가 크다는 뜻이다. EKS나 자체 쿠버네티스 클러스터에서 EFS CSI Driver를 사용하더라도, 해당 옵션을 실제로 활성화했는지 먼저 확인해야 한다.
영향받는 환경과 악용 조건
영향 버전은 3.4.0 이하로 제시됐다. 다만 이 취약점이 바로 모든 환경에서 동일하게 악용되는 것은 아니며, 최소한 컨트롤러가 --delete-access-point-root-dir=true로 설정돼 있어야 하고, 공격자가 Kubernetes에서 PersistentVolume을 생성할 수 있는 인증된 사용자여야 한다.
운영 관점에서는 스토리지 클래스, Helm values, 애드온 배포 매니페스트, GitOps 저장소에 이 옵션이 포함돼 있는지 우선 확인할 필요가 있다. 여기에 더해 일반 사용자나 테넌트 운영 계정에 PersistentVolume 생성 권한이 넓게 열려 있다면, 멀티테넌트 클러스터나 공용 플랫폼 환경에서 위험도가 상대적으로 커질 수 있다.
쿠버네티스 스토리지 운영자가 확인할 점
첫째, 현재 사용 중인 Amazon EFS CSI Driver 버전이 3.4.0 이하인지 확인해야 한다. 둘째, 컨트롤러 배포 설정에서 --delete-access-point-root-dir=true가 활성화돼 있는지 점검해야 한다. 셋째, PersistentVolume 생성 권한이 어떤 사용자·서비스계정·자동화 파이프라인에 부여돼 있는지 RBAC 기준으로 다시 살펴볼 필요가 있다.
또한 표준 배포 템플릿, 내부 Helm 차트, 클러스터 골든 이미지, 운영 자동화 저장소에 과거 설정이 남아 있는지도 확인하는 편이 좋다. 스토리지 삭제 동작은 한 번 실행되면 복구 부담이 커질 수 있으므로, 옵션 비활성화 여부와 권한 범위 축소를 함께 보는 방식이 현실적이다.
국내·일본 리전 운영보다 중요한 것은 공용 클러스터 권한 경계
이번 공지는 특정 지역 리전 장애나 EFS 서비스 중단과 관련된 내용이 아니다. 한국이나 일본에서 EFS 기반 쿠버네티스 워크로드를 운영하는 경우에도 핵심은 리전 이슈보다 동일한 CSI 드라이버 설정과 Kubernetes 권한 구조에 있다.
특히 서버호스팅형 관리형 쿠버네티스, 사내 플랫폼, 여러 팀이 공유하는 클러스터처럼 스토리지 프로비저닝 권한이 분산된 환경에서는, 삭제 옵션 사용 여부와 PV 생성 권한 위임 범위를 함께 관리해야 한다. 원문 사실 범위에서 보면 네트워크 경로보다 스토리지 컨트롤러 설정 점검이 우선순위가 높다.
핵심 포인트
- 취약점 식별자는 CVE-2026-85781이다.
- 영향 버전은 Amazon EFS CSI Driver 3.4.0 이하이다.
- 문제는 비기본 옵션 --delete-access-point-root-dir=true 사용 시 발생한다.
- PersistentVolume 생성 권한이 있는 인증된 Kubernetes 사용자가 조작된 volume handle로 악용할 수 있다.
- Amazon EFS 자체 접근제어가 깨진 것은 아니며 CSI 드라이버 삭제 로직 이슈다.