리눅스 커널 TCP 원격 코드 실행 취약점(CVE-2026-98432) 보안 권고

개요

리눅스 커널의 IPv4 TCP 연결 처리 코드에서 원격 코드 실행으로 이어질 수 있는 메모리 해제 후 사용(Use-After-Free) 취약점 CVE-2026-98432가 공개됐습니다. 인증 없이 패킷을 보내는 것만으로 취약점이 유발되기 때문에, 웹·SSH·syslog처럼 TCP 포트를 열어 둔 리눅스 서버는 대부분 영향을 받습니다. 리눅스 서버를 운영하는 조직은 커널 버전을 바로 확인하고, 패치된 커널이 아직 나오지 않은 배포판에는 임시 완화 조치를 먼저 적용해야 합니다.

리눅스 커널 개발팀은 10월 15일 이 취약점을 CVE로 등록하고 CVSS v3.1 9.8점(Critical)으로 평가했습니다. 위험성이 널리 알려진 것은 10월 30일입니다. 이날 앤스로픽이 MPTCP(멀티패스 TCP) 리스너가 열린 서버에서 원격에서 root 권한으로 명령어를 실행하는 과정을 공개했고, 레드햇도 같은 날 갱신한 보안 공지(RHSB-2026-016)에서 심각도를 Critical로 평가하고, 이 취약점으로 원격 코드 실행이 가능하다고 밝혔습니다.

리눅스 커널 개발팀의 패치는 업스트림 커널과 유지보수 중인 안정 브랜치에 이미 반영됐습니다. 그러나 각 배포판별로는 상황이 다릅니다. 10월 31일 기준 Amazon Linux는 패치된 커널을 배포했지만, RHEL과 Ubuntu는 아직 준비 중입니다.

영향을 받는 커널 버전

CVE 레코드에 따르면 취약점은 리눅스 커널 4.4에 들어간 커밋 079096f103fa("tcp/dccp: install syn_recv requests into ehash table")에서 시작됐고, 커밋 e3f33b0a1d89("ipv4: free inet_opt and ireq_opt after an RCU grace period")로 수정됐습니다. 4.4 이상이면서 아래 패치 버전보다 낮은 커널은 모두 취약합니다.

kernel.org가 현재 유지보수하는 장기 지원(longterm) 브랜치는 6.18, 6.12, 6.6, 6.1, 5.15, 5.10이며, 이 중 5.15와 5.10은 2026년 12월에 지원이 끝날 예정입니다. 지원이 끝난 브랜치에는 공식 패치가 나오지 않으므로, 패치 버전이 있는 브랜치로 올려야 합니다. 다만 Amazon Linux 2의 4.14, 5.4 커널처럼 배포판이 지원 종료 브랜치에 수정 사항을 직접 백포트한 경우도 있습니다.

RHEL, Ubuntu 등 개별 배포판은 커널 수정 사항을 자체적으로 백포트하므로 공식 커널 버전 번호만으로는 판단할 수 없습니다. 배포판 커널을 쓴다면 각 배포판의 보안 공지를 확인하시기 바랍니다. 아래 배포판별 상태는 2026년 10월 31일 기준이며, 이후 바뀔 수 있습니다.

RHEL / Rocky Linux

레드햇 공지(RHSB-2026-016)와 레드햇 CVE 데이터에 따르면 RHEL 8, 9, 10과 OpenShift Container Platform이 영향을 받고, RHEL 6과 7은 영향을 받지 않습니다. RHEL 8, 9는 실시간 커널(kernel-rt)도 영향을 받습니다. 레드햇은 패치를 서둘러 준비하고 있다고 밝혔으며, 10월 31일 기준 배포된 패치는 없습니다. RHEL CoreOS, OpenStack Platform, Virtualization처럼 RHEL 커널을 쓰는 제품도 영향을 받을 수 있습니다.

