CVE-2026-98432: '패치했어요'로 끝내면 안 되는 이유와 점검법

왜 지금 조치해야 하나요

한 줄 답: 공격자에게 서버 계정이 필요 없고, 서버가 멈추거나 그보다 나쁜 일이 생길 수 있습니다. 그리고 “업데이트했다”와 “조치됐다” 사이에는 재부팅이라는 빈틈이 있습니다.

이 취약점으로 생길 수 있는 일

2026년 10월 15일 공개됐습니다. 접속을 받는 TCP 연결 처리(IPv4)에서, 이미 지운 메모리를 다시 쓰는 문제(use-after-free)가 생길 수 있습니다.

• 누가 공격할 수 있나: 서버에 접속만 할 수 있으면 됩니다. 아이디·비밀번호가 필요 없습니다. 홈페이지, 쇼핑몰, 업무 시스템처럼 외부 접속을 받는 서버가 대상입니다.
• 바로 생길 수 있는 피해 — 서버 멈춤: Red Hat은 인증 없는 외부 공격자가 일반 TCP 접속만으로 커널을 즉시 멈추게 하거나 메모리를 망가뜨릴 수 있다고 밝혔습니다. 서버가 멈추면 그 위의 홈페이지·주문·업무 시스템이 함께 멈춥니다.
• 최악의 경우 — 메모리 유출·변조·원격 코드 실행: 커널 보안팀은 서버 메모리 내용이 공격자에게 새어 나가거나 메모리가 변조될 수 있다고 보고 위험도를 9.8(치명적, 10점 만점)로 매겼습니다. Red Hat 보안 공지는 원격 코드 실행까지 가능하다고 적었습니다. 다만 접속 요청의 타이밍을 정밀하게 맞춰야 합니다.
• 기관별 평가: 처음에 ’보통(Moderate)’으로 매겼던 Red Hat도 ‘치명적(Critical)’, 9.8로 올렸습니다(10월 31일 확인). Amazon Linux는 ‘중요(Important)’, 8.1로 봅니다. 어느 쪽이든 수정판 적용이 답입니다.

가상 시나리오: “자동 업데이트 켜져 있어서 괜찮습니다”

① 공개 다음 날. 직원 8명이 운영하는 온라인 꽃집 ‘A플라워’. 홈페이지와 주문 시스템은 Ubuntu 24.04 서버 한 대에서 돌고, 관리는 외주업체가 맡고 있습니다. 대표가 뉴스를 보고 묻자 업체는 이렇게 답합니다. “자동 업데이트가 켜져 있어서 수정판이 나오면 알아서 깔립니다.”

② 3주 뒤. Ubuntu가 수정판을 내놓고, 자동 업데이트가 밤사이 새 커널을 설치합니다. 여기까지는 업체 말이 맞습니다. 하지만 Ubuntu 자동 업데이트는 기본 설정에서 서버를 재부팅하지 않습니다. 새 커널은 디스크에만 있고, 서버는 여전히 예전 커널로 돌고 있습니다. 서버 안에는 “재부팅 필요” 표시 파일이 생겼지만, 아무도 보지 않습니다.

③ 빼빼로데이 전날 저녁. 1년 중 주문이 가장 몰리는 날입니다. 누군가 이 서버에 조작한 접속 요청을 반복해서 보냅니다. 로그인도 필요 없습니다. 밤 9시쯤 커널이 멈추고, 서버는 응답 없이 멈춘 채로 있습니다. 퇴근 시간이 지나 아무도 눈치채지 못하고, 주문 페이지는 밤새 열리지 않습니다.

④ 다음 날 아침. 고객 문의 전화로 장애를 안 업체가 서버를 재부팅합니다. 서버는 그제야 3주 전에 설치돼 있던 새 커널로 켜지고, 같은 공격은 더는 통하지 않습니다. 재부팅 한 번이면 3주 전에 막을 수 있었던 일입니다.

⑤ 남은 것. 대목 하루치 주문, 환불·사과 문자, 단골의 신뢰. 그리고 더 나쁜 가능성도 남습니다. 커널 보안팀의 최악 시나리오대로라면, 서버가 멈추기 전에 메모리 속 정보(주문자 정보가 섞여 있을 수 있음)가 새어 나갔을 수도 있습니다. 확인할 방법이 없다는 것이 더 큰 문제입니다.

