작성일시: 2026. 11. 02. 18:09

안녕하세요

이스트시큐리티 시큐리티대응센터(ESRC) 입니다.

리눅스 커널의 IPv4 TCP 연결 처리 과정에서 인증 없이 원격에서 악용 가능한 메모리 해제 후 재사용(Use-After-Free) 취약점(CVE-2026-98432)이 공개되어, Red Hat, Debian, SUSE,  Oracle Linux, Amazon Linux 등 주요 리눅스 배포판이 보안 업데이트를 배포하고 있으며(Ubuntu는 11월 1일 기준 패치 준비 중), AWS는 자사 클라우드 서비스별 조치사항을 담은 보안 공지를 발표했습니다.

 

이 취약점은 TCP 연결을 맺는 3-way 핸드셰이크 단계, 즉 애플리케이션의 인증이 이루어지기 전에 발생합니다. 따라서 웹 서버, SSH, 데이터베이스, 로드밸런서, 쿠버네티스 노드 등 IPv4 TCP 연결을 받는 리눅스 커널 4.4 이상의 시스템이라면 대부분 영향 범위에 포함됩니다. 리눅스 커널 CNA는 CVSS 3.1 기준 9.8(Critical)로 평가했으며, Red Hat도 2026년 10월 30일 심각도를 Important에서 Critical(9.8)로 상향했습니다.

 

특히 이 취약점을 제보한 Anthropic은 MPTCP(Multipath TCP) 리스너가 동작하는 서버에서 인증 없이 root 권한으로 임의 명령을 실행하는 실험용 익스플로잇을 구현했다고 밝혔으며, 이 익스플로잇은 연구자의 초기 프롬프트를 받은 미공개 Claude 연구 모델이 작성했다고 설명했습니다.

익스플로잇 코드는 공개되지 않았으나, GitHub에 해당 CVE 관련 저장소가 잇따라 등장하고 있고 일부는 경쟁 상태(Race Condition) 트리거 코드나 개념 증명(PoC)을 포함한다고 주장하고 있어, 신속한 커널 보안 업데이트 적용을 권고 드립니다.

 

 

취약점 개요

■ 사용자 권고 사항

사용 중인 리눅스 서버의 커널 버전(uname -r)을 확인하고, 배포판의 보안 권고문과 비교합니다.
패치된 커널을 설치한 뒤 반드시 재부팅합니다. 커널 패키지만 설치하고 재부팅하지 않으면 취약한 커널이 계속 동작합니다.
컨테이너는 호스트의 커널을 공유하므로, 컨테이너 이미지가 아닌 호스트(쿠버네티스 노드 포함)의 커널을 업데이트해야 합니다.
즉시 패치가 어려운 경우 IPv4 옵션이 포함된 TCP 패킷을 차단하는 방화벽 규칙을 임시로 적용합니다.
MPTCP가 필요하지 않다면 비활성화를 검토합니다. 단, 이는 공격 표면을 줄이는 조치일 뿐 근본적인 해결책은 아닙니다.

취약점 발생 원인

 

리눅스 커널은 TCP 연결 요청(SYN)을 받으면 핸드셰이크가 끝나기 전까지 가벼운 '요청 소켓(Request Socket)'으로 연결 상태를 관리하고, 핸드셰이크가 완료되면 정식 소켓(자식 소켓)을 생성합니다. 이때 상대방이 보낸 IPv4 헤더에 옵션(Record Route, Timestamp 등)이 포함되어 있으면, 커널은 응답 패킷에 이를 반영하기 위해 옵션 데이터를 별도 메모리에 저장해 둡니다.

문제는 이 옵션 데이터가 요청 소켓(ireq_opt)에서 자식 소켓(inet_opt)으로 복사되지 않고 포인터만 넘겨진 채, 소켓이 소멸될 때 일반 kfree()로 즉시 해제된다는 점입니다. 그 사이 다른 CPU에서는 재전송된 SYN을 처리하며 같은 옵션 데이터를 RCU 읽기 잠금만 건 상태로 읽고 있을 수 있어, 이미 해제된 메모리를 참조하는 Use-After-Free가 발생합니다.

 

[표 1] CVE-2026-98432 발생 흐름

 

패치(커밋 e3f33b0a1d89)는 두 소멸자 함수의 kfree()를 kfree_rcu()로 바꿔, 다른 CPU의 RCU 읽기가 모두 끝난 뒤(RCU 유예 기간 이후) 메모리를 해제하도록 수정한 4줄 규모의 변경입니다. 커널 CVE 설명에 따르면 이 경쟁 구간은 커밋 079096f103fa("tcp/dccp: install syn_recv requests into ehash table") 이후부터 존재했습니다.

 

 

영향 및 공격 시나리오

 

리눅스 시스템이 공격에 노출되는 대표적인 환경은 다음과 같습니다.

 

 

 

영향 받는 버전 및 패치 버전

 

■ 리눅스 커널(업스트림)

[표 2] 리눅스 커널 영향 받는 버전 및 패치 버전

 

※ 위 버전은 Linux 업스트림 커널 기준이며, RHEL, Ubuntu, Debian 등 배포판은 기존 커널에 보안 패치를 백포트할 수 있으므로 업스트림 버전 번호만으로 취약 여부를 판단해서는 안 됩니다.

 

■ 주요 배포판 패치 현황 (2026. 11. 01. 기준)

 

[표 3] 주요 리눅스 배포판 패치 현황

 

 

조치 방법

 

① 사용 중인 커널 버전 확인

• 실행 중인 커널 버전 확인

uname -r
uname -v

• 설치된 커널 패키지 확인

# Debian / Ubuntu
dpkg -l 'linux-image*' | grep ^ii

# RHEL / Rocky / AlmaLinux / Amazon Linux
rpm -q kernel

확인한 버전을 [표 4]의 배포판 패치 버전과 비교합니다. 컨테이너 내부가 아닌 호스트와 쿠버네티스 노드에서 확인해야 하며, 패치 커널을 설치했더라도 재부팅 전이라면 uname -r에는 이전 커널 버전이 표시됩니다.

 

② 보안 업데이트 적용

 

커널 업데이트는 재부팅해야 적용되므로 서비스 영향을 고려해 진행하시기 바랍니다. 재부팅 후 다시 커널 버전을 확인해 패치 버전으로 변경되었는지 점검합니다.

 

③ 즉시 패치가 어려운 경우 임시 완화 조치

※ 아래 조치는 패치 적용 전까지 위험을 줄이기 위한 임시 방편이며, 실제 익스플로잇에 대한 차단 효과가 검증되지 않았습니다. 커널 업데이트 및 재부팅만이 완전한 해결책입니다.

[표 4] CVE-2026-98432 임시 완화 조치

 

※ IPv4 옵션은 정상적인 인터넷 트래픽에서는 거의 사용되지 않지만, 내부망에서 IP 옵션을 사용하는 장비·서비스가 있다면 차단 규칙 적용 전 영향을 확인하시기 바랍니다.

 

 

침해 여부 확인 및 조치 방안

 

• 점검 명령 예시

uname -r
ss -Mlnp
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req

※ 현재까지 이 취약점의 악용 흔적을 식별할 수 있는 공식 침해 지표(IoC)나 탐지 시그니처는 공개되지 않았습니다. 원인을 알 수 없는 커널 패닉·재부팅이 반복된다면 커널 로그를 보존하고 패치를 우선 적용하시기 바랍니다.

 

 

참고 용어