인터넷 서버의 ‘첫 인사’에 9.8점 구멍? 리눅스 커널 TCP 취약점 CVE-2026-98432로 본 ‘버린 메모를 다시 읽는’ 버그의 원리와 AI가 53분 만에 root를 딴 실험, 우분투 패치 대기 속 서버 담당자가 오늘 할 4단계를 초보도 쉽게

여러분이 오늘 연 웹사이트, 쓰고 있는 앱, 클라우드에 올려 둔 사진. 그 뒤편 서버의 상당수는 리눅스(Linux)라는 운영체제로 돌아가요. 그런데 이 리눅스의 가장 깊은 곳인 커널(kernel)에서, 인터넷 연결이 시작되는 첫 ‘인사’ 단계에 위험도 10점 만점에 9.8점짜리 구멍이 발견됐습니다. 이름은 CVE-2026-98432예요.

이번 일이 특히 화제가 된 이유는 두 가지예요. 첫째, 로그인도 하기 전에 터지는 문제라 비밀번호가 아무리 튼튼해도 소용이 없어요. 둘째, 이 구멍을 제보한 AI 회사 앤트로픽(Anthropic)이 “아직 공개하지 않은 클로드(Claude) 연구용 모델이 서버의 최고 권한(root)을 원격으로 빼앗는 공격 코드를 직접 짰다”고 밝혔거든요. 11월 2일에는 이스트시큐리티와 아카마이 같은 보안 회사들도 잇따라 업데이트 권고를 냈고, 11월 3일 현재 우분투(Ubuntu)는 아직 패치를 준비하고 있어요. 오늘은 “커널이 뭔지”, “인사 단계에서 무슨 일이 생기는지”, “누가 서둘러야 하는지”, “서버 담당자는 오늘 무엇을 하면 되는지”를 초보 눈높이로 하나씩 풀어 볼게요.

구멍은 SYN·SYN-ACK·ACK로 이어지는 TCP ‘3단계 인사’ 처리 코드에 있어요. 로그인·비밀번호 확인보다 먼저 일어나는 단계라 인증이 막아 주지 못해요
구멍은 SYN·SYN-ACK·ACK로 이어지는 TCP ‘3단계 인사’ 처리 코드에 있어요. 로그인·비밀번호 확인보다 먼저 일어나는 단계라 인증이 막아 주지 못해요

한눈에 보는 핵심 정리

항목 내용
이름 CVE-2026-98432 (리눅스 커널 IPv4 TCP 연결 처리 취약점)
위험도 CVSS 9.8 ‘치명적(Critical)’ — 리눅스 커널 CVE 담당 기관·레드햇 기준. 우분투는 ‘높음’, 오라클·아마존은 8.1로 평가
어디에 생긴 구멍? TCP 연결을 맺는 첫 ‘3단계 인사(3-way 핸드셰이크)’ 처리 코드
버그 종류 해제 후 사용(Use-After-Free) — 이미 버린 메모리를 다른 쪽이 계속 읽는 문제
영향 범위 리눅스 커널 4.4 이상, 패치 전 버전 (약 10년 치 커널)
필요한 조건 인증 불필요. IPv4 TCP 포트에 네트워크로 닿기만 하면 시도 가능
실제 공격 11월 1일 기준 실제 악용 보고 없음. 앤트로픽의 공격 코드는 비공개. 깃허브에 ‘PoC 포함’을 주장하는 저장소가 등장(검증 안 됨)
해결책 배포판이 낸 패치 커널 설치 + 반드시 재부팅
집 PC 윈도·맥은 리눅스 커널이 아니라 이번 버그와 무관

먼저, ‘커널’이 뭔가요?

컴퓨터를 하나의 건물로 생각해 볼게요. 우리가 쓰는 웹 서버, 데이터베이스, 앱은 건물에 입주한 가게들이에요. 그리고 커널은 건물 전체를 관리하는 관리사무소입니다. 전기(전원), 엘리베이터(메모리), 출입문(네트워크)을 모두 관리실이 쥐고 있죠.

보통 해킹은 가게 하나(예: 웹사이트 프로그램)를 뚫는 거라 피해가 그 가게에서 멈출 수 있어요. 하지만 관리사무소가 뚫리면 건물 전체의 마스터키를 넘겨주는 셈이에요. 리눅스에서 이 마스터키를 가진 계정을 root(루트)라고 부르는데, 이번 구멍은 최악의 경우 이 root 권한까지 원격으로 넘어갈 수 있다는 점에서 무겁게 다뤄지고 있어요.

