Ubuntu CVE-2026-98432, LTS 수정 커널 아직 정식 배포 전

Ubuntu 서버를 운영한다면 CVE-2026-98432의 ‘수정본 공개’와 ‘서버에 적용 가능’을 구분해야 한다. 이 CVE는 Linux 커널의 IPv4 TCP 연결 처리 과정에서 해제된 메모리를 다시 사용하는 취약점으로, 원격 코드 실행으로 이어질 수 있다. Ubuntu가 매긴 우선순위는 High이고 CVSS 3.1 점수는 9.8이다. 커널 문제인 만큼 패키지 설치 여부뿐 아니라 실제 실행 중인 커널까지 확인해야 한다.[1][2]

수정 커널은 나왔지만, 2026년 11월 3일 19:22 KST 확인 기준 Ubuntu 22.04·24.04·26.04 LTS의 일반 linux 수정본은 아직 -proposed에 있다. 기본 updates/security 저장소만 쓰는 이들 LTS 서버에서는 apt upgrade를 실행해도 그 수정본을 받지 못한다. ‘패치가 나왔다’는 소식만으로 대응이 끝나지 않는 이유다. 다만 Ubuntu 26.10은 수정 버전이 Updates·Security에 올라와 있어 따로 봐야 한다.[1][3][4][5][6]

현재 판단: LTS 일반 linux 수정본은 테스트용 채널에 있고 정식 채널 진입 전이다. 해당 CVE의 USN은 확인되지 않았다. 정식 배포 날짜와 Livepatch 커버 여부는 확인 안 됨. 운영 서버 전체에 proposed를 열기보다, 검증 환경과 정식 배포 후 적용 절차를 구분하는 것이 이번 후속의 핵심이다.[1][2][8]

이전 글에서 무엇이 바뀌었나?

수정 커널의 버전과 올라온 채널을 확인할 수 있게 됐다. 10월 30일 글 ‘Ubuntu CVE-2026-98432, 패치 전에 확인할 것들’이 패치 전 점검을 다뤘다면, 이번에는 수정본이 등장한 뒤에도 남아 있는 배포 단계의 차이를 살펴본다.

Canonical은 22.04 LTS 이상 수정본이 qualification testing 중이라고 설명한다. 2,000대 이상의 인증 서버와 디바이스에서 테스트를 마친 뒤 updates에 배포하고 블로그를 갱신하겠다는 안내다. 구체적인 배포 날짜는 제시하지 않았다. 수정본이 있다는 사실과 기본 업데이트 대상으로 배포됐다는 사실은 같은 뜻이 아니다.[1]

릴리스마다 수정 커널은 어디에 있나?

22.04·24.04·26.04의 일반 linux 수정본은 Proposed에만 있고, 26.10은 정식 채널에도 있다. 아래는 Canonical 표를 Launchpad의 Published 항목 및 패키지 목록과 대조한 결과다.[1][3][4][5][6][7]

이 표는 일반 linux 소스 패키지 기준이다. HWE나 AWS·Azure 등 다른 커널 계열에 그대로 적용하면 안 된다. 또 소스 패키지 전체 버전은 uname -r에 나오는 실행 커널의 ABI·플레이버 표기와 다르므로, 두 문자열이 똑같은지만 비교해서는 안 된다.[1][2]

자료 사이의 차이도 남아 있다. CVE JSON에서 이 네 릴리스의 linux 상태는 모두 pending이다. 반면 26.10은 Canonical 블로그에 Fixed로 표시되고 실제 패키지도 Updates·Security에 있다. 어느 자료가 왜 다른지는 단정할 수 없다. 26.10 운영자는 pending이라는 표시만 보고 패키지가 없다고 판단하지 말아야 한다.[1][2][6]

20.04 이하의 지원 릴리스는 블로그상 Fix pending이며, 이번에 확인한 JSON에서 focal·bionic·xenial의 linux는 needed다.[1][2][6]

-proposed를 켜면 일반 업데이트와 같아지나?