레드햇은 심각도를 Critical로 정한 이유로, 인증 없는 원격 공격자가 일반 IPv4 TCP 트래픽만으로 커널 메모리를 손상시키거나 시스템을 즉시 중단시킬 수 있다는 점을 들었습니다. 타이밍에 민감한 취약점이라 임의 코드를 안정적으로 실행하려면 정밀한 힙 제어가 필요하지만, 네트워크 전제 조건이 없고 시스템 불안정 위험이 크다는 판단입니다.

Ubuntu

Ubuntu는 CVSS 9.8(Critical)을 근거로 대응 우선순위를 High로 정했습니다. 26.10, 26.04 LTS, 24.04 LTS, 22.04 LTS는 아직 취약하지만 패치가 들어갈 커널 버전이 정해져 배포를 기다리는 상태이고, 표준 지원이 끝나 Ubuntu Pro 구독으로 보안 패치를 받는 ESM(Expanded Security Maintenance) 릴리스(20.04, 18.04, 16.04)는 취약한 것으로 확인됐지만 아직 패치 일정이 없습니다.

클라우드용 커널(linux-aws, linux-azure, linux-gcp, linux-oracle)은 버전이 따로 나오며, 각 커널의 상태는 Ubuntu CVE-2026-98432 페이지에서 확인할 수 있습니다. 24.04의 HWE 6.14 커널(linux-hwe-6.14)은 지원이 끝나 수정 대상에서 빠졌습니다.

Amazon Linux

Amazon Linux는 10월 24일부터 30일 사이에 Amazon Linux 2와 Amazon Linux 2023의 커널 패키지 7종 모두에 패치를 배포했습니다. 심각도는 다른 곳보다 낮은 Important(CVSS 8.1)로, 공격 복잡도를 높음으로 봤습니다.

Amazon Linux 2023 기본 커널의 패치 버전(6.1.189)은 공식 커널 패치 버전(6.1.190)보다 번호가 낮습니다. 수정 사항을 백포트한 커널이기 때문이며, 버전은 공식 커널 표가 아니라 위 공지와 비교해야 합니다.

Debian, SUSE 등 다른 배포판도 각 배포판의 CVE 트래커에서 상태를 확인하시기 바랍니다.

취약점 분석

근본 원인

취약점은 TCP 연결을 맺을 때 SYN 패킷에 붙어 온 IP 옵션을 다루는 방식에 있습니다. 커널은 SYN에 담긴 IP 옵션(Record Route, Timestamp)을 메모리에 저장해 두고, SYN-ACK 응답을 보낼 때 이 옵션을 응답 패킷의 IP 헤더에 다시 넣습니다. 연결이 맺어지면 커널은 이 옵션 메모리를 복사하지 않고 새로 만든 소켓에 그대로 넘깁니다. 그런데 같은 연결 요청에 대해 재전송된 SYN이 들어오면, 다른 CPU가 SYN-ACK를 다시 만들면서 새 소켓에 넘어간 바로 그 옵션 메모리를 참조합니다. 문제는 SYN-ACK를 다 만들기 전에 공격자가 연결을 끊는 경우입니다. 커널은 연결이 끊기면 새 소켓을 정리하면서 옵션 메모리도 반납(해제)하는데, SYN-ACK를 만들던 CPU는 이 사실을 모른 채 반납된 메모리를 계속 옵션으로 여기고 사용합니다. 반납된 메모리는 커널이 곧바로 다른 용도로 다시 쓸 수 있으므로, 그 자리에 다른 데이터가 들어오면 커널은 그 데이터를 응답 패킷에 실어 내보내거나(커널 메모리 노출) 엉뚱한 위치에 값을 써 넣습니다(메모리 손상). 이것이 메모리 해제 후 사용(Use-After-Free)입니다.

그림 1. 재전송 SYN과 연결 종료가 겹치면 커널이 해제된 옵션 메모리를 사용합니다. CVE 레코드 설명을 바탕으로 단순화했습니다.

