Copy Fail: 리눅스 커널 취약점 발견, Proxmox 홈랩 커널 패치

연꿀

01 5월 2026 • 10 min read

2026년 4월 29일, 보안 연구팀 Theori에서 Copy Fail이라는 이름의 리눅스 커널 취약점(CVE-2026-31431)을 공개했다.

2017년부터 모든 주요 리눅스 배포판에 존재해온 이 취약점은, 로컬 사용자가 단 732바이트의 Python 스크립트만으로 root 권한을 탈취할 수 있다. Copy Fail 패치가 되지 않은 환경에서는, 배포판별로 특별한 조건도 없이 실행할 때 마다 100% 성공한다.

Proxmox VE 위에서 LXC 컨테이너를 운영하는 홈랩 사용자로서, 이 취약점이 내 환경에 어떤 영향을 미치는지 살펴보고, 실제 패치까지의 과정을 기록해 본다.

Copy Fail은 어떤 취약점인가?

Copy Fail은 리눅스 커널의 algif_aead암호화 템플릿에 존재하는 로직 버그다. 세 가지 커널 기능의 조합으로 발생한다.

AF_ALG 소켓: 비권한 사용자에게 커널 암호화 연산을 노출
splice() 시스템콜: 파일의 페이지 캐시를 직접 참조하여 데이터를 전달
authencesn의 in-place 최적화: 2017년에 추가된 변경으로, 출력 버퍼 너머에 4바이트를 쓸 수 있는 경로가 생김

이 세 가지가 결합되면, 비권한 사용자가 시스템의 페이지 캐시에 있는 임의 파일에 4바이트를 덮어쓸 수 있다. 공격자는 이를 이용해 /usr/bin/su같은 setuid 바이너리의 메모리 상 이미지를 변조하거나, /etc/passwd의 UID를 0으로 바꿔 root 셀을 획득한다.

기존의 Dirty Cow(CVE-2016-5195)나 Dirty Pipe(CVE-2022-0847)와는 달리, Copy Fail은 레이스 컨디션이 전혀 없다. 결정론적으로 동작하며, 디스크에는 아무런 변경도 남기지 않는다. 파일 무결성 검사 도구로는 탐지할 수 없다는 뜻이다.

더 주목할 점은, 이 취약점이 Theori의 AI 기반 플랫폼인 Xint Code에 의해 약 1시간 만에 발견되었다는 것이다. 사람이 수 주에서 수 개월 걸리던 커널 취약점 분석이 AI로 인해 근본적으로 빨라지고 있다.

현재 Github Copy Fail 스크립트 페이지에서 Copy Fail 취약점을 재현할 수 있는 스크립트를 제공한다. 혹시나 내가 운영하는 서버에서 Copy Fail 취약점이 발생하는지 테스트하길 원한다면 다운로드 받도록 하자.

내 환경은 안전한가? — 위험도 판단 기준

모든 환경이 동일한 수준의 위험에 노출되는 것은 아니다. Copy Fail은 로컬 권한 상승(LPE) 취약점이므로, 공격자가 먼저 시스템에서 코드를 실행할 수 있어야 한다.

매우 위험한 환경

공유 호스팅 서버: 다수의 사용자에게 쉘 접근을 제공하는 환경. 어떤 일반 사용자든 즉시 root를 탈취할 수 있다.
CI/CD 러너: GitHub Actions self-hosted runner, GitLab Runner 등. 악의적인 PR이 빌드 과정에서 실행되면 러너 호스트 전체가 뚫린다.
Kubernetes/컨테이너 클러스터: 하나의 컨테이너가 탈취되면 같은 노드의 모든 컨테이너와 호스트가 위험해진다.
내부자 위협이 있는 환경: 개발 서버에 일반 계정으로 접근하는 직원이 악의를 가지면 바로 root 권한 탈취가 가능하다.

상대적으로 안전한 환경

단일 테넌트 서버: 본인 팀만 쉘 접근 권한을 가진 경우. 내부 LPE 성격이 강하며, 웹 RCE나 탈취된 자격증명과 결합되어야 위험해진다.
단일 사용자 워크스테이션/노트북: 이미 유일한 사용자이므로 긴급도는 낮지만, 로컬 코드 실행이 곧 root 승격으로 이어질 수 있다.

Proxmox LXC 환경에서는 괜찮은가?

Proxmox LXC 환경은 위에 있는 위험한 환경에 비해 "상대적으로 안전하다"고 말할 수 있겠지만, 그래도 Proxmox에서 LXC를 쓰는 환경은 VM 대비 구조적으로 취약하다. 이유는 단순하다.

LXC 컨테이너는 VM과 달리 호스트 커널을 공유한다. 리눅스의 페이지 캐시는 호스트의 모든 프로세스가 공유하는 자원이고, 컨테이너 경계와 무관하게 호스트 커널 위에서 동작하는 모든 프로세스가 같은 페이지 캐시를 바라본다. 즉 LXC 컨테이너 내부에서 Copy Fail을 실행하면

컨테이너 안에서 root를 획득하고
페이지 캐시 변조를 통해 컨테이너를 탈출하여
호스트 시스템까지 장악할 수 있다.