아니다. proposed는 updates로 내보내기 전에 새 패키지를 검증하는 채널이다. SRU 문서도 proposed 활성화, 테스트 수행, 결과 공유를 검증 절차로 안내한다. 이번 수정 커널을 먼저 시험할 수 있다는 뜻이지, 운영 환경 전체에 이미 검증이 끝났다는 뜻은 아니다.[9]

Canonical은 proposed 패키지의 명시적인 대상 지정 설치를 안내한다. 다만 설정 방식에는 릴리스 차이가 있다.

SRU 문서는 22.04 이하에서 선택적 업그레이드를 위한 Pin-Priority: 100 설정을 따로 안내한다. 이를 빼고 저장소만 추가하면 의도하지 않은 패키지까지 업데이트 후보에 섞일 수 있다. 운영 서버 전체에 proposed를 상시 활성화하는 방법을 이번 대응의 기본값으로 삼지 않는 편이 좋다.[1][9]

조직 정책상 선행 검증이 필요하다면 운영과 분리된 테스트 서버나 제한된 카나리에서 대상 커널 계열을 정하고, 변경 전 복구 경로를 확보한 뒤 진행한다. 이는 운영상 권고다. 공식 블로그의 메타 패키지 설치 예제를 모든 서버에 일괄 적용하는 명령으로 받아들이지 말고, SRU 문서의 릴리스별 절차와 실제 의존성을 먼저 확인해야 한다.[1][9]

APT에서는 무엇을 구분해서 봐야 하나?

설치된 커널, 다음 설치 후보, 후보가 오는 저장소를 나눠 봐야 한다. generic 커널 메타 패키지를 쓰는 환경이라면 다음처럼 확인할 수 있다. 아래 명령은 proposed를 활성화하거나 커널을 설치하지 않는다.

uname -r
sudo apt update
apt-cache policy linux-image-generic

apt-cache policy에서는 Installed와 Candidate뿐 아니라 버전별 저장소 주소와 suite도 읽는다. proposed를 설정하지 않은 서버에 proposed 후보가 보이지 않는 것은 정상이다. generic이 아닌 서버는 쓰는 커널 메타·이미지 패키지명으로 바꿔 확인해야 한다.

새 ABI 설치 시 메타 패키지와 의존성을 어떻게 처리하는지는 별도 문제이며, 이번 LTS의 핵심은 수정본 자체가 기본 채널에 아직 없다는 점이다.[1][9]

테스트를 마친 뒤 proposed sources와 pin 설정을 해제해도 이미 설치한 proposed 패키지가 자동으로 이전 버전으로 돌아가지는 않는다. 설치 이력과 패키지별 후보를 확인해 정식 채널 복귀 계획을 따로 세워야 한다. 운영상으로는 이전 정상 커널과 원격 콘솔 접근 수단을 확보해 두는 편이 안전하다.

완화책이나 Livepatch로 적용을 대신할 수 있나?

이번 자료만으로 패치 적용이 끝났다고 볼 수는 없다. Canonical은 취약점 수정이 MPTCP에만 한정되지 않으며, Ubuntu Security Team은 security updates를 유일하게 적절한 완화로 본다고 설명한다. 따라서 MPTCP를 껐다는 사실을 수정 커널 적용의 대체 증거로 쓰면 안 된다.[1]

CVE JSON에는 IP options가 있는 IPv4 TCP 패킷을 nftables로 거르는 절차도 있다. 하지만 한계 문구는 분명하다. Limit: reduces the risk but does not fully prevent exploitation. 즉, 위험을 줄이지만 악용을 완전히 막지는 못한다.[2]

부작용과 적용 범위도 생략하면 안 된다. 원문은 Breaks: TCP connections that depend on IPv4 options., Containers with separate networking need the rule applied separately.라고 적고 있다. IPv4 options에 의존하는 TCP 연결은 깨지며, 별도 네트워크를 쓰는 컨테이너에는 규칙을 따로 적용해야 한다.