재전송 SYN 말고도 같은 문제가 생기는 경우가 하나 더 있습니다. 웹 서버처럼 여러 프로세스가 같은 포트를 함께 열어 두는(SO_REUSEPORT) 서버에서, 프로세스 하나가 내려갈 때 그 프로세스가 받아 둔 연결 요청을 다른 프로세스로 넘겨주는 연결 요청 이전 기능을 켠 경우입니다. 이 기능은 커널 설정 net.ipv4.tcp_migrate_req=1로 켜거나, 요청을 어느 프로세스로 넘길지 정하는 eBPF 프로그램(BPF_SK_REUSEPORT_SELECT_OR_MIGRATE 유형)을 해당 포트에 붙여서 씁니다. 커널은 연결 요청을 다른 프로세스로 넘길 때 요청 정보를 새로 하나 만들지만, IP 옵션은 내용을 복사하지 않고 저장된 위치만 함께 가리키게 합니다. 그래서 넘겨받은 쪽에서 요청을 정리하며 옵션 메모리를 해제해도, 그 전부터 원래 요청으로 SYN-ACK를 보내거나 연결을 만들던 CPU는 반납된 메모리를 계속 쓸 수 있습니다. tcp_migrate_req의 기본값은 0(꺼짐)입니다. 이 값을 바꾸지 않았고 위 eBPF 프로그램도 쓰지 않는 서버는 연결 요청 이전 기능을 악용하는 공격에 해당되지 않습니다. 다만 이런 경우에도 첫번째로 설명한 재전송 SYN을 악용하는 공격에는 그대로 노출됩니다. 수정된 커널은 두 가지 모두 메모리를 RCU 유예 기간이 지난 뒤에 해제하도록 바꿨습니다. IPv6 TCP는 연결을 맺을 때 옵션을 복사해서 새 소켓에 넘기기 때문에, 이번 취약점의 영향을 받지 않습니다. 두번째 취약점은 IPv6에도 비슷한 문제가 있지만 CALIPSO 보안 레이블을 쓰는 경우에만 해당하며, 리눅스 커널 개발팀은 이를 별도 패치로 고칠 예정이라고 밝혔습니다.

이 취약점을 악용한 공격이 성공하려면 SYN-ACK를 만드는 처리와 연결이 끊겨 소켓이 해제되는 처리가 정확한 시점에 겹쳐야 하므로, 공격자는 같은 시도를 여러 번 반복합니다. 다만 재전송 SYN과 연결 종료는 모두 공격자가 패킷을 보내 직접 일으킬 수 있습니다. 서버에서 특정 상황이 우연히 생기기를 기다릴 필요 없이 공격자가 원하는 만큼 시도할 수 있기 때문에, 리눅스 커널 개발팀은 공격 복잡도를 낮음(AC:L)으로 평가했습니다.

IPv4 패킷의 IP 헤더는 기본 길이가 20바이트입니다. 헤더가 20바이트보다 길다면 그 뒤에 IP 옵션이 붙어 있다는 뜻이고, 이번 공격에 쓰이는 경로 기록(Record Route)과 시간 기록(Timestamp)이 바로 이 IP 옵션입니다. 웹, SSH, syslog 같은 일반적인 TCP 통신은 IP 옵션을 쓰지 않으므로 IP 헤더가 20바이트를 넘는 일이 거의 없습니다. 대응 방안의 차단 규칙은 이 점을 이용해 IP 헤더가 20바이트를 넘는 TCP 패킷을 모두 버리고, 공격에 필요한 IP 옵션이 붙은 패킷을 걸러 냅니다. MSS, 윈도 크기 조정처럼 TCP 연결에 흔히 쓰는 옵션은 IP 헤더가 아니라 TCP 헤더에 들어가므로 이 규칙에 걸리지 않습니다.

그림 2. IPv4 헤더 구조입니다. IP 헤더 길이(IHL)가 5보다 크면 IP 옵션이 붙은 패킷입니다.

원격 코드 실행 취약점 성공 조건

앤스로픽은 MPTCP 리스너가 열린 서버에서 이 취약점으로 원격에서 root 권한으로 명령어를 실행하는 개념 증명(PoC)을 공개했습니다. 공격은 두 단계로 이뤄집니다.

