CVE-2026-98432 리눅스 TCP 취약점 대응법

CVE-2026-98432란 무엇인가요?

CVE-2026-98432는 리눅스 운영체제의 핵심인 리눅스 커널의 취약점입니다. 공식 제목은 ipv4: free inet_opt and ireq_opt after an RCU grace period입니다^[1]. 리눅스 커널 CVE 팀이 이 번호를 부여하고 2026년 10월 15일에 레코드를 공개했습니다^[1]. 레코드에 기재된 CVSS 3.1 기본 점수는 9.8로, Critical 등급입니다^[1].

이 결함은 use-after-free, 즉 프로그램이 이미 해제된 메모리를 계속 사용하는 문제로, 해당 메모리에는 이미 다른 데이터가 들어 있을 수 있습니다. 이번 경우에는 들어오는 IPv4 TCP 연결 요청을 처리하는 코드에 존재합니다^[10]. CVSS 벡터는 AV:N/AC:L/PR:N/UI:N입니다. 이는 공격이 네트워크를 통해 이루어지고, 복잡도가 낮으며, 권한도 사용자 상호작용도 필요하지 않다는 뜻입니다^[1].

이 버그는 커밋 079096f103fa와 함께 들어온 Linux 4.4부터 존재했습니다^[2]. Eric Dumazet이 작성한 수정 사항은 2026년 10월 5일에 커밋되어 현재 메인라인 커널에 반영되어 있습니다^[3]. 또한 유지 관리 중인 안정 브랜치에도 백포트되었습니다^[2][4].

어떤 시스템이 영향을 받나요?

Red Hat에 따르면 IPv4 TCP 네트워킹이 활성화된 취약한 커널을 실행하는 모든 시스템이 영향을 받습니다. 그중 외부에서 들어오는 TCP 연결을 받는 시스템이 가장 직접적으로 노출됩니다^[6]. AlmaLinux는 신뢰할 수 없는 네트워크로부터 IPv4 TCP 연결을 받는 모든 시스템을 노출된 것으로 간주하라고 권고합니다^[10]. IPv6는 주된 문제의 영향을 받지 않습니다^[2].

이 취약점은 어떻게 작동하나요?

TCP 연결은 핸드셰이크로 시작됩니다. 클라이언트가 SYN 패킷을 보내면 서버가 SYN-ACK로 응답하고, 클라이언트가 이를 확인합니다. SYN 패킷에는 IP 헤더의 선택적 추가 필드인 IPv4 옵션이 담길 수 있습니다. Record Route와 Timestamp가 그 예입니다^[1].

커널의 설명에 따르면 tcp_v4_syn_recv_sock() 함수는 저장된 옵션을 복사하지 않은 채 새 자식 소켓에 그대로 넘깁니다^[2]. 그사이 다른 CPU 코어가 같은 요청에 대해 재전송된 SYN을 처리하면서 그 옵션을 읽는 SYN-ACK를 만들 수 있습니다^[2]. SYN-ACK가 아직 만들어지는 도중에 자식 소켓이 해제되는 것을 막는 장치는 없습니다. 자식 소켓의 옵션은 단순한 kfree()로 해제되므로, 커널은 ip_options_build()에서 해제된 메모리를 읽게 됩니다^[2].

요청 소켓 마이그레이션이 켜져 있을 때, 즉 net.ipv4.tcp_migrate_req=1 설정이나 BPF reuseport 프로그램을 사용할 때에도 비슷한 두 번째 경쟁 조건이 존재합니다^[2]. 수정 사항은 inet_sock_destruct()와 tcp_v4_reqsk_destructor()에서 kfree_rcu()를 사용하게 하여, 두 해제 경로 모두 RCU 유예 기간을 기다리도록 만듭니다^[2]. RCU(read-copy-update)는 메모리를 읽는 쪽이 더 이상 그 메모리를 사용할 수 없게 될 때까지 해제를 늦추는 커널 기법입니다.

공격자는 이 취약점으로 무엇을 할 수 있나요?

CVE 레코드의 점수 산정 설명에는 세 가지 영향이 기술되어 있습니다^[1].