이 이야기에서 업체는 거짓말을 하지 않았습니다. “업데이트했다”는 맞았고, “조치됐다”가 틀렸을 뿐입니다. 이 글의 점검 스크립트는 바로 그 차이(설치는 됐는데 재부팅 전인 상태)를 잡아내도록 만들었습니다.

실제로도 있었던 일: 패치 지시만 하고 확인하지 않은 대가

가상 이야기만은 아닙니다. 미국 연방거래위원회(FTC) 발표에 따르면, 신용평가사 Equifax는 2017년 3월 심각한 취약점 경고를 받고 48시간 안에 패치하라고 지시했지만, 실제로 됐는지 확인하지 않았습니다. 빠진 시스템 하나를 7월에야 발견했고, 그 사이 약 1억 4,700만 명의 개인정보가 유출됐습니다. 2019년 합의금은 최소 5억 7,500만 달러(최대 7억 달러)였습니다. 리눅스 커널 취약점은 아니었지만, “지시”와 “확인” 사이의 빈틈이라는 점은 같습니다.

조치하지 않으면 생길 수 있는 손해

손해	근거
서버가 멈춰 홈페이지·주문·업무 시스템 중단	Red Hat: 인증 없는 외부 공격자가 즉시 일으킬 수 있음
서버 메모리 정보 유출, 시스템 변조	커널 보안팀·Red Hat이 9.8을 매긴 최악의 시나리오(Red Hat 공지는 원격 코드 실행 가능성까지 언급)
수정판을 미룬 사이 공격 도구가 나올 위험	같은 계열 커널 취약점 CVE-2024-1086은 공개 넉 달 뒤 실제 악용 목록에 올랐고, 랜섬웨어에 쓰인 것으로 표시됨(CISA)
사고 후 비용·신뢰 손실	Equifax: 확인 누락 하나로 최소 5억 7,500만 달러 합의

할 일은 단순합니다. 내 서버 배포판의 수정판을 확인하고, 설치하고, 재부팅하고, 다시 확인합니다. 아래에 그 방법을 순서대로 정리했습니다.

이런 분께 / 준비물

이런 분께 맞습니다.

• 클라우드(AWS, 네이버 클라우드 등), VPS, 사내 서버에서 리눅스를 쓰는 분
• 서버를 외주·호스팅 업체에 맡겨 직접 만질 수 없는 분
• “패키지만 올리면 끝인지” 헷갈리는 분

준비물

• 서버에 접속할 수 있는 터미널(SSH). 직접 접속할 수 없다면 3단계 문의 템플릿만 있으면 됩니다.
• 설치할 프로그램은 없습니다.

1단계: 내 서버 배포판의 수정 버전부터 찾습니다

판정 기준은 커널 숫자가 아니라 배포판의 수정 패키지 버전입니다. 같은 수정이라도 배포판마다 번호가 다릅니다.

각 배포판 공식 보안 페이지를 2026-10-31에 다시 확인해 옮김. 상태는 바뀌므로 표의 '확인할 곳'을 다시 보세요

배포판	2026-10-31 상태	수정 패키지(있을 때)	확인할 곳
Debian 12 (bookworm)	수정판 있음	6.1.190-1	Debian 보안 트래커
Debian 13 (trixie)	수정판 있음	6.12.113-1	Debian 보안 트래커
Ubuntu 22.04 / 24.04 / 26.04	준비 중	24.04는 6.8.0-149.149 예정	Ubuntu CVE 페이지
Ubuntu 20.04 이하	취약(수정 일정 표시 없음)	아직 없음	Ubuntu CVE 페이지
Amazon Linux 2023	수정판 있음(kernel·kernel6.12·kernel6.18)	ALAS2023-2026-3365 · 3335 · 3251	Amazon Linux 보안 센터
Amazon Linux 2	수정판 있음(기본 kernel, 5.4·5.10·5.15 Extra 커널은 공지 별도)	ALAS2-2026-4065	Amazon Linux 보안 센터
RHEL 8 / 9 / 10	영향 있음, 수정판 준비 중	아직 없음	Red Hat CVE 페이지 · 보안 공지 RHSB-2026-016
RHEL 6 / 7	해당 없음	-	Red Hat CVE 페이지