먼저 공격자는 커널이 메모리 어디에 놓여 있는지 알아냅니다. 리눅스 커널은 부팅할 때마다 커널 코드가 놓이는 주소를 무작위로 바꾸므로(KASLR), 원하는 코드를 실행하려면 이 주소부터 알아야 합니다. 공격자는 경합을 일으켜 커널이 공격자가 조작한 길이 값을 옵션 길이로 쓰게 만들고, 그 결과 커널은 원래보다 많은 메모리를 응답 패킷에 담아 보냅니다. 이렇게 흘러나온 메모리에 커널 내부를 가리키는 주소 값이 하나라도 섞여 있으면, 그 값으로 커널 전체가 놓인 위치를 계산할 수 있습니다.

다음으로 공격자는 커널의 실행 흐름을 빼앗습니다. 같은 Use-After-Free로 버퍼를 넘치게 해, 커널이 나중에 호출할 함수의 주소(콜백 포인터)를 덮어씁니다. 덮어쓴 주소는 공격자가 일반적인 프로토콜 기능으로 미리 커널 메모리에 올려 둔 데이터를 가리킵니다. 커널이 그 콜백을 호출하면 기존 커널 함수가 차례로 실행되고, 마지막에 공격자가 지정한 명령어가 root 권한으로 실행됩니다.

PoC에서는 커널이 메모리 어디에 놓여 있는지 알아내는 첫 단계에 약 48분, 명령을 실행하는 두 번째 단계에 약 5분이 걸려 모두 약 53분이 걸렸습니다. 경합에 실패하면 해당 연결의 핸드셰이크만 실패하고 서버는 멈추지 않기 때문에, 공격자는 자동화 도구로 성공할 때까지 계속 시도할 수 있습니다.

Go 보안팀은 oss-security 공지에서 버그 자체가 MPTCP에 한정되지 않는다고 밝혔습니다. MPTCP 리스너가 없다고 해서 비슷한 공격에서 안전하다고 볼 수는 없습니다.

그림 3. MPTCP 연결은 TCP 서브플로우 여러 개로 이뤄집니다. 공개된 PoC는 MPTCP 리스너가 있는 서버를 대상으로 했습니다.

공격 성공 시 영향

• 서비스 거부: 커널 메모리가 손상되면 서버가 바로 멈춥니다. 로그 수집 서버라면 멈춘 동안 들어온 로그를 잃습니다.
• 커널 메모리 노출: SYN-ACK 응답에 커널 힙 메모리 내용이 섞여 공격자에게 전달됩니다.
• 원격 코드 실행: MPTCP 리스너가 있는 서버에서는 root 권한으로 임의의 명령어가 실행될 수 있습니다.

탐지 방안

1. 취약 자산 식별

운영 중인 리눅스 서버마다 배포판과 커널 버전을 확인하고, 위 배포판별 패치 버전과 비교합니다. kernel.org 커널을 직접 빌드해 쓴다면 uname -r 결과를 위 공식 커널 패치 버전 표와 비교하면 됩니다.

# 배포판·커널 버전 확인
cat /etc/os-release
uname -r

# RHEL/Rocky: 구동 중인 커널에 수정이 반영됐는지 확인 (결과가 1 이상이면 패치된 커널)
rpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-2026-98432

# Amazon Linux: 구동 중인 커널 버전을 위 Amazon Linux 표의 패치 버전과 비교
rpm -q kernel

# Ubuntu: 설치된 커널 패키지 버전을 위 Ubuntu 표의 패치 버전과 비교
dpkg -l 'linux-image-*' | grep ^ii

2. MPTCP 리스너·연결 요청 이전 설정 확인

원격 코드 실행이 실증된 MPTCP 리스너가 있는지, 연결 요청 이전 기능이 켜져 있는지 확인합니다.

# MPTCP 활성화 여부 (1이면 활성, 키가 없다는 오류면 MPTCP 미탑재 커널)
sysctl net.mptcp.enabled

# MPTCP 리스너 목록
ss -lnM

# 연결 요청 이전 설정 (기본값 0, 1이면 연결 요청 이전 기능을 악용하는 공격에도 노출)
sysctl net.ipv4.tcp_migrate_req