• 정보 유출: 해제된 메모리는 다른 데이터로 재사용될 수 있고, 그 내용이 공격자에게 돌려보내는 SYN-ACK에 복사될 수 있습니다^[1].
• 메모리 손상: 낡은 길이 값과 오프셋이 커널의 쓰기 작업을 경계 밖으로 이끌 수 있어, 제어 흐름이 손상될 가능성이 있습니다^[1].
• 시스템 다운: 재사용된 길이 값이 커널 패닉을 일으킬 수 있으며, 잘못된 위치에 대한 쓰기도 커널을 다운시킬 수 있습니다^[1].

Red Hat은 타이밍에 민감한 이 버그를 통해 안정적으로 코드를 실행하려면 정밀한 힙 제어가 필요하다고 덧붙입니다. 그럼에도 네트워크상의 전제 조건이 없고 심각한 불안정을 일으킬 수 있기 때문에 Critical 등급으로 평가합니다^[7].

Anthropic은 무엇을 공개했고, MPTCP는 어떤 역할을 하나요?

2026년 10월 27일, Anthropic의 Frontier Red Team은 Claude 모델을 활용해 찾아낸 취약점들에 관한 보고서를 공개했습니다^[4][11]. CVE-2026-98432에 대해서는, 팀이 멀티패스 TCP(MPTCP) 리스너가 있는 리눅스 서버에서 원격 공격자가 자격 증명이나 사용자 상호작용 없이 root 권한으로 임의의 명령을 실행할 수 있는 익스플로잇을 만들었다고 밝힙니다^[4]. MPTCP는 하나의 연결이 여러 네트워크 경로를 동시에 사용할 수 있게 해 주는 TCP 확장입니다.

Anthropic은 공격을 두 단계로 설명합니다. 먼저 익스플로잇은 커널 포인터를 유출해 커널의 주소 무작위화 기법인 KASLR을 무력화합니다. 이어서 콜백 포인터를 덮어써 커널이 공격자가 고른 명령을 root 권한으로 실행하게 만듭니다^[4]. 경쟁에서 지더라도 핸드셰이크가 실패할 뿐 시스템이 다운되지 않으므로, 공격자는 계속 재시도할 수 있습니다^[4]. Anthropic의 개념 증명에서는 커널 포인터를 유출하는 데 48분이 걸렸고, 명령 실행에는 다시 5분이 걸렸습니다^[4].

MPTCP가 반드시 필요한가요?

이를 평가한 벤더들에 따르면 그렇지 않습니다. Red Hat은 MPTCP가 이 취약점의 필수 조건이 아니며, MPTCP를 비활성화한 시스템도 여전히 영향을 받는다고 밝힙니다^[6]. Go 보안 팀은 시연된 익스플로잇에는 MPTCP 리스너가 필요하지만, 근본 버그 자체는 MPTCP에만 국한된 것이 아니라고 설명합니다^[5]. Go가 여기서 중요한 이유는 Go 1.24부터 리눅스에서 Go 프로그램의 리스닝 소켓에 MPTCP가 기본으로 활성화되어 있기 때문입니다^[5].

Akamai에 따르면 Anthropic은 root 익스플로잇을 공개하지 않았으며, Akamai는 2026년 11월 2일 공개된 실제 작동 익스플로잇을 알지 못한다고 밝혔습니다^[11].

어떤 커널 버전과 배포판이 수정되었나요?

커널 CVE 팀은 다음 업스트림 수정 버전을 제시합니다. 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 그리고 메인라인 7.3입니다^[2]. 하지만 대부분의 사용자는 배포판이 빌드한 커널을 쓰며, 이 커널은 배포판 자체의 버전 번호를 사용합니다. 업스트림 번호를 비교하기보다 사용 중인 배포판의 보안 권고를 확인하십시오.

2026년 11월 3일 기준 현황은 다음과 같습니다.

