수정됨 — 2026년 11월 3일 오후: 오전 기준으로 쓴 이 글의 Ubuntu 부분을 같은 날 오후에 Ubuntu 보안 트래커로 다시 확인해 고쳤습니다. 바뀐 것은 세 가지입니다. 첫째, 트래커의 Ubuntu 표시가 "수정 작업 중"에서 "pending"으로 바뀌었습니다. 우리는 이것을 수정판 버전 번호가 정해져 릴리스를 기다리는 단계로 읽었습니다. 둘째, 트래커에 적힌 예정 커널 버전 번호를 배포판별로 추가했습니다. 셋째, 수정판이 나온 뒤 실행 중인 커널과 비교하는 방법을 보강했습니다. 트래커에 released(릴리스됨)로 표시된 Ubuntu 수정 커널은 아직 없고, 릴리스 날짜도 트래커에 없습니다. Debian·Red Hat 계열 내용은 오전에 확인한 그대로입니다.

2026년 11월 3일 오전 기준으로 정리했고, Ubuntu 수정 상태는 같은 날 오후에 다시 확인해 고친 글입니다. 리눅스 커널의 IPv4 TCP 연결 처리 부분에서 CVE-2026-98432가 공개됐고, Debian과 Red Hat 계열에는 수정 커널이 나왔지만 Ubuntu는 오후 재확인에서 수정판 버전 번호가 정해진 "pending" 상태가 됐을 뿐 트래커 기준으로 아직 릴리스된 수정 커널은 없습니다(예정 버전 번호는 아래에 적었습니다). 서버가 Ubuntu라면 지금 할 일은 "수정 커널이 나왔는지 확인하고, 나오면 업데이트한 뒤 재부팅하는 것"입니다. 그 사이에 쓸 수 있는 임시 완화책과 아직 확인되지 않은 부분도 함께 적었습니다.

한눈에 보기

  • 무엇인가: 커널이 IPv4 TCP 연결 요청을 처리하는 도중, 재전송된 연결 요청(SYN)을 다른 CPU가 동시에 처리하면 이미 해제된 IP 옵션 메모리를 다시 읽을 수 있는 결함(use-after-free)입니다. CVE 설명에 따르면 수정은 그 메모리를 RCU 유예 기간이 지난 뒤에 해제하도록 바꾸는 작은 변경입니다. 2026년 10월 15일에 CVE가 공개됐습니다.
  • 심각도: Red Hat과 CVE 기록 모두 CVSS 9.8(네트워크 경유, 권한과 사용자 조작 불필요)로 적었고, Ubuntu는 우선순위를 High로 표시합니다.
  • 어디가 해당하나: 취약한 커널에서 IPv4 TCP 연결을 받는 서버입니다. 웹이든 SSH든 연결을 받는 단계에서 일어나는 일이라 PHP·Node.js 같은 응용 프로그램 코드와는 상관이 없습니다. IPv6 연결에는 이 첫 번째 문제가 없다고 CVE 설명에 적혀 있습니다.
  • 얼마나 쉬운가: Red Hat은 정확한 타이밍이 필요하고, 코드 실행까지 안정적으로 이르려면 메모리 배치를 정밀하게 다뤄야 한다고 설명합니다. 그래도 인증 없이 원격에서 커널 메모리 손상이나 서버 중단을 일으킬 수 있다는 점에서 위험도를 Critical로 평가했습니다.
  • Anthropic 시연: Anthropic은 10월 27일 글에서 비공개 내부 연구용 모델이 MPTCP(멀티패스 TCP) 리스너가 있는 리눅스 서버에서 인증 없이 루트 권한으로 명령을 실행하는 공격 코드를 작성했다고 밝혔습니다. 바탕이 된 취약점은 커널 네트워크 스택의 경쟁 조건으로 생긴 use-after-free라고 설명합니다. Red Hat 공지는 이 글을 참고 자료로 달아 두었습니다. 다만 Anthropic 글이 이 CVE 번호를 직접 적었는지는 우리가 확인하지 못했습니다.

