기준 시각: 2026-11-10 KST. 이 글은 CVE-2026-98432에 관한 세 번째 글이다. 취약점의 원리는 10/29 글에, 배포판별 대응 원칙은 11/02 글에 정리했다. 이번에는 우분투만 수정 커널이 늦게 나온 경위, 기다리는 동안 할 수 있는 일, 그리고 이 일이 앞으로 무엇을 예고하는지를 다룬다. 공격 방법은 다루지 않는다.

결론부터

  • 버그는 10월 초 upstream에서 고쳐졌다. Debian·RHEL·SUSE·Amazon Linux는 10월 중순~11월 초에 수정 커널을 냈다. 우분투는 수정 커널을 일찍 빌드했지만, 사용자가 실제로 받는 경로로 내보내는 데 몇 주가 걸렸다.
  • 이 글을 쓰면서 Launchpad API로 직접 확인한 결과(11/10 기준):
    • 22.04 LTS: 수정 커널 5.15.0-203.213이 11/09 19:11 UTC(11/10 04:11 KST)에 -security pocket에 들어갔다.
    • 24.04 LTS·26.04 LTS: 수정 커널이 여전히 -updates에만 있다. -security의 최신 커널은 아직 수정 전 버전이다.
  • unattended-upgrades의 기본 설정은 -security만 받는다. 기본 설정으로 자동 업데이트만 돌리는 24.04·26.04 서버는 오늘도 취약한 커널로 돈다.
  • 이번 일은 우분투 하나의 잘못이라기보다 구조의 문제다. AI가 취약점을 찾는 속도는 빨라졌는데, 고친 커널을 시험하고 배포하고 재부팅하는 속도는 그대로다. 병목이 “발견”에서 “전달”로 옮겨 갔다.

1. 무슨 일이 있었나 — 날짜순

날짜 (2026) 일 출처
10/5~6 upstream 수정 커밋(Eric Dumazet). kfree() → kfree_rcu() Akamai 분석
10/15 커널 CNA가 CVE-2026-98432 공개 Ubuntu CVE 페이지
10/15~16 Debian 13·12 수정 커널 Debian 보안 트래커
10/26 우분투 수정 커널이 -proposed(시험용)에 올라감 Launchpad 게시 기록(아래 실측)
10/27 Anthropic이 비공개 연구 모델로 MPTCP 리스너 대상 원격 root 익스플로잇을 만들었다고 발표. 코드는 공개하지 않음 Anthropic
10/29 Go 보안팀이 Go 1.24 이상은 Linux 리스너에서 MPTCP가 기본으로 켜진다고 경고 Go 1.24 릴리스 노트
11/1~2 Red Hat이 RHEL 8·9·10 수정 커널 배포, 등급을 Critical로 올림 Red Hat CVE, RHSB-2026-016
11/2 Canonical 공식 블로그: 22.04 이상 수정본은 -proposed에 있음, 2,000대 이상 인증 장비 시험 뒤 배포 예정, 날짜는 미정 Ubuntu 블로그
11/5~6 22.04·24.04·26.04 수정 커널이 -updates로 승격 Launchpad(아래 실측)
11/9 19:11 UTC 22.04 수정 커널이 -security로 들어감 Launchpad(아래 실측)

upstream 수정부터 22.04의 -security 반영까지 약 5주가 걸렸다. 24.04·26.04는 이 글을 쓰는 시점에도 반영되지 않았다. 같은 기간에 다른 배포판은 이미 수정 커널을 내놓은 상태였고, 우분투 사용자 커뮤니티의 비판도 여기서 나왔다(OMG! Ubuntu, 11/4).

직접 확인한 값 [1차 데이터]

Launchpad 공개 API(getPublishedSources)를 2026-11-10 오전에 직접 조회한 결과다. 시각은 UTC다.

릴리스 수정 커널 -proposed -updates -security
22.04 jammy 5.15.0-203.213 10/26 17:30 11/05 23:22 11/09 19:11
24.04 noble 6.8.0-149.149 10/26 17:30 11/06 01:14 없음 (최신이 6.8.0-147.147, 10/13)
26.04 resolute 7.0.0-43.43 10/28 02:39 11/06 01:14 없음 (최신이 7.0.0-42.42, 11/02)
20.04 focal 미배포 — — 수정본 없음

우분투 CVE 페이지(마지막 갱신 11/9)는 22.04부터 16.04까지 모두 “Vulnerable, work in progress”로 표시한다. 이 CVE를 다루는 USN(Ubuntu Security Notice)은 이 글을 쓰는 시점에 CVE 페이지에서 찾을 수 없었다. 상태 페이지가 아카이브보다 늦다. 내 서버의 상태를 판단할 때는 상태 페이지가 아니라 uname -r과 실제 pocket을 봐야 한다.