• Red Hat Enterprise Linux: RHEL 8, 9, 10용 수정 커널이 2026년 11월 1일에 배포되었습니다. RHEL 6과 7은 영향을 받지 않는 것으로 표시되어 있습니다. RHEL 9 실시간 커널과 OpenShift 노드 이미지는 아직 영향을 받는 것으로 표시되어 있습니다^[7].
• Ubuntu: Ubuntu는 이 문제를 Critical로 평가합니다. 추적 페이지에는 26.10, 26.04 LTS, 24.04 LTS, 22.04 LTS가 취약하며 수정이 진행 중인 것으로 나와 있고, 20.04, 18.04, 16.04도 취약한 것으로, 14.04는 영향을 받지 않는 것으로 표시되어 있습니다^[8].
• Debian: Debian 12 bookworm(linux 6.1.190-1 및 linux-6.12 6.12.113-1~deb12u1), Debian 13 trixie(linux 6.12.113-1), 그리고 unstable용 수정이 제공됩니다^[9].
• AlmaLinux: AlmaLinux 8, 9, 10용 수정 커널이 프로덕션 저장소에 올라와 있습니다^[10].
• 기타: Akamai는 2026년 10월 30일까지 SUSE, Oracle Linux, Amazon Linux 2023이 일부 릴리스용 수정 커널을 배포했다고 보고했습니다^[11].

안드로이드 휴대폰은 어떤가요?

안드로이드는 리눅스 커널을 사용하지만, 2026년 11월 2일 발표된 Android 보안 게시판에는 CVE-2026-98432가 포함되어 있지 않습니다^[13]. 휴대폰 사용자는 제조사가 배포하는 보안 업데이트를 설치해야 합니다.

서버가 취약한지 어떻게 확인하나요?

1. 실행 중인 커널을 확인합니다. uname -r을 실행합니다. 수정 사항은 시스템이 새 커널로 재부팅된 뒤에야 적용된 것으로 볼 수 있습니다. AlmaLinux는 재부팅한 뒤 uname -r로 버전을 확인하라고 안내합니다^[10].
2. 벤더의 추적 페이지와 비교합니다. 사용 중인 배포판의 보안 페이지에서 CVE-2026-98432를 찾아봅니다. Red Hat^[7], Ubuntu^[8], Debian^[9], AlmaLinux^[10]는 각각 수정이 포함된 패키지 버전을 제시합니다.
3. MPTCP를 확인합니다. sysctl net.mptcp.enabled로 MPTCP가 켜져 있는지 알 수 있습니다. sudo ss -lnMp는 MPTCP 리스너와 이를 소유한 프로세스를 보여 줍니다^[10]. Akamai는 net.ipv4.tcp_migrate_req도 확인할 것을 권합니다^[11].
4. Go 서비스를 찾습니다. Go 1.24 이상으로 빌드된 Go 프로그램은 리눅스에서 기본적으로 MPTCP 리스너를 엽니다^[5]. 따라서 운영 중인 모든 Go 서비스가 Anthropic이 악용한 경로를 노출할 수 있습니다.
5. 상위 제품을 점검합니다. Red Hat은 OpenShift, OpenStack, Red Hat Virtualization을 포함해 RHEL 커널을 기반으로 한 모든 제품이 영향을 받을 수 있다고 경고합니다^[6].

CVE-2026-98432는 어떻게 수정하거나 완화하나요?

진짜 해결책은 패치된 커널입니다. Red Hat은 커널 업데이트 적용을 유일한 완전한 해결책이라고 부르며^[6], Go 보안 팀도 패치된 커널로 업그레이드하는 것이 최선의 해결책이라고 말합니다^[5]. 배포판의 커널 업데이트를 설치하고 재부팅한 뒤 실행 중인 버전을 확인하십시오.

패치가 나오기 전에는 무엇을 할 수 있나요?