배포판별 수정 상태 (2026년 11월 3일 확인, Ubuntu는 오후에 다시 확인)

  • Ubuntu (오전에 확인한 내용을 오후에 다시 확인해 고쳤습니다):
    • 일반 커널(linux 패키지): 22.04 LTS, 24.04 LTS, 26.04 LTS, 26.10이 보안 트래커에서 "pending"으로 표시되고 수정판 버전 번호가 적혀 있습니다. 22.04 LTS는 5.15.0-203.213, 24.04 LTS는 6.8.0-149.149, 26.04 LTS는 7.0.0-43.43, 26.10은 7.3.0-10.10입니다. 오전에는 이 네 버전이 "수정 작업 중"으로 표시돼 있었습니다. "수정판 버전이 정해져 릴리스를 기다리는 상태"라는 풀이는 트래커의 pending 표시를 우리가 그렇게 읽은 것입니다.
    • 20.04·18.04·16.04의 일반 커널: "needed"로 표시됩니다. 수정이 필요하다는 표시만 있고 수정판 버전 번호도, 작업 중이라는 표시도 없습니다.
    • AWS용 커널(linux-aws 패키지): 같은 네 버전이 pending이고 번호가 다릅니다. 22.04 LTS는 5.15.0-1120.127, 24.04 LTS는 6.8.0-1069.74, 26.04 LTS는 7.0.0-1017.18, 26.10은 7.3.0-1004.4입니다. 24.04 LTS에서 7.0 계열 AWS 커널(linux-aws-7.0)을 쓴다면 7.0.0-1017.18~24.04.1입니다. uname -r 끝이 -aws이면 AWS용 커널입니다.
    • 트래커 기준으로 아직 받을 수 있는 수정판은 없습니다. 트래커가 이 상태를 아직 released(릴리스됨)로 바꾸지 않았으므로 지금 apt로 받을 수 있는 Ubuntu 수정 커널은 없는 것으로 보입니다. 보안 저장소를 직접 조회한 것은 아니고 트래커 표시에 근거한 판단입니다. 수정판이 언제 릴리스된다는 일정은 트래커에 없습니다. 위 번호는 예정이고 릴리스될 때 달라질 수 있으니, 업데이트하기 전에 트래커에서 번호를 다시 확인하세요.
    • 위에는 일반 커널과 AWS용 커널만 옮겼습니다. HWE나 다른 클라우드용 등 그 밖의 커널 패키지는 트래커에 별도 줄이 있고, 우리가 모두 확인해 옮기지는 않았습니다. 사용 중인 커널 패키지의 줄을 직접 확인하세요.
  • Debian: 보안 트래커에서 12(bookworm)는 커널 6.1.190-1, 13(trixie)은 6.12.113-1에서 수정됨으로 표시됩니다.
  • RHEL·AlmaLinux 계열: Atlas의 정리에 따르면 Red Hat은 11월 1일에 RHEL 8·9·10 수정 커널을 냈고 AlmaLinux가 11월 2일에 뒤따랐습니다. 이 부분은 우리가 Red Hat 원문으로 직접 확인하지는 못했습니다.
  • 커널 원본(업스트림): Atlas의 정리에 따르면 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3에 수정이 들어갔습니다. 배포판 커널은 자기 버전 번호를 따로 쓰므로 위 숫자와 uname -r 결과를 그대로 비교하면 안 되고, 배포판 트래커를 봐야 합니다.

내 서버가 해당하는지 확인하기

서버에 접속해서 운영체제와 실행 중인 커널을 확인합니다.