• 원래 커널(upstream) 기준으로는 4.4부터 영향이 있고, 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3에서 고쳐졌습니다. 배포판을 거치지 않고 커널을 직접 빌드해 쓰는 경우에만 이 숫자를 씁니다.
• Rocky Linux, AlmaLinux 같은 RHEL 호환 배포판은 각자 공지를 냅니다. 이 글에서는 상태를 확인하지 않았습니다.

2단계: 서버에서 3가지를 확인합니다

서버에서 확인할 것은 3가지입니다. 설치된 커널이 수정판인지, 대기 중인 업데이트가 있는지, 지금 그 커널로 돌고 있는지입니다.

아래 캡처는 제 PC의 테스트용 컨테이너에서 찍었습니다. docker exec 컨테이너이름 뒤에 있는 부분이 서버에서 그대로 치는 명령입니다.

업데이트 후보 확인 (Debian·Ubuntu)

sudo apt update
apt-cache policy linux-image-amd64     # Ubuntu는 linux-image-generic 등

Installed가 설치된 버전, Candidate가 받을 수 있는 버전입니다. 후보가 1단계 표의 수정 버전과 같거나 높으면 업데이트로 해결됩니다. Red Hat 계열은 sudo dnf check-update 'kernel*'로 봅니다.

실행 중인 커널이 수정판인지: 변경 기록에서 CVE 번호 찾기

# Debian·Ubuntu
zcat /usr/share/doc/linux-image-$(uname -r)/changelog*.gz | grep -B1 CVE-2026-98432
# Red Hat 계열
rpm -q --changelog kernel-core-$(uname -r) | grep CVE-2026-98432

아무것도 안 나오면 아직 수정판이 아니거나, 배포판이 변경 기록에 번호를 적지 않은 경우입니다. 그때는 1단계 표의 버전 비교로 판단합니다.

재부팅 확인

uname -r                 # 지금 실행 중인 커널
ls /boot/vmlinuz-*       # 설치된 커널 목록

실행 중인 커널이 목록에서 가장 높은 버전과 다르면, 새 커널을 설치만 하고 재부팅하지 않은 상태입니다. 커널은 재부팅해야 바뀝니다.

• Debian은 보안 업데이트에서 이름(6.1.0-54-amd64)을 그대로 두고 내용만 바꾸기도 합니다. 이름이 같아도 uname -v의 Debian 6.1.190-1 부분이 설치된 패키지 버전과 다르면 재부팅 전입니다.
• Ubuntu는 /var/run/reboot-required 파일이 있으면 재부팅이 필요하다는 뜻입니다.
• Red Hat 계열은 sudo dnf needs-restarting -r로 확인합니다.

한 번에 보기: 읽기 전용 점검 스크립트

위 확인을 한 번에 하는 스크립트를 내려받을 수 있습니다. 서버의 정보를 읽어 출력만 하고, 아무것도 설치하거나 바꾸지 않습니다. 실행 전에 내용을 열어 확인해 보세요.

sh check-cve-2026-98432.sh

줄	뜻	볼 것
[2] Running kernel	지금 실행 중인 커널	[3]과 같은지
[3] Newest installed	설치된 가장 새 커널과 패키지 버전	1단계 수정 버전 이상인지
[4] Reboot needed?	새 커널을 설치하고 아직 재부팅하지 않았는지	YES면 재부팅
[5] CVE in changelog	설치된 커널 변경 기록에 이 CVE가 있는지	yes면 수정판 설치됨
[6] Kernel updates	받을 수 있는 커널 업데이트	있으면 업데이트
[7] tcp_migrate_req	두 번째 문제 경로와 관련된 설정값	참고용
[8] Fixed version	내 배포판 보안 페이지 주소	수정 버전 확인

• [7]은 참고용입니다. 이 값이 0이어도 첫 번째 문제(재전송된 접속 요청과의 경쟁)는 그대로 남습니다. 0이라서 안전하다는 뜻이 아닙니다.
• 컨테이너 안에서 돌리면 [2]에 PC나 호스트의 커널이 나오고, [4]는 “n/a”로 나옵니다. 반드시 서버 자체에서 실행하세요.