컴퓨터 용어 건물 비유 이번 사건에서의 의미
커널 관리사무소 구멍이 생긴 곳. 모든 프로그램보다 높은 권한
애플리케이션(웹 서버·SSH·DB) 입주 가게 가게 문을 열어 두기만 해도(포트 개방) 관리실 출입문이 노출됨
root 권한 마스터키 공격 성공 시 넘어갈 수 있는 최고 권한
포트(port) 건물 출입문 번호 80·443(웹), 22(SSH), 3306(DB) 등 열린 문이 곧 공격 통로
패치 + 재부팅 관리실 자물쇠 교체 후 새 관리자 출근 자물쇠를 사 오기만 하고 안 바꾸면(재부팅 안 하면) 소용없음

인터넷 연결의 ‘3단계 인사’부터 알아볼게요

웹사이트에 접속하면 화면이 뜨기 전에, 내 기기와 서버는 아주 짧은 인사를 세 번 주고받아요. 이걸 TCP 3-way 핸드셰이크라고 부릅니다. 전화를 걸 때 “여보세요?” “네, 들려요” “아, 네!” 하고 서로 확인하는 것과 비슷해요.

순서 이름 전화 비유 서버 안에서 일어나는 일
① SYN “여보세요, 연결할게요” 서버가 ‘대기 명단(요청 소켓)’에 손님을 임시로 적어 둠
② SYN-ACK “네, 들려요” 서버가 대답을 보냄. 손님이 보낸 IP 옵션 메모가 있으면 대답에 반영
③ ACK “확인!” 인사 끝. 서버가 정식 연결(자식 소켓)을 만들고 임시 명단 정보를 넘김
그다음 로그인·데이터 본론 대화 비밀번호 확인 등은 이 다음에야 시작

포인트는 이번 구멍이 ①~③ 인사 단계에 있다는 거예요. 아직 “누구세요?”를 묻기도 전이라, 비밀번호나 2단계 인증이 막아 줄 수 없어요.

구멍의 원리: “버린 메모를 다른 직원이 아직 읽고 있었다”

IPv4 패킷에는 거의 쓰이지 않는 ‘IP 옵션’이라는 덧붙임 칸이 있어요(경로 기록, 시간 기록 같은 것). 손님이 첫 인사(SYN)에 이 옵션을 붙여 보내면, 커널은 대답할 때 쓰려고 그 내용을 따로 메모해 둡니다.

요즘 서버에는 일하는 직원(CPU 코어)이 여러 명 있죠. 문제는 이런 순간이었어요.

한 CPU가 연결을 끝내며 IP 옵션 메모를 바로 버리는 사이, 다른 CPU가 재전송된 인사에 답하려고 그 메모를 계속 읽는 게 문제였어요. 고친 방법은 kfree를 kfree_rcu로 바꾼 4줄 수정이에요
한 CPU가 연결을 끝내며 IP 옵션 메모를 바로 버리는 사이, 다른 CPU가 재전송된 인사에 답하려고 그 메모를 계속 읽는 게 문제였어요. 고친 방법은 kfree를 kfree_rcu로 바꾼 4줄 수정이에요
단계 쉬운 설명 실제 커널 동작
1 손님이 옵션 메모가 붙은 인사를 보냄 IPv4 옵션이 담긴 SYN → 요청 소켓에 옵션(ireq_opt) 저장
2 인사가 끝나 정식 연결로 넘어가면서, 메모를 복사하지 않고 그대로 넘김 tcp_v4_syn_recv_sock()이 포인터만 자식 소켓(inet_opt)으로 이전
3 같은 손님이 첫 인사를 한 번 더 보냄(재전송). 다른 직원 B가 그 메모를 보며 대답 준비 다른 CPU가 재전송된 SYN 처리, RCU 읽기 잠금만 걸고 옵션 읽기
4 그 사이 연결이 끝나 직원 A가 메모를 바로 쓰레기통에 소멸자가 kfree()로 즉시 해제
5 직원 B는 이미 버려진 종이를 계속 읽음 → 엉뚱한 내용을 손님에게 보내거나, 메모리가 망가짐 해제된 메모리 사용(UAF) → 커널 메모리 유출·손상·다운

고친 방법은 놀랄 만큼 단순해요. “모든 직원이 다 읽은 걸 확인한 뒤에 버리기”. 코드로는 kfree()를 kfree_rcu()로 바꾼 4줄 수정이었어요. 리눅스 네트워크 핵심 개발자인 에릭 뒤마제(Eric Dumazet)가 수정을 작성했고, 이 틈은 리눅스 4.4 시절의 한 변경 이후 약 10년 동안 숨어 있었습니다.

