로컬 권한 상승 취약점이라는 말을 들으면 보통 이렇게 반응합니다. "원격 RCE도 아닌데, 당장 장애 내면서까지 처리해야 하나?" CopyFail는 이 질문을 조금 바꿔야 하는 사례입니다. 무서운지 아닌지가 아니라, 내 환경에서 "로컬 사용자"가 어디에 숨어 있는지부터 다시 봐야 합니다.
최근 공개된 CopyFail(CVE-2026-31431)는 리눅스 커널의 AF_ALG와 splice() 경로를 악용해 일반 권한 사용자가 루트 권한을 얻을 수 있게 만드는 취약점입니다. 상위 패치는 4월 1일 커널에 들어갔지만, 공개 시점 이후에도 여러 배포판의 실제 배포는 뒤따르는 중이었고, 공개 PoC도 빠르게 확산됐습니다.123
진짜 우선순위는 "로컬 접근이 어디에 존재하나"로 정해진다
확인된 사실부터 보면, 이 취약점은 단독 원격 공격은 아닙니다. 먼저 일반 사용자 권한의 실행 환경이 필요합니다.24 그래서 단일 사용자 데스크톱이나, 외부 코드가 전혀 돌지 않는 전용 서버에서는 분명히 위험도가 상대적으로 낮아질 수 있습니다.
하지만 여기서 많은 팀이 판단을 잘못합니다. 오늘날 "로컬 사용자"는 SSH 계정만 뜻하지 않습니다. 공유 셸 서버, 대학·연구 클러스터, CI/CD 러너, 고객 코드가 도는 SaaS 백엔드, Kubernetes 노드 위의 컨테이너, 일회성 빌드 에이전트도 사실상 로컬 실행권한을 제공합니다.
이런 환경에서는 CopyFail이 단순 패치 항목이 아니라 권한 경계 붕괴 문제로 바뀝니다. 예를 들어 PR 기반 빌드가 도는 공유 러너라면, "빌드 한 번"이 곧 호스트 루트 획득으로 이어질 수 있습니다. Kubernetes도 마찬가지입니다. 페이지 캐시는 호스트 단위로 공유되기 때문에, 취약한 커널에서 컨테이너 내부 프로세스가 해당 경로에 도달하면 컨테이너 탈출과 노드 장악 문제로 번집니다.256
실무적으로는 이렇게 분류하는 편이 빠릅니다.
오늘 바로 조치 우선: 공유 러너, 다중 사용자 호스트, 불신 워크로드를 받는 서버, Kubernetes 워커 노드
빠른 패치 대상: 인터넷 노출 서비스 호스트, 내부 점프박스, 개발자 공용 서버
일반 패치 사이클 가능: 단일 목적 전용 서버, 로컬 사용자 부재, 외부 코드 실행 없음
컨테이너와 저권한 계정이 안전벨트라는 믿음이 흔들린다
CopyFail의 기술적 핵심은 디스크 파일이 아니라 페이지 캐시를 건드린다는 점입니다. 공격자는 읽을 수 있는 파일의 메모리상 캐시를 4바이트씩 조작할 수 있고, 이를 반복해 su 같은 setuid 바이너리를 루트 권한 실행 경로로 바꿉니다. 중요한 점은 원본 파일은 디스크에서 바뀌지 않는다는 것입니다.26
이 사실이 왜 크냐면, 우리가 익숙한 두 가지 안전장치를 동시에 약하게 만들기 때문입니다.
첫째, "일반 사용자 계정이니까 괜찮다"는 가정입니다. 로컬 권한 상승이 안정적으로 가능하면, 앱 계정 하나 뚫린 순간 호스트 전체 신뢰가 무너집니다.
둘째, "컨테이너니까 어느 정도 격리된다"는 가정입니다. 기본 seccomp나 Kubernetes Restricted 정책만으로는 AF_ALG 소켓 생성을 막지 못했다는 분석이 나와 있습니다.6 즉 비특권 컨테이너, capability를 거의 제거한 파드라도 커널이 취약하면 호스트 경계가 충분하지 않을 수 있습니다.
물론 한계도 있습니다. 모든 환경이 똑같이 위험한 것은 아닙니다. AF_ALG 접근이 정책적으로 차단돼 있거나, 관련 모듈이 비활성화돼 있거나, 아예 SELinux 정책이 매우 강하게 막는 플랫폼은 노출 양상이 다를 수 있습니다. GrapheneOS가 Android에서 영향이 제한적이라고 밝힌 것도 이런 맥락입니다.7 핵심은 "리눅스니까 다 똑같이 위험"이 아니라, 내 격리 모델이 커널 경계에 얼마나 의존하는가입니다.
패치만으로 끝내면 놓치는 것: 흔적이 약한 공격에 대비해야 한다
운영자에게 가장 불편한 대목은 탐지입니다. CopyFail은 디스크 무결성 검사에 잘 걸리지 않을 수 있습니다. 페이지 캐시만 오염되고 파일 자체는 안 바뀌기 때문입니다.28 그래서 "해시가 정상이다, 파일이 그대로다"는 이유만으로 안심하면 안 됩니다.
당장 할 일은 세 가지입니다.
첫째, 배포판 패치가 나왔는지 확인하고 실제로 재부팅까지 끝났는지 봐야 합니다. 커널 취약점은 패키지 설치와 위험 제거가 같은 말이 아닙니다.59
둘째, 패치 전 임시조치가 필요하면 algif_aead 비활성화나 AF_ALG 차단을 검토해야 합니다. 다만 이건 커널 빌드 옵션과 워크로드에 따라 적용 방식이 달라집니다.4910
셋째, 탐지 기대치를 바꿔야 합니다. 비정상 AF_ALG 소켓 생성, splice()와의 결합, setuid 실행 직후의 비정상 권한 전이 같은 행위를 봐야 합니다.68 반대로 포렌식 관점에서는 "뚜렷한 파일 변조 흔적이 없었다"가 무혐의의 증거가 아닙니다. 공유 러너나 노드에서 의심 정황이 있었다면, 로그가 약하더라도 해당 호스트를 불신하는 판단이 더 현실적일 수 있습니다.
결국 CopyFail이 남기는 질문은 "우리가 취약했는가"보다 "왜 이 취약점 하나가 이렇게 큰 운영 위험으로 증폭됐는가"에 가깝습니다. 다중 사용자 호스트를 얼마나 오래 유지했는지, 공유 러너를 얼마나 넓게 썼는지, 컨테이너를 얼마나 강한 보안 경계처럼 취급했는지, 그리고 사고 후 무엇을 볼 수 있다고 과신했는지가 함께 드러났기 때문입니다.
지금 가장 신경 써야 하는 팀은 리눅스를 많이 쓰는 팀이 아니라, 남의 코드와 여러 사용자를 같은 커널 위에 올려두는 팀입니다. CopyFail의 우선순위는 CVSS 숫자보다, 당신의 시스템이 "로컬 같지 않은 로컬 실행권한"을 얼마나 많이 허용하느냐로 정하는 편이 맞습니다.
참고
2티오리 '진트 코드', 리눅스 루트 권한 탈취 취약점 'CopyFail' 발견
4CVE-2026-31431 ("Copy Fail"): What You Need to Know
5CVE-2026-31431 Copy Fail Linux Root Vulnerability Explained
6Copy Fail: When 732 Bytes of Python Can Root Every Linux Server You Manage
10Closing the AF_ALG Window: Userspace Mitigation for CVE-2026-31431 ("Copy Fail")
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.