2. 왜 늦었나 — pocket이라는 구조

우분투 커널은 세 단계를 거쳐 사용자에게 간다.

pocket 성격 기본으로 받나
-proposed 빌드가 끝나 인증 시험을 기다리는 후보 아니오. 직접 켜고 지정해야 함
-updates 시험을 통과한 일반 업데이트 apt upgrade로 받음. 자동 업데이트 기본값은 아님
-security 보안 업데이트 unattended-upgrades 기본값이 받는 곳

Canonical은 9월 23일에 커널 배포 주기를 바꾼다고 발표했다. 4주 정기 주기와 2주 보안 주기를 하나의 2주 주기로 합치고, 주기를 겹쳐 매주 배포한다는 내용이다(Canonical 블로그). 발표문은 그 이유를 이렇게 쓴다.

CVE가 폭증하는 원인은 AI다. LLM과 전문 AI 에이전트가 버그 발견을 수작업에서 고도로 자동화된 엔진으로 바꿔 놓았다. (요약 번역)

같은 발표문에는 두 가지 약속이 더 있다.

  1. 아주 빠른 대응이 필요한 사용자는 -proposed 후보로 직접 수용 시험을 해서 먼저 써도 된다.
  2. 패치가 나오기 전이라도 공개 후 24~48시간 안에 안전한 우회책이나 일반 강화 지침을 주겠다.

이번 사건은 두 약속을 실제로 시험했다. 1번은 지켜졌다. 수정 커널은 10/26부터 -proposed에 있었다. 하지만 -proposed를 직접 켜고 자체 시험까지 할 수 있는 조직은 많지 않다. 2번은 애매하다. 11/2 블로그에서 Canonical 보안팀은 MPTCP를 끄는 우회책에 선을 그었다. 이 우회책은 버그 자체가 아니라 공개된 익스플로잇 하나에만 기댄다는 이유였고, 보안팀은 “보안 업데이트만이 적절한 완화책”이라고 했다. 그 보안 업데이트가 사용자에게 도착하는 데 몇 주가 걸렸다. CVE 페이지에는 나중에 nftables 필터 규칙이 우회책으로 올라왔지만, 페이지 스스로 “위험을 줄일 뿐 막지는 못한다”고 적어 두었다.

시험 자체를 탓하기는 어렵다. 커널 회귀가 수백만 대에 한꺼번에 퍼지는 것도 사고다. 문제는 시험에 걸리는 시간이 취약점의 위험도와 상관없이 일정하다는 것이다. 9.8짜리 원격 root와 사소한 드라이버 수정이 같은 줄에 선다.

3. 기다리는 동안 할 일 — 대비책

3.1 먼저 잰다

uname -r                                   # 지금 돌고 있는 커널
dpkg -l 'linux-image*' | grep ^ii          # 설치된 커널(재부팅 전이면 다를 수 있다)
ls /var/run/reboot-required 2>/dev/null    # 새 커널을 설치하고 재부팅하지 않았는지
sudo ss -Mlnp                              # MPTCP 리스너 목록 (Anthropic 익스플로잇의 전제 조건)
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req

uname -r이 1장 표의 수정 버전 이상이면 이 CVE는 해결된 상태다. 상태 페이지가 아직 빨간색이어도 마찬가지다.

3.2 자동 업데이트가 무엇을 받는지 확인한다

grep -A8 'Allowed-Origins' /etc/apt/apt.conf.d/50unattended-upgrades

여기에 -updates가 주석 처리돼 있으면 24.04·26.04 서버는 이 수정 커널을 자동으로 받지 않는다. 선택지는 두 가지다.

  • 수정 커널만 -updates에서 직접 설치한다. -updates는 시험용인 -proposed가 아니다. Canonical의 인증 시험을 통과한 정식 업데이트 채널이다. 
    sudo apt update
sudo apt install -t "$(. /etc/os-release && echo $VERSION_CODENAME)-updates" linux-generic
sudo reboot   # 그 다음 uname -r 로 확인
  • 아니면 -security로 승격될 때까지 기다리고, 그동안 3.3의 노출 줄이기를 한다.

3.3 노출을 줄인다 (패치를 대신하지는 않는다)