cat /etc/os-release
uname -r
  • 실행 중인 커널이 기준입니다. 새 커널 패키지를 설치해도 재부팅하기 전까지는 옛 커널이 계속 돕니다. Ubuntu·Debian은 재부팅이 필요하면 /var/run/reboot-required 파일이 생깁니다.
  • 컨테이너(Docker 등)를 쓰더라도 커널은 서버(호스트)의 것입니다. 컨테이너 이미지를 새로 받는다고 이 문제가 해결되지는 않습니다.
  • 공유 호스팅이나 관리형 호스팅은 커널을 직접 바꿀 수 없으니 호스팅 업체의 공지와 조치 계획을 확인합니다.
  • 해당 배포판의 트래커에서 이 CVE의 상태가 "fixed"로 바뀌었는지 봅니다. Ubuntu는 참고 자료의 트래커 링크를 확인하면 됩니다.

수정 커널이 나오기 전에 할 수 있는 것

아래 방법은 노출을 줄일 뿐 취약점을 없애지 않습니다. Red Hat도 공지에서 패킷을 걸러내는 방법은 업데이트를 대신하지 못하고 필요한 업무 트래픽을 방해할 수 있다고 적었습니다.

IP 옵션이 붙은 TCP 패킷 차단 (Red Hat 공지의 임시 규칙)

Red Hat 보안 공지(RHSB-2026-016)는 IP 옵션이 붙은 IPv4 TCP 패킷을 버리는 nftables 규칙을 임시 방법으로 제시합니다. 일반 애플리케이션 트래픽이 쓰는 TCP 옵션은 TCP 헤더에 들어 있어 이 규칙의 영향을 받지 않는다는 설명입니다. 아래는 그 규칙을 옮긴 것이고, 우리가 직접 시험한 규칙이 아닙니다. 운영 서버에 넣기 전에 시험 환경에서 먼저 확인하세요.

# cve-2026-98432.nft
table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}
sudo nft --check --file cve-2026-98432.nft
sudo nft --file cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

수정 커널로 올린 뒤에는 규칙을 지웁니다.

sudo nft delete table inet cve_2026_98432
  • 이 방법으로 올린 규칙은 따로 저장 설정을 하지 않으면 재부팅 뒤 사라지는 것이 nftables의 일반적인 동작입니다. 임시 조치이니 오래 두지 말고 업데이트 일정을 잡습니다.
  • Atlas가 인용한 AlmaLinux 공지에는 같은 서버 안의 컨테이너끼리 오가는 트래픽은 이 규칙을 거치지 않을 수 있고, IP 옵션으로 보안 라벨을 싣는 네트워크(CIPSO)에서는 쓰면 안 된다는 경고가 있습니다.
  • 서버 앞단 방화벽이 IP 옵션이 붙은 패킷을 버릴 수 있다면 거기서 막는 쪽이 뒤의 서버를 한꺼번에 보호한다는 것이 Atlas의 정리입니다. 사용 중인 장비의 설정은 직접 확인해야 합니다.

MPTCP를 쓰지 않는다면 끄기

Anthropic이 시연한 조건은 MPTCP 리스너가 있는 서버였습니다. TuxCare와 Atlas는 Go 1.24 이후 버전으로 만든 프로그램이 기본으로 MPTCP 리스너를 연다는 Go 보안팀의 설명을 전합니다. MPTCP를 쓰지 않는다면 net.mptcp.enabled 설정을 0으로 바꿔 시연 조건을 없앨 수 있습니다. 다만 이것은 시연 조건을 없앨 뿐 결함 자체를 고치지 않습니다. Atlas는 Go 보안팀이 MPTCP 리스너가 없는 시스템도 비슷한 공격에 노출될 가능성이 있다고 말했다고 전하므로, MPTCP를 껐다고 안심하지 마세요.

그 밖의 기본 조치

  • 쓰지 않는 공개 포트를 닫고, SSH는 접속할 수 있는 주소를 제한합니다. 이번 결함에 특화된 조치는 아니지만 노출되는 입구가 줄어듭니다.
  • 서버 재시작 시 서비스가 정상적으로 다시 올라오는지 미리 점검해 둡니다. 수정 커널이 나오면 재부팅이 필요합니다.