nftables와 sudo를 통한 root 접근이 필요하고, 재부팅 후 유지는 UFW나 firewalld 없이 /etc/nftables.conf로 방화벽을 관리한다는 전제다. 일반 TCP options와 IPv6는 영향을 받지 않는다고 설명한다. 이 전제를 확인하지 않은 채 규칙만 복사하지 말아야 한다.[2]

Livepatch가 이 CVE를 커버하는지는 확인 안 됐다. 구독 여부나 Livepatch 실행 여부만으로 이번 수정이 적용됐다고 판단하지 말고, 해당 CVE에 맞는 패치가 제공되고 활성화됐는지 따로 확인해야 한다.

AWS의 수정 안내를 Ubuntu에도 적용하면 되나?

Amazon Linux와 Ubuntu의 배포 상태를 구분해야 한다. 관련 공지는 AWS-2026-160이다. Amazon Linux 수정 커널은 제공 중이며 업데이트와 재부팅을 안내하지만, Ubuntu는 운영체제 벤더의 수정본 제공에 따라야 한다. Cloud9 항목에는 Canonical이 Ubuntu 수정 커널을 아직 정식으로 내놓지 않았다는 취지의 문구가 남아 있다. Ubuntu의 현재 채널 상태는 앞의 Canonical·Launchpad 자료와 함께 읽어야 한다.[10]

WorkSpaces의 Livepatch 언급 역시 벤더가 적용 가능한 livepatch를 제공하고 그것이 설치·활성화된 경우라는 조건부 설명이다. Ubuntu용 이번 CVE 패치가 존재한다는 확인은 아니다. 한편 AWS-2026-164는 Serverless MCP Server의 CVE-2026-116635 공지로, 이 커널 취약점과는 별개다.[10][11]

정식 채널에 들어온 뒤에는 무엇으로 완료를 판단하나?

대상 커널 설치와 재부팅, 서비스 검증까지 끝나야 운영 변경이 마무리된다. 다음은 정식 배포 이후 적용할 체크리스트다.

1. 대상과 채널 확인: 쓰는 릴리스·커널 계열의 CVE released 상태, 연결된 USN, 실제 updates/security 후보를 교차 확인한다. 자료가 엇갈리면 패키지 제공 여부와 수정 여부를 각각 확인한다. 이미 정식 채널에 있는 26.10을 LTS와 같은 대기 상태로 취급하지 않는다.[2][6][8]
2. 업그레이드와 재부팅: 기본 security/updates 채널에서 조직 표준 커널 배포 절차로 설치한다. 커널 수정 적용에는 재부팅이 필요하다. 패키지 설치 성공만으로 종료하지 않는다.[1]
3. 실행 상태 확인: 재부팅 후 uname 출력과 설치 패키지를 대조하고, 서비스 응답·네트워크·모니터링 경보를 확인한다. 이는 배포 성공과 운영 정상 여부를 함께 보는 점검이다.
4. 테스트 설정 정리: 검증용 proposed 설정과 pin을 검토하고 정상 채널 복귀를 확인한다. 설정 해제와 패키지 되돌리기는 별개의 작업으로 기록한다.
5. 클라우드·Livepatch 별도 확인: 쓰는 이미지와 벤더 공지의 갱신 내용을 확인한다. Livepatch를 쓴다면 해당 CVE 패치의 실제 제공·활성 상태를 확인한 뒤 재부팅 예외를 판단한다.[10]

확인 시점의 CVE JSON에는 연결된 USN이 없고, notices 검색과 RSS에서도 해당 공지를 찾지 못했다. 하지만 USN 유무 하나로 모든 릴리스의 배포 상태를 대신 판단할 수는 없다. 이번 공백에서 필요한 구분은 간단하다. 수정본이 있는가, 내 서버의 채널에 왔는가, 재부팅 뒤 실제 실행 중인가. 이 세 가지를 각각 확인해야 ‘패치가 나왔다’는 소식을 서버의 적용 완료로 연결할 수 있다.[2][8]

출처