조치 효과 한계
인터넷에서 노드로 바로 들어오는 SYN을 없앤다 (Cloudflare Tunnel처럼 밖으로 나가는 연결만 쓰는 구조, 포트포워딩 제거) 원격 공격면 자체가 줄어든다 같은 LAN·같은 호스트의 컨테이너는 그대로 남는다
MPTCP 끄기: sysctl -w net.mptcp.enabled=0, Go 서비스는 GODEBUG=multipathtcp=0 공개된 익스플로잇의 전제를 없앤다 버그는 MPTCP 전용이 아니다(Canonical·Go 보안팀). 이미 열린 리스너는 프로세스를 재시작해야 반영된다
IP 옵션이 붙은 IPv4 TCP 패킷 버리기 (우분투 CVE 페이지의 nftables 규칙) 첫 번째 경로의 입구를 좁힌다 페이지 스스로 “완전히 막지 못한다”고 적었다. IP 옵션을 쓰는 연결은 끊긴다. 네트워크를 따로 쓰는 컨테이너에는 따로 적용해야 한다
tcp_migrate_req를 켜지 않는다 두 번째 경로(요청 소켓 이주)를 닫는다 기본값이 0이므로 켠 적이 없으면 이미 닫혀 있다

Go 1.24 릴리스 노트에는 “ListenConfig는 이제 지원되는 시스템(현재 Linux만)에서 기본으로 MPTCP를 쓴다”고 적혀 있다(go.dev/doc/go1.24, GODEBUG 문서). 관리자가 켠 적이 없어도 Go로 만든 서비스는 MPTCP 리스너일 수 있다. 그래서 ss -Mlnp를 먼저 돌려 봐야 한다.

3.4 쿠버네티스 노드라면

  • 컨테이너는 호스트 커널을 쓴다. 이미지를 새로 빌드해도 이 문제는 안 고쳐진다. 고쳐야 하는 것은 노드 OS다.
  • 노드는 한 대씩 처리한다. kubectl drain → 커널 설치 → 재부팅 → uname -r 확인 → kubectl uncordon. 로컬 PV에 묶인 파드는 다른 노드로 옮기지 못하므로, 그 노드가 재부팅되는 동안 서비스가 멈출 수 있다. 미리 공지한다.
  • 우리 클러스터의 경우: 10/29 실측 때 네 노드 모두 수정 전 커널이었다(ilwon·solomon 26.04, lemuel·louise 24.04). 그래서 그날 노드를 껐다. 24.04 노드는 오늘 기준 -security로는 수정 커널을 받을 수 없다. 다시 켤 때는 3.2의 -updates 경로로 설치하고 재부팅한 뒤 확인해야 한다. 오늘 노드들의 커널은 SSH가 닿지 않아 다시 측정하지 못했다.

3.5 끝났다고 말하기 전에

  • uname -r이 수정 버전 이상인지 본다. 설치만 하고 재부팅하지 않았으면 아직 취약한 커널이 돌고 있다.
  • Livepatch로는 아직 이 CVE를 막을 수 없다. 이 글을 쓰는 시점에 이 CVE를 다룬 우분투 Livepatch 공지는 찾지 못했다. 재부팅을 피할 방법이 없다고 보고 계획을 세운다.

4. 앞으로의 문제 — 이번 일이 예고하는 것

4.1 병목이 “발견”에서 “전달”로 옮겨 갔다

이 버그는 리눅스 4.4(2016) 때부터 있었다. 거의 10년 동안 숨어 있던 버그를 AI 모델이 찾았고, 익스플로잇까지 만들었다. Anthropic 발표에 따르면 개념 증명에서 커널 포인터 유출까지 48분, 명령 실행까지 5분이 더 걸렸다. 같은 글은 Chrome에서만 CVE 62개가 할당·수정됐다고 밝힌다(Anthropic, 벤더 자체 주장이며 독립 재현은 확인되지 않았다).

Canonical도 9월 발표에서 같은 진단을 내렸다. AI 때문에 CVE가 폭증하고 있다는 것이다. 그런데 발견이 빨라져도 그 뒤 단계는 사람과 장비의 속도로 움직인다. 수정 → 백포트 → 빌드 → 인증 시험 → pocket 승격 → 서버 설치 → 재부팅 순서다. 이번 사건에서 upstream 수정은 하루 만에 나왔지만, 우분투 사용자에게 도착하기까지는 몇 주가 걸렸다.

이 간격을 줄이는 방법은 세 갈래로 보인다.

  1. 위험도에 따라 시험 경로를 나누기. 원격·무인증·root인 취약점은 인증 시험 일부를 줄여 먼저 내보내는 길을 따로 둔다. Canonical의 -proposed 안내는 그 판단을 사용자에게 넘긴 것이다.
  2. 재부팅 없는 패치(Livepatch·kpatch·Ksplice) 확대. 이번에는 대부분의 배포판에서 쓸 수 없었다.
  3. 노드를 고치지 말고 교체하기. 불변(immutable) 노드 OS로 이미지를 통째로 바꾸고 노드를 순서대로 교체하는 방식이다. 커널 하나를 고치는 일이 노드 교체로 바뀐다. 다만 이런 OS들이 이번에 실제로 얼마나 빨리 대응했는지를 1차 자료로 비교하지는 않았다.

