Copy Fail 취약점, AI 인프라의 리눅스 운영 리스크를 드러내다

732바이트 PoC가 던진 메시지

Copy Fail로 공개된 CVE-2026-31431은 전형적인 원격 코드 실행 취약점은 아니다. 공격자는 이미 로컬에서 실행 권한을 가져야 한다. 그런데도 이 이슈가 AI 업계에 중요한 이유는 명확하다. 오늘날 AI 제품은 코드 인터프리터, 브라우저 자동화, 노트북, 플러그인 실행, CI 기반 에이전트처럼 “사용자가 올린 코드”를 서버 안에서 돌리는 구조를 빠르게 늘리고 있기 때문이다.

공개 페이지는 이 취약점이 authencesn, AF_ALG, splice() 경로를 거쳐 페이지 캐시에 4바이트 쓰기를 만들 수 있고, 2017년 이후 여러 배포판에서 같은 732바이트 파이썬 스크립트로 권한 상승이 가능하다고 설명한다. 검증 목록에는 Ubuntu, Amazon Linux, RHEL, SUSE가 포함됐다. 세부 주장은 벤더 패치와 커널 커밋 확인이 필요하지만, 운영 관점의 결론은 이미 충분히 분명하다. 멀티테넌트 리눅스에서 “로컬 권한”은 더 이상 낮은 위험이 아니다.

왜 AI 서비스 운영자가 더 민감해야 하나

AI 에이전트 서비스는 일반 웹 서비스보다 로컬 실행면이 넓다. 사용자는 프롬프트만 보내는 것이 아니라 파일, 노트북, 스크립트, 패키지 설치 요청, 브라우저 조작 요청을 보낸다. 한 격리 계층이 깨지면 모델 품질 문제가 아니라 고객 데이터와 호스트 인프라 문제가 된다. 클로드 에이전트 멀웨어 거부 버그에서 봤듯 에이전트 보안은 모델의 거부 정책만으로 끝나지 않는다. 커널, 컨테이너, 네트워크, 파일시스템 정책이 함께 맞물려야 한다.

특히 자체 호스팅 CI 러너와 빌드팜은 위험도가 높다. GitHub self-hosted runners 문서는 편의성을 제공하지만, 신뢰할 수 없는 PR 코드를 실행하는 순간 커널 공유의 위험을 떠안는다. AI 코딩 에이전트가 테스트를 자동 실행하는 조직이라면 이 위험은 더 자주 현실화된다.

패치 이전의 현실적 방어선

가장 좋은 대응은 배포판 커널 업데이트다. 공개 페이지는 메인라인 커밋 a664bf3d603d를 언급하며, algif_aead 모듈 비활성화를 임시 완화책으로 제시한다. 리눅스의 AF_ALG 인터페이스를 직접 쓰는 애플리케이션이 아니라면 영향은 제한적일 수 있다. 다만 금융, 통신, 임베디드처럼 커널 암호 API를 특수하게 쓰는 환경은 사전 점검이 필요하다.

쿠버네티스 환경에서는 seccomp 프로파일로 AF_ALG 소켓 생성을 막는 식의 방어가 유용하다. 컨테이너 보안은 “이미지 스캔”에서 끝나지 않는다. 커널 syscall 경계, 권한 있는 컨테이너 금지, 호스트Path 제한, 노드 풀 분리까지 묶어야 한다.

한국 개발팀을 위한 체크리스트

마이크로소프트가 AI를 SDL에 투입한 사례는 보안 자동화가 중요하다는 점을 보여줬다. 하지만 자동화 자체가 커널 취약점 위에서 돌아간다면 신뢰의 기반이 약해진다. 한국 스타트업과 SI 조직은 AI 기능 출시 속도에 맞춰 보안 운영 속도도 올려야 한다.

1. AI 샌드박스와 CI 러너의 커널 버전을 즉시 재고 조사한다.
2. untrusted workload는 장기 실행 호스트가 아니라 폐기형 VM 또는 격리 노드에서 실행한다.
3. /proc, hostPath, Docker socket 노출 여부를 점검한다.
4. 패치 전까지 AF_ALG 사용 여부를 확인하고 불필요하면 차단한다.
5. 사고 대응 시 디스크 이미지만 믿지 말고 페이지 캐시와 실행 중 프로세스 관찰도 포함한다.

구글 신규 코드 75% AI 생성처럼 AI가 개발 파이프라인 깊숙이 들어올수록, 취약점 대응은 더 이상 인프라팀만의 일이 아니다. 제품팀도 “이 에이전트가 어떤 커널 위에서 실행되는가”를 알아야 한다.

FAQ

Q1. 원격 공격자가 바로 악용할 수 있나?
공개 설명 기준으로는 로컬 실행 권한이 필요하다. 그러나 웹 RCE, 탈취 계정, 악성 PR, 노트북 실행 권한과 결합하면 위험도가 크게 올라간다.

Q2. 컨테이너를 쓰면 안전한가?
아니다. 컨테이너는 커널을 공유한다. Copy Fail류 취약점은 컨테이너 탈출 프리미티브로 이어질 수 있어 노드 단위 방어가 필요하다.

Q3. 파일 무결성 도구가 탐지하나?
페이지 캐시가 오염된 동안에는 해시 차이가 보일 수 있지만, 디스크에는 남지 않을 수 있다. 실행 중 탐지와 커널 패치가 핵심이다.

Q4. AI 샌드박스는 무엇부터 바꿔야 하나?
장기 공유 호스트에서 임의 코드를 돌리지 말고, 폐기형 VM·강한 seccomp·네트워크 차단·비밀값 미주입을 기본값으로 둬야 한다.

Q5. 개발자는 무엇을 확인해야 하나?
내가 쓰는 CI 러너가 공유형인지, PR에서 비밀값과 내부망에 접근 가능한지, 러너가 작업 후 완전히 폐기되는지 확인해야 한다.