# 포트에 붙은 SO_REUSEPORT용 eBPF 프로그램 확인 (출력이 없으면 해당 없음, bpftool 패키지 필요)
bpftool prog show | grep sk_reuseport

3. IP 옵션 패킷 유입 확인

정상 운영 환경에서는 IP 옵션이 붙은 TCP 패킷이 거의 들어오지 않습니다. 같은 출발지에서 짧은 시간에 이런 패킷이 반복해 들어온다면 공격 시도를 의심해 볼 수 있습니다.

# IP 헤더 길이가 20바이트를 넘는 TCP 패킷 캡처
tcpdump -ni any 'ip and tcp and (ip[0] & 0x0f) > 5'

대응 방안 1의 차단 규칙을 적용한 뒤에는 차단 기록으로 시도 여부를 확인할 수 있습니다. 방식 A, B는 차단한 패킷을 IPOPT-TCP-DROP 접두어로 커널 로그에 남기고, 방식 C(레드햇 규칙)는 차단한 패킷 수를 카운터로 셉니다.

# 방식 A, B
journalctl -k | grep IPOPT-TCP-DROP

# 방식 C
nft list table inet cve_2026_98432

4. 비정상 재부팅·커널 오류 확인

공격이 서비스 거부로 이어졌다면 커널 오류 기록이나 예정에 없던 재부팅 이력이 남습니다.

# 이전 부팅의 커널 오류 기록
journalctl -k -b -1 -p err

# 재부팅 이력
last -x reboot | head

대응 방안

1과 2는 막는 방법이 다르므로 함께 적용하시기 바랍니다. IP 옵션 차단은 모든 TCP 포트로 들어오는 공격 패킷을 거르고, MPTCP 비활성화는 원격 코드 실행 취약점에 악용된 MPTCP 리스너를 닫아 원격 코드 실행 위험을 줄입니다. 둘 다 임시 조치이므로 커널 패치가 나오면 커널을 업데이트해야 합니다.

1. IP 옵션 TCP 패킷 차단

레드햇은 보안 공지에서 IP 옵션이 붙어 IP 헤더 길이가 5워드(20바이트)를 넘는 IPv4 TCP 패킷을 버리는 nftables 규칙을 완화책으로 제시했습니다. TCP 옵션은 IP 헤더가 아니라 TCP 헤더에 실리므로 일반적인 애플리케이션 트래픽은 영향을 받지 않을 것으로 봤습니다. 다만 레드햇은 이 규칙이 노출을 줄일 뿐 공격을 완전히 막지는 못하고, 필요한 업무 트래픽을 끊을 수도 있으므로 운영 환경에 넣기 전에 시험 환경에서 먼저 확인하라고 안내했습니다.

방식 C는 레드햇이 공지에 실은 규칙을 그대로 쓴 것입니다. 방식 A, B는 같은 조건을 firewalld와 iptables로 옮기고 차단 기록을 초당 10건까지 커널 로그에 남기도록 한 것으로, 커널이 IP 옵션을 처리하기 전 단계인 PREROUTING(raw 우선순위)에 넣습니다.

그림 4. 차단 규칙은 IP 옵션이 붙은 TCP 패킷을 TCP 처리 단계에 닿기 전에 버립니다. 처리 순서는 단순화했습니다.

CIPSO 레이블 네트워크(SELinux/Smack NetLabel)를 쓰는 서버는 정상 트래픽에도 IP 옵션이 들어 있고, 방식 A, B를 다른 장비의 트래픽을 라우팅하는 서버에 넣으면 그 트래픽까지 차단됩니다. 이런 서버는 영향을 확인한 뒤 적용하시기 바랍니다.

서버에서 동작 중인 방화벽 관리 도구(firewalld, iptables, nftables)를 아래 순서로 확인하고, 그에 맞는 방식 하나만 적용합니다. 여러 방식을 섞으면 나중에 확인하고 제거하기가 어려워집니다.