지금까지의 흐름 (날짜는 발표 기준)

날짜 있었던 일
10월 5일 리눅스 본가(업스트림)에 수정 코드 반영. 제보자는 앤트로픽 연구원 신양 거(Xinyang Ge)
10월 15일 리눅스 커널 CVE 담당 기관이 CVE-2026-98432로 공개, 9.8점 부여
10월 27일(미국) 앤트로픽이 “AI가 원격 root 공격 코드를 작성했다”고 공개. 코드 자체는 비공개
10월 29일(미국) Go 언어 보안팀이 “Go 1.24부터 리눅스에서 MPTCP가 기본으로 켜진다”며 주의 공지
10월 30일 레드햇이 심각도를 ‘중요’에서 ‘치명적(9.8)’으로 상향. 데비안·SUSE·오라클·아마존 리눅스 패치 배포 시작
11월 2일 이스트시큐리티·아카마이 등 보안업체 분석과 업데이트 권고 공개
11월 3일 현재 우분투는 여전히 ‘작업 중’. 실제 공격 보고는 아직 없음

왜 9.8점이나 될까? AI가 53분 만에 ‘마스터키’를 땄다

‘메모리를 잘못 읽는 버그’라고 하면 서버가 잠깐 멈추는 정도로 들릴 수 있어요. 그런데 앤트로픽의 실험은 훨씬 멀리 나아갔어요. 보도에 따르면 공격은 두 단계였습니다.

  • 1단계(48분): 경쟁 상황을 계속 일으켜 서버가 대답에 커널 메모리 조각을 실어 보내게 만들고, 그 안에서 커널 주소를 찾아내 ‘주소 숨기기(KASLR)’ 방어를 무력화.
  • 2단계(약 5분): 같은 버그로 메모리를 넘치게 해 커널이 나중에 부를 ‘연락처(콜백 포인터)’를 공격자 코드 주소로 바꿔치기 → root로 명령 실행.

무서운 점은 실패해도 티가 잘 안 난다는 거예요. 경쟁에서 지면 그 연결 하나만 실패할 뿐 서버는 멀쩡해서, 공격자는 될 때까지 계속 시도할 수 있어요. 다만 앤트로픽은 공격 코드와 시험한 커널 버전·설정을 공개하지 않았고, 11월 2일 기준 공개된 ‘작동하는’ 공격 코드도 확인되지 않았어요. 지금은 “문이 열린 걸 다들 알게 된 상태”라고 보면 됩니다. 그래서 공격이 퍼지기 전에 패치하는 게 핵심이에요.

MPTCP와 Go 1.24: “나도 모르게 켜져 있을 수 있는 스위치”

앤트로픽이 시연한 공격은 MPTCP(멀티패스 TCP)를 쓰는 서버가 대상이었어요. MPTCP는 휴대폰이 와이파이와 LTE를 동시에 써서 한 연결을 이어 가는 것처럼, 여러 길로 데이터를 나눠 보내는 TCP 확장 기술이에요.

구분 일반 TCP MPTCP
비유 한 차선 도로 여러 차선을 묶어 쓰는 도로
켜는 방법 기본 프로그램이 소켓을 열 때 요청해야 함
이번 시연 공격 원격 코드 실행은 공개 시연되지 않음(그래도 버그 자체는 존재) 원격 root 실행 시연 대상
주의할 점 MPTCP를 꺼도 근본 해결 아님 Go 1.24 이상으로 만든 프로그램은 리눅스에서 기본으로 MPTCP 리스너를 엶

Go는 도커, 쿠버네티스 도구, 각종 API 서버를 만드는 데 많이 쓰이는 언어예요. 그래서 관리자가 MPTCP를 켠 적이 없어도 Go로 만든 서비스 하나가 조용히 켜 두고 있을 수 있어요. Go 보안팀은 GODEBUG=multipathtcp=0 환경 변수나 go.mod의 godebug multipathtcp=0으로 끌 수 있다고 안내하면서도, “프로그램마다 끄는 건 깨지기 쉬운 임시 조치이고, 정답은 커널 패치”라고 강조했어요.

누가 서둘러야 할까?