VM(QEMU/KVM) 환경에서는 게스트가 별도의 커널을 사용하므로 호스트 페이지 캐시에 접근할 수 없다. LXC를 사용하는 Proxmox 환경이 VM 기반 환경보다 이 취약점에 더 위험한 이유다.

그리고 LXC 컨테이너 안에서는 커널을 업데이트할 수 없다. 컨테이너가 사용하는 커널은 호스트의 커널이기 때문에, 패치는 반드시 Proxmox 호스트 노드에서 이루어져야 한다.

현재 Proxmox 개발 팀에서는 아래의 커널에 대해서 해당 CVE에 영향을 받지 않거나 패치된 커널 버전을 명시하고 있다.

영향을 받지 않음

proxmox-kernel-7.0.0-*-pve (PVE 9.x, PBS 4.x, PDM 1.x, PMG 9.x)

CVE 대응 패치됨

proxmox-kernel-6.17.13-6-pve or later (PVE 9.x, PBS 4.x, PDM 1.x, PMG 9.x)
proxmox-kernel-6.14.11-7-pve or later (PVE 9.x, PBS 4.x, PDM 1.x, PMG 9.x)
proxmox-kernel-6.14.11-7-bpo12-pve or later (PVE 8.x, PBS 3.x, PMG 8.x)
proxmox-kernel-6.8.12-22-pve or later (PVE 8.x, PBS 3.x, PMG 8.x)
pve-container >= 6.1.5 (PVE 9.x)
pve-container >= 5.3.5 (PVE 8.x)

현재 본인의 PVE 커널 버전이 위에 해당하지 않는다면 즉시 완화 명령어를 입력하거나 커널 업데이트를 진행하기를 권장한다.

실제 대응 과정

1단계: 현재 커널 확인

uname -r
# 6.17.13-1-pve → 취약

필자의 경우 기존 6.17.13-1-pve에서 7.0.0-3-pve로 패치를 해두었다. 이 커널에는 upstream fix 커밋(a664bf3d603d)이 포함되어있다.

2단계: 즉시 완화 조치 (패치 전)

Proxmox 공식 보안 권고(PSA-2026-00018-1) 기준의 완화 절차를 따른다.

먼저 모듈이 이미 로드되어 있는지 확인한다.

lsmod | grep algif_aead

만약 출력이 있고, AF_ALG 소켓을 의도적으로 사용한 적이 없다면 이미 공격 시도가 있었을 가능성이 있다. 저널에서 모듈 로드 시점을 확인할 수 있다: "kernel: NET: Registered PF_ALG protocol family"

algif_aead모듈이 활성화되어 있다면 모듈 로딩을 비활성화한다

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
update-initramfs -u -k all

이미 로드된 모듈을 제거한다

rmmod algif_aead

참고: pve-container패키지를 6.1.5 이상으로 업데이트하면, 이후 시작되는 LXC 컨테이너에서 seccomp 필터를 통해 AF_ALG 소켓 생성이 차단된다.

3단계: 커널 업데이트

Proxmox no-subscription 레포 기준

apt update
apt dist-upgrade

4단계: 리부트 및 확인

# GRUB 설정 확인
grep "GRUB_DEFAULT" /etc/default/grub
# GRUB_DEFAULT=0 → 최신 커널로 자동 부팅

reboot

리부트 후

uname -r
# 7.0.0-3-pve → 패치 완료

5단계: (선택) 이전 커널 정리

설치된 커널 목록을 확인한다

dpkg -l | grep proxmox-kernel-.*-pve-signed

현재 사용중인 커널(uname -r)과 하나의 이전 버전 정도만 남기고, 나머지는 제거해도 된다.

apt remove proxmox-kernel-<버전>-pve-signed # 커널 삭제
apt purge proxmox-kernel-<버전>-pve-signed # 커널 설정 잔여물 삭제
update-grub

주의사항

영향받지 않는 커널:proxmox-kernel-7.0.0-*-pve는 이미 안전하다
패치된 커널: 6.17.13-6-pve, 6.14.11-7-pve, 6.8.12-22-pve이상으로 업데이트하면 해결된다.
pve-container 업데이트: 6.1.5(PVE 9.x) 또는 5.3.5(PVE 8.x) 이상으로 업데이트하면 LXC 컨테이너에서 seccomp으로 AF_ALG 소켓이 차단된다.
LXC 컨테이너는 추가 커널 조치 불필요: 호스트 커널만 업데이트하면 모든 LXC 컨테이너에 자동 적용된다.
VM(QEMU)은 별도: VM은 자체 커널을 사용하므로, VM 내부의 리눅스도 개별적으로 패치가 필요하다.

마무리

Copy Fail은 9년간 리눅스 커널에 숨어 있던 취약점을 AI가 1시간 만에 찾아낸 사례다. 앞으로 이런 수준의 커널 취약점이 더 빈번하게 발견될 것이라는 점을 시사한다.

홈랩이든 프로덕션이든, 새로운 CVE가 알려졌을 때 완화 조치를 빠르게 적용하는 습관이 필요하다. 특히 LXC 컨테이너를 사용하는 환경에서는 호스트 커널이 곧 모든 컨테이너의 커널이라는 점을 항상 기억해야 한다.