3단계: 결과별로 할 일

Debian·Ubuntu·Red Hat 공식 보안 페이지(2026-10-31)를 바탕으로 정리

확인 결과	서버를 직접 운영	업체에 맡김
수정판 설치 + 재부팅 완료	끝. 다른 서버도 같은 방법으로 확인	업체 답변으로 확인
수정판 설치, 재부팅 전	작업 시간을 잡아 재부팅	재부팅 일정 요청
수정판이 업데이트 후보에 있음	업데이트 → 재부팅 → 다시 점검	문의 템플릿으로 적용 요청
배포판이 아직 수정판을 안 냄	보안 페이지를 지켜보고 나오면 바로 적용	적용 예정일 문의

• 수정판을 기다리는 동안 쓸 임시 완화책은 Red Hat 보안 공지 RHSB-2026-016에 있습니다. IP 옵션이 붙은 IPv4 TCP 패킷을 nftables 방화벽에서 버리는 규칙입니다.
• Red Hat은 이 규칙이 노출을 줄일 뿐 완전히 막지는 못하고, 필요한 통신을 끊을 수도 있다고 적었습니다. 운영 서버에 넣기 전에 시험 환경에서 확인하라고 권합니다. 수정 커널이 나오면 규칙을 지우고 업데이트하는 것이 유일한 완전한 해결입니다.
• 이 글에서는 공식 문서에 없는 우회 설정은 권하지 않습니다.
• 업체에 맡겼다면 “패치했나요?“보다 실행 중 커널 버전, 수정 패키지 버전, 재부팅 여부를 물어야 확인할 수 있는 답이 옵니다. 이 내용을 담은 문의 메일 템플릿을 꺾쇠(<>) 부분만 바꿔 보내면 됩니다.

직접 해본 결과: 컨테이너 4개에서 돌린 점검 스크립트

운영 중인 서버를 일부러 예전 커널로 되돌릴 수는 없어서, 제 PC의 Docker에 배포판별 컨테이너를 띄워 커널 패키지를 설치하고 같은 스크립트를 돌렸습니다.

Docker Desktop 29.4.0, 공식 이미지 debian:12·ubuntu:24.04·rockylinux:9에 커널 패키지만 설치, 각 1회 실행

컨테이너	설치한 커널 패키지	[5] 변경 기록에 CVE	[6] 대기 중인 커널 업데이트
Debian 12 (수정 전 버전 지정)	6.1.176-1	no	linux-image-amd64
Debian 12 (최신)	6.1.190-1	yes	없음
Ubuntu 24.04 (최신)	6.8.0-147.147	no	없음
Rocky Linux 9 (최신)	kernel-core 5.14.0-687.61.1.el9_8	no	없음

• Debian은 보안 저장소 업데이트만으로 수정판이 들어왔고, 변경 기록에서도 CVE 번호를 바로 찾을 수 있었습니다.
• Ubuntu 24.04는 최신 상태로 맞춰도 no였습니다. “업데이트 다 했는데요”라는 답만으로는 부족한 이유입니다.
• Rocky 9 결과는 이 날짜에 받은 패키지 기준일 뿐이며, Rocky의 공식 수정 상태를 뜻하지 않습니다.

주의할 점과 한계

• 컨테이너는 서버(호스트)의 커널을 빌려 씁니다. 그래서 위 캡처의 [2] 실행 중 커널은 제 PC(WSL2)의 커널이고, 재부팅 판정은 실제 서버에서만 의미가 있습니다. Docker를 쓰는 서버라면 컨테이너가 아니라 호스트를 업데이트해야 합니다.
• 배포판별 상태는 2026년 10월 31일 기준입니다. Ubuntu와 Red Hat은 곧 바뀔 수 있으니 1단계 표의 공식 페이지를 다시 확인하세요.
• 위험도 점수는 기관마다 다릅니다(커널 보안팀·Red Hat 9.8 ‘치명적’, Amazon Linux 8.1 ‘중요’). 어느 쪽이든 할 일은 같습니다. 수정판이 나오면 적용하고 재부팅합니다.