인터넷에 열린 리눅스 서버, MPTCP가 켜진 서버(Go 1.24 이상 프로그램 주의), 컨테이너·쿠버네티스 노드가 우선 대상이고 집 윈도·맥 PC는 해당 없어요
인터넷에 열린 리눅스 서버, MPTCP가 켜진 서버(Go 1.24 이상 프로그램 주의), 컨테이너·쿠버네티스 노드가 우선 대상이고 집 윈도·맥 PC는 해당 없어요
환경 노출 조건 위험도
인터넷에 직접 열린 리눅스 서버 웹·SSH·메일·DB 등 IPv4 TCP 포트를 바깥에 개방 높음
MPTCP 리스너가 있는 서버 앤트로픽 공격의 대상. Go 1.24+ 프로그램은 기본으로 생성 높음
컨테이너 호스트·쿠버네티스 노드 컨테이너는 호스트 커널을 함께 쓰므로, 컨테이너로 연 포트도 영향 높음
로드밸런서·프록시 뒤 서버 바깥 연결을 앞단에서 끊는 구조(예: AWS ALB)는 노출이 적지만, TCP를 그대로 넘기는 NLB 같은 구조는 뒤 서버까지 영향 중간
집 윈도·맥 PC 리눅스 커널이 아님 해당 없음

개인 블로그를 리눅스 가상 서버(VPS)에 올려 두셨거나, 집에서 리눅스로 작은 서버를 돌리는 분도 “서버 담당자”에 해당해요. 반대로 노트북·데스크톱에서 윈도나 맥만 쓴다면 이번 건으로 할 일은 없어요.

내 서버 커널 버전, 이렇게 읽어요

터미널에서 uname -r을 입력하면 지금 돌아가고 있는 커널 버전이 나와요. 예를 들어 6.12.94가 나왔다면 “6.12 계열의 94번째 수정판”이라는 뜻이에요. 아래 표에서 6.12 계열은 6.12.113 이상이어야 하니, 이 예시는 아직 취약한 범위예요.

커널 계열 취약한 버전 고쳐진 버전
7.3 7.3-rc7 미만 7.3 정식판
7.2 7.2.10 미만 7.2.10 이상 (7.2 계열은 11월 1일 7.2.15로 지원 종료)
6.18 6.18.56 미만 6.18.56 이상
6.12 6.12.113 미만 6.12.113 이상
6.6 6.6.159 미만 6.6.159 이상
6.1 6.1.190 미만 6.1.190 이상
5.15 5.15.223 미만 5.15.223 이상
5.10 5.10.272 미만 5.10.272 이상
4.4 ~ 5.4 전부 본가 수정판 없음 → 배포판 패치로만 해결

주의! 위 숫자는 ‘본가(업스트림)’ 기준이에요. 레드햇·우분투·데비안은 옛 버전 번호에 보안 수정만 덧대는(백포트) 경우가 많아서, 번호만 보고 판단하면 틀릴 수 있어요. 아래 배포판별 표와 각 배포판 보안 공지를 함께 확인하세요.

배포판별 패치 현황 (11월 1~3일 기준)

배포판 상태 참고할 버전·공지
레드햇(RHEL) 배포 RHEL 8.10: kernel-4.18.0-553.182.1 / 9.8: kernel-5.14.0-687.64.1 / 10.2: kernel-6.12.0-211.72.1 (RHEL 6·7은 영향 없음)
데비안 배포 12(bookworm) 6.1.190-1, 13(trixie) 6.12.113-1
SUSE 일부 배포 SLES 16.0·15 SP4~SP6 LTSS 완료, SP7 작업 중
오라클 리눅스 배포 UEK 에라타 배포
아마존 리눅스 배포 AL2·AL2023 패치. AL2023을 특정 릴리스로 고정했다면 2023.12.20261102 이상
알마리눅스 테스트 저장소 테스트 저장소에 패치 커널
우분투 대기(작업 중) 26.10·26.04·24.04·22.04 작업 중, 20.04·18.04·16.04 취약. 패치 전까지 임시 조치 필요

서버 담당자가 오늘 할 4단계

버전 확인, 패치 설치, 재부팅, 임시 방패의 4단계. 컨테이너 이미지가 아니라 호스트 커널을 고쳐야 해요
버전 확인, 패치 설치, 재부팅, 임시 방패의 4단계. 컨테이너 이미지가 아니라 호스트 커널을 고쳐야 해요

1단계 — 지금 돌아가는 커널 확인

uname -r
# 설치된 커널 패키지 보기
dpkg -l 'linux-image*' | grep ^ii     # 데비안·우분투
rpm -q kernel                          # RHEL·Rocky·Alma·아마존 리눅스

컨테이너 안이 아니라 호스트·쿠버네티스 노드에서 확인해야 해요.

2단계 — 패치 커널 설치 / 3단계 — 재부팅