4.2 상태 페이지를 믿을 수 없다

이번에 상태 표시가 세 갈래로 어긋났다. 공식 블로그는 “26.10 수정됨”, CVE 트래커는 “Vulnerable, work in progress”, 아카이브에는 이미 -updates에 수정본이 있었다. 사람이 읽으라고 만든 상태 페이지는 실제 배포보다 늦는다. 앞으로 보안 대응 자동화는 아카이브와 실행 중인 커널을 직접 재는 쪽으로 가야 한다. 이 글의 1장 표도 상태 페이지가 아니라 Launchpad API로 만든 것이다.

4.3 기본값이 공격면을 조용히 넓힌다

Go 1.24가 리스너의 MPTCP를 기본으로 켠 것은 성능을 위한 합리적인 선택이었다. 하지만 그 결과, 운영자가 모르는 사이에 공개 익스플로잇의 전제 조건을 갖춘 서버가 늘었다. 언어 런타임, 라이브러리, 커널의 기본값이 바뀌면 보안 검토 대상도 바뀐다. 업그레이드 노트에서 “기본으로 켜진다”는 문장은 보안 공지만큼 주의해서 읽어야 한다.

4.4 배포판을 고를 때 “응답 속도”를 재야 한다

이번 사건은 배포판마다 대응 속도가 크게 다르다는 것을 보여 주었다. 지원 기간(LTS 몇 년)만 보던 기준에 치명적 CVE에서 -security 반영까지 걸린 날짜를 더할 때가 됐다. 이 숫자는 배포판의 공개 기록(아카이브 게시 시각, 보안 공지 날짜)으로 누구나 잴 수 있다. 이 글에서는 우분투만 쟀다. 다른 배포판과의 정밀한 비교는 하지 않았다.

근거의 한계

  • 우분투 pocket 게시 시각은 이 글을 쓰면서 Launchpad API로 직접 조회했다(1차 데이터). 다른 배포판의 수정 날짜는 각 벤더 공지를 기준으로 했고, 일부는 공지를 모아 정리한 2차 자료를 참고했다. 2차 자료는 사실 인용이 아니라 시점 확인용으로만 썼다.
  • Anthropic의 익스플로잇 소요 시간(48분+5분)과 Chrome CVE 수는 Anthropic 자체 발표다. 익스플로잇 코드는 공개되지 않았고, 독립 재현은 확인하지 못했다.
  • 인터넷 전체의 MPTCP 노출 규모나 실제 공격 시도에 관한 수치는 SNS 게시물이나 2차 보도로만 확인돼서 넣지 않았다.
  • USN이 없다는 판단은 이 글을 쓰는 시점에 우분투 CVE 페이지에서 USN 번호를 찾지 못했다는 뜻이다. 그 사이에 발행됐을 수 있다.
  • unattended-upgrades 기본값은 우분투 패키지 기본 설정 기준이다. 조직마다 바꿔 쓸 수 있으니 3.2의 명령으로 각자 확인해야 한다.
  • 우리 클러스터 노드의 오늘 커널 버전은 측정하지 못했다(SSH 불통).

References

[공식] 우분투·Canonical

  1. Ubuntu Security — CVE-2026-98432 (마지막 갱신 2026-11-09)
  2. Luci Stanescu, Fixes available in -proposed pocket for CVE-2026-98432, Ubuntu Blog, 2026-11-02
  3. Canonical, Accelerating delivery of CVE fixes with a new Kernel release strategy, 2026-09-23
  4. Launchpad API — ubuntu/+archive/primary?ws.op=getPublishedSources&source_name=linux (2026-11-10 직접 조회)

[공식] 다른 벤더·프로젝트

  1. Red Hat — CVE-2026-98432, RHSB-2026-016
  2. Debian — Security Tracker: CVE-2026-98432
  3. Go — Go 1.24 Release Notes (net), GODEBUG: multipathtcp

[벤더 1차 주장] 발견자

  1. Anthropic, Discovering and exploiting vulnerabilities in critical, real-world software with Claude, 2026-10-27

[제3자 분석·보도]

  1. Akamai Security Intelligence Group, CVE-2026-98432: A Remote Use-After-Free in the Linux Kernel’s TCP Stack, 2026-11-02
  2. Joey Sneddon, Ubuntu users blast Canonical for slow kernel security fix, OMG! Ubuntu, 2026-11-04

이전 글

  1. CVE-2026-98432 읽기 — SYN 하나에 실린 IP 옵션이 커널 메모리를 두 번 쓰게 되는 경위 (10/29)
  2. CVE-2026-98432 분석 — Linux IPv4 TCP Use-After-Free와 커널 패치 대응 (11/02)