수정 커널이 나오면

  1. 패키지 목록을 갱신하고 커널 업데이트가 있는지 확인합니다(sudo apt update 뒤 apt list --upgradable).
  2. 업데이트를 설치하고 재부팅 시간을 잡아 서버를 다시 시작합니다.
  3. 재부팅 뒤 uname -r이 배포판 트래커에 적힌 수정판 번호 이상인지 확인합니다. Ubuntu 24.04 LTS의 일반 커널을 예로 들면 예정 번호가 6.8.0-149.149인데, uname -r은 6.8.0-149-generic처럼 점 아래 번호를 빼고 앞쪽만 보여 줍니다. 그래서 6.8.0-149 이상이 나오는지 보고, 정확한 패키지 버전은 dpkg -l 'linux-image-*'로 설치된 커널 패키지를 나열해 uname -r과 같은 번호가 든 줄의 버전 칸에서 확인합니다. AWS용 커널이면 6.8.0-1069-aws처럼 끝이 -aws이고 번호 체계가 다르니 위 AWS 줄의 번호와 비교합니다. 비교 기준은 수정판이 릴리스되는 시점의 트래커에서 다시 확인합니다.
  4. 임시 규칙을 넣었다면 지웁니다.

자동 업데이트(unattended-upgrades)를 켜 둔 서버라도 커널은 설치만 되고 재부팅은 따로 해야 적용되는 경우가 많습니다. 재부팅 대기 중인지 위의 /var/run/reboot-required 파일로 확인합니다.

알려진 것과 아직 확인되지 않은 것

  • 확인된 것: 결함의 내용과 수정 방법(CVE 설명), Debian의 수정 커널, Ubuntu의 수정판 예정 버전 번호(아직 릴리스 전), Red Hat의 심각도 평가와 임시 규칙.
  • 실제 공격 여부: Atlas의 정리로는 11월 2일 낮 기준 이 CVE가 미국 CISA의 악용 확인 취약점 목록(KEV)에 올라 있지 않습니다. 같은 글은 이 CVE를 언급하는 공개 저장소 중 일부가 경쟁 조건을 일으키는 코드나 개념 증명을 갖췄다고 주장한다고 전하는데, 우리는 그 코드를 시험하거나 링크하지 않았습니다. 이 상태는 빠르게 바뀔 수 있습니다.
  • 확인하지 못한 것: Anthropic 시연이 MPTCP를 쓰지 않는 일반 서버에서도 같은 방식으로 되는지, Ubuntu 수정 커널의 공개 시점, 임시 규칙이 각 환경에서 일으킬 부작용.

Ubuntu 수정판이 나오거나 상황이 바뀌면 이 글을 갱신하겠습니다.

점검 체크리스트

  1. cat /etc/os-release와 uname -r로 배포판과 실행 중인 커널을 확인합니다.
  2. 배포판 트래커에서 이 CVE의 수정 상태를 확인합니다(Ubuntu는 수정판 버전이 정해진 pending 상태이고 아직 릴리스 전).
  3. 수정 커널이 있으면 설치하고 재부팅한 뒤 uname -r을 다시 확인합니다.
  4. 수정 커널이 아직 없으면 임시 규칙 적용 여부를 시험 환경에서 먼저 검토하고, 앞단 방화벽에서 막을 수 있는지 봅니다.
  5. MPTCP를 쓰지 않는다면 끄는 것을 검토하되, 그것만으로 해결되지 않는다는 점을 기억합니다.
  6. 컨테이너를 쓴다면 호스트 커널이 기준이라는 점, 호스팅을 쓴다면 업체 공지를 확인합니다.

서버 점검이나 재부팅 일정 잡기가 부담스러우시면 아래 문의 양식으로 현재 상황을 알려 주세요. 사용 중인 서버 환경을 함께 확인하고 우선순위를 정리해 드리겠습니다.

참고 자료