1. systemctl is-active firewalld 결과가 active → 방식 A
2. 그 외, systemctl is-active iptables 결과가 active → 방식 B
3. 그 외 → 방식 C

방식 A. firewalld (RHEL/Rocky 8 이상 기본)

firewall-cmd --permanent --direct --add-rule ipv4 raw PREROUTING 0 -p tcp -m u32 --u32 "0>>24&0xF=6:15" -m limit --limit 10/sec -j LOG --log-prefix "IPOPT-TCP-DROP "
firewall-cmd --permanent --direct --add-rule ipv4 raw PREROUTING 1 -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROP
firewall-cmd --reload
firewall-cmd --direct --get-all-rules

방식 B. iptables-services

두 명령 모두 1번 위치에 넣기 때문에, 순서대로 실행하면 로그 규칙이 차단 규칙 앞에 놓입니다.

iptables -t raw -I PREROUTING 1 -p tcp -m u32 --u32 "0>>24&0xF=6:15" -j DROP
iptables -t raw -I PREROUTING 1 -p tcp -m u32 --u32 "0>>24&0xF=6:15" -m limit --limit 10/sec -j LOG --log-prefix "IPOPT-TCP-DROP "
service iptables save

방식 C. nftables (레드햇 공지 규칙)

규칙 파일을 만든 뒤 문법을 먼저 검사하고 적용합니다. 마지막 두 줄은 재부팅 뒤에도 규칙이 유지되도록 등록하는 명령입니다.

cat > /etc/nftables/cve-2026-98432.nft <<'EOF'
table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}
EOF
nft --check --file /etc/nftables/cve-2026-98432.nft
nft --file /etc/nftables/cve-2026-98432.nft
nft list table inet cve_2026_98432
echo 'include "/etc/nftables/cve-2026-98432.nft"' >> /etc/sysconfig/nftables.conf
systemctl enable nftables

systemctl restart nftables는 서버의 nftables 규칙 전체를 초기화하므로 실행하지 않습니다.

적용 후 확인

1. 규칙이 들어갔는지 확인합니다. 방식 A, B는 iptables -t raw -L PREROUTING -v -n으로 로그 규칙이 차단 규칙 앞에 있는지 보고, 방식 C는 nft list table inet cve_2026_98432로 차단 규칙을 봅니다.
2. 웹 콘솔, SSH, TCP syslog 수신 등 서버의 주요 서비스가 정상 동작하는지 확인합니다.
3. (선택) 다른 장비에서 nping --tcp -p 443 --ip-options R <서버 IP>를 보낸 뒤, 1단계의 명령으로 차단 규칙의 패킷 카운터가 늘었는지 확인합니다.

규칙 제거

커널 패치를 적용했거나 통신 장애가 생기면 규칙을 제거합니다. 이 규칙 때문에 생기는 장애는 접속 거부가 아니라 타임아웃으로 나타납니다.

• 방식 A: 추가 명령의 --add-rule을 --remove-rule로 바꿔 실행한 뒤 firewall-cmd --reload를 실행합니다.
• 방식 B: 추가 명령의 -I PREROUTING 1을 -D PREROUTING으로 바꿔 실행한 뒤 service iptables save를 실행합니다.
• 방식 C: nft delete table inet cve_2026_98432를 실행하고, /etc/sysconfig/nftables.conf의 include 줄과 /etc/nftables/cve-2026-98432.nft 파일을 삭제합니다.

2. MPTCP 비활성화

MPTCP를 끄면 공개된 원격 코드 실행 공격에 필요한 MPTCP 리스너가 사라집니다. 커널 패치나 재부팅 없이 바로 적용되고, MPTCP를 쓰지 않는 서비스에는 영향이 없습니다. MPTCP 기본값은 배포판마다 다릅니다. 공식 커널(kernel.org)은 기본값이 켜짐(1)이고, 이를 그대로 따르는 Ubuntu와 Amazon Linux도 켜져 있습니다. 레드햇은 자체 패치로 기본값을 꺼짐(0)으로 바꿨기 때문에 RHEL 8, 9, 10과 이를 다시 빌드한 Rocky Linux 8, 9, 10은 꺼져 있습니다. Ubuntu 20.04나 Amazon Linux 2의 4.14, 5.4 커널처럼 MPTCP가 들어가기 전 커널에는 이 설정이 없습니다.