• IPv4 옵션이 있는 TCP 패킷을 차단합니다. Red Hat이 공개하고 Ubuntu 추적 페이지가 사용자 제공 임시 해결책으로 소개한 nftables 규칙은, IP 헤더가 기본 20바이트보다 긴 들어오는 IPv4 TCP 패킷, 즉 옵션을 담은 패킷(ip hdrlength > 5)을 차단합니다^[6][8]. 타임스탬프나 윈도 스케일링 같은 일반적인 TCP 옵션은 TCP 헤더에 들어 있으므로 영향을 받지 않습니다^[8]. 두 벤더 모두 이 규칙이 위험을 줄여 주지만 공격을 완전히 막을 수는 없다고 말합니다^[6][8].
• 규칙의 한계를 알아 둡니다. AlmaLinux는 자사 버전의 규칙이 재부팅 후 유지되지 않고, 같은 호스트의 컨테이너 간 트래픽이 규칙을 우회할 수 있으며, 라우팅 호스트에서는 전달되는 패킷까지 차단하고, CIPSO/NetLabel 레이블에 의존하는 네트워크를 망가뜨린다고 지적합니다^[10]. Ubuntu는 별도 네트워킹을 쓰는 컨테이너에는 규칙을 따로 적용해야 한다고 설명합니다^[8].
• 필요 없다면 MPTCP를 끕니다. net.mptcp.enabled=0으로 설정하면 시스템 전체에서 MPTCP가 꺼집니다^[10]. Akamai는 net.ipv4.tcp_migrate_req=0 설정도 권합니다^[11]. 다만 Akamai는 MPTCP를 끄는 것만으로는 공격을 막을 수 없고, 경쟁 조건이 발생할 가능성을 낮출 뿐이라고 경고합니다^[11]. Go 프로그램은 GODEBUG=multipathtcp=0으로 MPTCP를 끌 수도 있지만, Go 팀은 프로그램별 비활성화가 취약한 방식이라고 말합니다^[5].
• 경계에서 필터링합니다. OpenShift의 경우 Red Hat은 노드에 적용한 규칙이 파드 간 트래픽을 필터링하지 못하는 반면, 클러스터 앞단의 네트워크 경계에서 필터링하면 이 한계를 피할 수 있다고 설명합니다^[6].

init_on_free=1이 도움이 되나요?

oss-security의 한 게시물은 추가 임시 방편으로 init_on_free=1 부팅 옵션을 제안했습니다. 이에 대해 CIQ 커널 팀의 한 구성원은 이 옵션이 이 CVE를 의미 있게 완화하지 못하며 보안 권고에서 비중 있게 다뤄서는 안 된다고 답했습니다^[12]. 이 옵션은 이 버그에 대한 완화책이 아니라 일반적인 보안 강화 조치로 보아야 합니다.

CVE-2026-98432는 실제로 악용되고 있나요?

2026년 11월 3일 기준 CVE-2026-98432는 실제 악용이 확인된 결함을 모은 미국 정부 목록인 CISA의 알려진 악용 취약점(KEV) 목록에 올라 있지 않습니다^[14]. Akamai는 2026년 11월 2일 공개된 실제 작동 익스플로잇을 알지 못한다고 밝혔습니다^[11]. 그렇다고 아무도 이 버그를 악용하지 않는다는 증거가 되지는 않습니다. 안정적인 익스플로잇이 존재한다는 사실이 이미 입증되었고^[4], 기술적 세부 사항은 커널 수정 사항에 공개되어 있습니다^[3].

심각도에 대한 인식도 시간이 지나며 달라졌습니다. 이 CVE는 2026년 10월 15일에 처음 공개되었습니다^[1]. 이후 Anthropic의 10월 27일 보고서로 더 넓은 관심을 받게 되었습니다^[4][11]. 이어서 10월 29일부터 11월 2일 사이에 임시 완화책을 담은 벤더 공지가 나왔습니다^[5][6][10]. 처음 공개된 레코드만 훑어본 관리자는 이후의 안내를 놓쳤을 수 있습니다.

앞으로 어떻게 될까요?

Red Hat은 조사가 진행 중이며 새로운 정보가 나오는 대로 공지를 갱신하겠다고 밝힙니다^[6]. RHEL 9 실시간 커널과 OpenShift 이미지^[7], 아직 작업 중인 Ubuntu 커널^[8] 등 남은 패키지들은 앞으로 며칠 또는 몇 주 안에 수정될 것으로 예상됩니다. 처음 몇 주 동안 이 페이지들이 여러 차례 바뀌었으므로, 뉴스 요약보다는 벤더의 추적 페이지를 확인하십시오.

커널 수정 사항에는 관련된 문제 하나도 남아 있습니다. 커널 설명에 따르면 IPv6의 tcp_v6_reqsk_destructor()에도 CALIPSO로만 설정된 옵션에 대해 같은 마이그레이션 문제가 있으며, 이는 별도의 패치로 처리될 예정입니다^[2]. Anthropic의 조율된 공개 정책은 패치에 90일, 그리고 공개 권고 이상의 세부 사항을 논의하기 전까지 추가로 45일을 허용합니다^[4]. 따라서 더 많은 기술적 세부 사항이 나중에 공개될 수 있습니다.

이 글은 일반적인 기술 정보이며, 벤더의 보안 권고나 소속 조직의 사고 대응 절차를 대신하지 않습니다.