환경 명령 메모
RHEL·Rocky·Alma sudo dnf update kernel → sudo reboot needs-restarting -r로 재부팅 필요 여부 확인
데비안·우분투 sudo apt update && sudo apt full-upgrade → sudo reboot 우분투는 패치가 나오면 실행. 그 전엔 4단계
아마존 리눅스 2 sudo yum update kernel && sudo reboot –
아마존 리눅스 2023 sudo dnf update kernel --releasever=latest && sudo reboot 릴리스 고정 시 2023.12.20261102 이상
컨테이너·쿠버네티스 노드 커널 업데이트 후 재부팅, 관리형은 패치된 노드 이미지로 교체 컨테이너 이미지 재빌드만으론 해결 안 됨

재부팅 후 다시 uname -r을 쳐서 숫자가 바뀌었는지 꼭 확인하세요. 패키지만 깔고 재부팅을 안 하면 예전 커널이 그대로 돌아갑니다.

4단계 — 바로 패치가 어렵다면 임시 방패

# 위험 신호 점검
ss -Mlnp                                       # 결과가 있으면 MPTCP 리스너 동작 중(고위험)
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
임시 조치 방법 주의
MPTCP·요청 이동 끄기 sudo sysctl -w net.mptcp.enabled=0
sudo sysctl -w net.ipv4.tcp_migrate_req=0		 이미 열린 MPTCP 리스너는 서비스 재시작해야 해제. 근본 해결 아님
Go 프로그램 GODEBUG=multipathtcp=0 또는 go.mod에 godebug multipathtcp=0 코드에서 직접 켠 경우엔 무시됨
IP 옵션 붙은 TCP 패킷 차단(nftables) nft add table ip cve_2026_98432
nft add chain ip cve_2026_98432 pre '{ type filter hook prerouting priority -300; }'
nft add rule ip cve_2026_98432 pre meta l4proto tcp ip hdrlength gt 5 counter drop		 재부팅 시 사라짐. CIPSO 보안 레이블 쓰는 망에선 금지
필요 없는 포트 닫기 바깥에 열린 SSH·DB 포트 점검, 접속 허용 IP 제한 공격 표면 자체를 줄이는 기본기

IP 옵션은 일반 인터넷 트래픽에서는 거의 쓰이지 않지만, 사내망에서 쓰는 장비가 있다면 차단 전에 영향부터 확인하세요. 아직 공식 침해 지표(IoC)는 없어서, 원인 모를 커널 패닉이나 재부팅이 반복된다면 로그를 보존하고 패치를 먼저 하는 게 좋아요.

자주 묻는 질문

질문 답
제 윈도 노트북도 업데이트해야 하나요? 이번 건은 리눅스 커널 문제라 윈도·맥과는 무관해요. 다만 평소처럼 OS 업데이트는 켜 두세요.
클라우드에 블로그를 올려 뒀는데요? 리눅스 가상 서버(VPS·EC2 등)라면 서버 주인이 직접 커널을 업데이트하고 재부팅해야 해요. 완전 관리형 서비스라면 업체 공지를 확인하세요.
도커 이미지를 새로 받으면 되죠? 아니요. 컨테이너는 호스트 커널을 함께 쓰기 때문에 호스트 커널을 고쳐야 해요.
MPTCP만 끄면 안전한가요? 공격 경로 하나를 줄일 뿐이에요. Go 보안팀도 버그 자체는 MPTCP 전용이 아니라고 밝혔어요.
IPv6만 쓰면요? 첫 번째 경로는 IPv6에 영향이 없지만, 대부분 서버는 IPv4도 함께 열려 있어요. 결국 패치가 답이에요.
AI가 공격 코드를 짰다는데, 더 위험해진 건가요? AI가 취약점 찾기와 공격 코드 작성을 앞당길 수 있다는 신호예요. 그만큼 “공개 → 공격”까지의 시간이 짧아질 수 있으니, 패치 속도가 더 중요해졌어요.

마무리: 비밀번호보다 먼저 열리는 문

이번 CVE-2026-98432는 로그인보다 먼저 일어나는 ‘인사’ 단계의 구멍이라, 튼튼한 비밀번호도 막아 주지 못해요. 다행히 아직 실제 공격 보고는 없고, 고치는 법도 분명합니다. 버전 확인 → 패치 설치 → 재부팅 → (우분투처럼 패치가 늦다면) 임시 방패. 이 네 가지만 기억하시면 돼요. 리눅스 서버를 하나라도 맡고 계신다면, 오늘 퇴근 전에 uname -r 한 줄부터 쳐 보세요.