기본값이 켜진 배포판에서는 아래 절차로 MPTCP를 끄고, 꺼진 배포판에서도 같은 절차로 그 상태를 고정해 둡니다.

sysctl net.mptcp.enabled
echo "net.mptcp.enabled=0" > /etc/sysctl.d/99-disable-mptcp.conf
sysctl -p /etc/sysctl.d/99-disable-mptcp.conf

첫 명령에서 키가 없다는 오류가 나오면 MPTCP가 없는 커널이므로 이 조치는 필요 없습니다. 설정 파일 이름을 99-로 시작하는 것은 다른 설정 파일보다 나중에 적용되게 하기 위해서입니다.

첫 명령의 결과가 1이었다면 이 설정은 새로 여는 소켓에만 적용되므로, ss -lnM으로 MPTCP 리스너를 찾아 해당 서비스를 재시작해야 합니다.

Go로 만든 프로그램은 MPTCP를 기본으로 쓸 수 있습니다. 서버 전체 설정을 바꾸기 어렵다면 GODEBUG=multipathtcp=0으로 프로그램별로 끌 수 있지만, Go 보안팀은 MPTCP 리스너가 하나만 남아도 서버가 취약하므로 이 방법은 불완전하다고 밝혔습니다.

커널 패치 뒤에도 이 설정은 그대로 유지해도 됩니다.

3. 커널 업데이트

패치가 나오면 바로 적용하고, 그 전까지는 1, 2 조치를 유지합니다.

• RHEL: 레드햇 보안 공지(RHSB-2026-016, RHSA)에서 패치 배포 여부를 확인합니다.
• Rocky Linux: Rocky Linux 보안 공지(RLSA)에서 패치 배포 여부를 확인합니다. Rocky Linux 8은 최신 마이너 버전(8.10)에만 보안 패치를 제공하므로, 8.6 등 이전 버전은 8.10으로 올려야 패치를 받을 수 있습니다.
• Amazon Linux: 패치가 이미 나와 있습니다. Amazon Linux 2023은 dnf upgrade --releasever=latest, Amazon Linux 2는 yum update kernel로 설치하고 재부팅합니다. 패치된 커널을 설치했다면 1, 2 조치는 필요 없습니다.
• Ubuntu: Ubuntu CVE 페이지의 상태가 배포 전(pending)에서 배포됨(released)으로 바뀌고 보안 공지(USN)가 나오면, apt update && apt full-upgrade로 패치된 커널을 설치하고 재부팅합니다.
• 그 외 배포판: 각 배포판의 보안 공지를 따릅니다.

재부팅하는 동안 서비스가 잠시 멈추게 됩니다. RHEL/Rocky 기준 절차는 다음과 같습니다.

1. 서버를 백업합니다.
2. dnf upgrade로 패치된 커널을 설치합니다.
3. 서버를 재부팅합니다.
4. rpm -q --changelog kernel-core-$(uname -r) | grep -c CVE-2026-98432 결과가 1 이상인지 확인합니다.
5. 주요 서비스가 정상 동작하는지 확인합니다.
6. (선택) 대응 방안 1의 차단 규칙을 제거합니다.

참고 자료

• CVE-2026-98432 (CVE.org)
• 리눅스 커널 수정 커밋 e3f33b0a1d89
• CVE-2026-98432 (NVD)
• 레드햇, CVE-2026-98432
• 레드햇, RHSB-2026-016
• Ubuntu, CVE-2026-98432
• Amazon Linux Security Center, CVE-2026-98432
• oss-security, Go 보안팀 공지 (2026-10-30)
• 앤스로픽, Discovering vulnerabilities with Claude
• 리눅스 커널 문서, MPTCP Sysfs variables
• 레드햇, RHEL 9: Getting started with Multipath TCP
• 레드햇, RHEL 8: Getting started with Multipath TCP