Daily-It

Java·백엔드 운영 경험으로 AI·개발·자동화와 일상 IT의 실제 판단을 기록하는 기술 블로그입니다.

Ubuntu CVE-2026-98432, 패치 전에 확인할 것들

보안 이슈가 자주 나오는데, 이번에는 무엇부터 봐야 할까?

심각도 숫자보다 먼저 내 Ubuntu의 릴리스와 커널 패키지에 어떤 상태가 붙어 있는지 확인한다.

보안 이슈가 거의 매일 올라온다. 새 CVE를 보면 업데이트부터 서두르고 싶지만, 수정본을 준비 중이라는 말과 실제로 설치할 수 있다는 말은 다르다. 이 글은 실제 패치 후기가 아니라, 공식 자료를 바탕으로 대상 식별부터 적용 후 확인까지 정리한 점검 가이드다.

CVE-2026-98432는 IPv4 TCP의 use-after-free 취약점이다. 2026년 10월 30일 05:34 KST 직접 조회 기준, Ubuntu의 CVSS3는 9.8, priority는 High다. 9.8은 Ubuntu 확인값이다. NVD 상세 페이지는 이번 조회에서도 HTTP 403으로 내용을 확인하지 못했다. 따라서 NVD 평가값을 대조했다는 뜻은 아니다.

Ubuntu 전체가 같은 상태인 것은 아니다. 릴리스와 소스 패키지를 나누어 확인해야 한다. pending의 목표 버전은 배포 완료 버전도, 지금 설치하라는 권장 버전도 아니다.

일반 linux 소스 패키지의 조회 시점 상태는 다음과 같다. AWS·Azure·HWE는 이 표와 별도로 확인해야 한다.

Ubuntu 릴리스 일반 linux 상태 수정 목표 버전
26.10 stonking pending(수정 작업 중) 7.3.0-10.10
26.04 resolute pending(수정 작업 중) 7.0.0-43.43
24.04 noble pending(수정 작업 중) 6.8.0-149.149
22.04 jammy pending(수정 작업 중) 5.15.0-203.213
20.04 focal needed(수정 필요) 미기재
18.04 bionic needed(수정 필요) 미기재
16.04 xenial needed(수정 필요) 미기재
14.04 trusty not-affected(해당 패키지 비영향) 해당 없음

이 표는 CVE 페이지에 실린 일반 linux 소스 패키지의 릴리스별 상태다. pending과 needed는 비영향 판정이 아니며, not-affected도 해당 패키지 조합에 한정된다. 표에 없는 릴리스의 안전을 뜻하거나 14.04 전체의 지원을 보장하지 않는다.

다른 커널 패키지에는 ignored나 DNE가 표시될 수 있다. ignored는 지원 종료·다른 패키지로 대체 등의 사유를 함께 읽어야 하며, DNE는 그 릴리스에 해당 패키지가 없다는 뜻이다. 둘을 안전 판정으로 묶지 않는다. AWS·Azure·HWE와 ESM 적용 여부도 별도로 대조해야 한다. 판단 기준은 Ubuntu CVE 페이지와 Ubuntu API다.

커널 네트워크 취약점의 개념을 표현한 일러스트
개념 일러스트(daily-it.com 자체 제작)

내 Ubuntu와 실행 중인 커널은 어떻게 확인할까?

배포판 정보와 현재 실행 커널을 각각 확인한 다음, 사용하는 커널 계열을 대조한다.

lsb_release -a
uname -r

각 명령의 출처는 Canonical의 lsb_release 매뉴얼과 uname 매뉴얼이다. 여기에는 실행 결과 예시를 넣지 않는다.

확인할 항목은 릴리스 이름, 실행 커널, 설치된 커널 패키지와 메타패키지, AWS·Azure·HWE 사용 여부다. 실행 커널 문자열만으로 CVE 페이지의 소스 패키지 행을 확정해서는 안 된다. 같은 Ubuntu 릴리스라도 커널 계열에 따라 확인할 행이 달라질 수 있기 때문이다.

특히 일반 linux의 상태를 클라우드용 커널에 그대로 적용해서는 안 된다. 점검 기록에는 릴리스와 커널 계열을 함께 적는다. 그래야 다른 패키지의 수정 버전과 비교하는 실수를 줄일 수 있다.

Livepatch가 켜져 있으면 이번 패치도 끝난 걸까?

아니다. Livepatch 구동 상태와 이번 CVE에 대한 방어 완료는 구분해서 확인해야 한다.

Ubuntu Pro 클라이언트가 있는 환경이라면 다음 명령으로 점검한다.

pro fix --dry-run CVE-2026-98432
pro status

출처는 Canonical의 CVE 영향 확인 문서와 Pro 기본 명령 문서다. 첫 명령은 문서의 CVE 자리표시자를 이번 식별자로 바꾼 것뿐이다. 실제 실행 결과가 아니며, dry-run 자체가 수정을 적용하는 것도 아니다.

Livepatch가 설치되어 있고 지원되는 환경에서는 다음 상태도 확인한다.

canonical-livepatch status --verbose

상세 상태 명령의 출처는 Canonical의 Livepatch 튜토리얼이며, 출력 해석은 상태 확인 문서를 함께 본다. 서비스 구동 표시만으로 CVE-2026-98432 적용이 보장되지는 않는다. 지원 범위와 이번 CVE에 대한 적용 여부를 따로 확인한다.

2026년 10월 30일 05:34 KST 조회 기준, Ubuntu API는 notices_ids=[], notices=[]이며, 이번에 확인한 RSS에서도 식별자를 찾지 못했다. 표현은 “해당 CVE에 연결된 USN 미확인”으로 한정한다. 보안 공지가 전혀 없거나 앞으로도 나오지 않는다는 뜻은 아니다. 공개 직전에는 CVE·USN·실제 커널 패키지 배포 상태를 반드시 다시 확인한다.

apt 업데이트와 재부팅은 언제 진행해야 할까?

이번 CVE의 수정 커널이 실제 배포된 뒤, 변경 범위와 유지보수 조건을 검토하고 진행해야 한다.

sudo apt update
sudo apt upgrade

두 명령의 출처는 Canonical의 업데이트 절차 문서다. 이 문서에서 패키지 갱신 단계만 참고하며, 배포판 버전 업그레이드를 권하는 것은 아니다. 패키지 목록을 새로 받는 것과 수정 커널을 설치하는 것은 다르다. 위 upgrade는 이번 CVE의 수정 커널이 실제 배포된 뒤 실행할 일반 예시다. pending 목표 버전을 현재 설치할 수 있다는 뜻이 아니다.

업데이트 전에는 전체 패키지 변경 범위와 서비스 재시작 위험을 검토한다. 보류된 패키지, 커널 메타패키지, 클라우드·HWE 계열의 제공 상태도 확인할 항목이다. 이 명령만으로 특정 커널 설치를 보장하지 않는다. 연결된 USN이 확인되면 자기 패키지의 수정 버전과 실제 제공 버전을 대조해야 한다.

systemctl reboot

재부팅 명령도 Canonical의 업데이트 절차 문서에서 확인했다. 권한을 요청하면 운영 환경의 승인 절차를 따른다. 업무 중 즉시 실행할 명령으로 제시하는 것이 아니다. 유지보수 창을 확보하고, 백업·복구 절차와 원격 접속이 끊겼을 때의 접근 수단을 검토한 뒤에만 실행한다.

업데이트가 필요하다는 판단과 지금 재부팅해도 된다는 판단은 별개다. 수정본 설치 여부와 재부팅 시점을 따로 결정해야 하는 이유다.

서버 패치와 재부팅 작업을 표현한 일러스트
개념 일러스트(daily-it.com 자체 제작)

적용 후에는 무엇을 다시 확인해야 할까?

설치된 패키지뿐 아니라 실제 실행 커널과 해당 패키지의 CVE 수정 상태를 다시 대조해야 한다.

재부팅을 수행했다면 앞의 uname -r로 실행 커널을 다시 확인한다. 설치된 커널 패키지 버전, 정확한 소스 패키지, Ubuntu CVE 상태, 연결된 USN의 자기 패키지 수정 버전을 함께 놓고 판단한다. 목표 버전과 비슷한 문자열이 보인다는 이유만으로 완료 처리해서는 안 된다.

Pro 클라이언트가 있다면 앞의 dry-run 점검을 다시 참고하고, 지원되는 Livepatch 환경이면 상태도 재확인한다. 각각의 출력은 점검 자료이지 다른 커널 계열까지 포괄하는 보증은 아니다.

커널 변경 뒤에는 서비스 상태, 원격 접속, 필요한 기능의 정상 여부도 확인한다. 이 글은 실제 적용 성공이나 서비스 정상화를 검증한 기록이 아니다.

수정 커널이 나오기 전에는 무엇을 할 수 있을까?

영향 대상과 지원 상태를 정리하고 공식 공지를 추적하되, 이를 취약점 해결 완료로 취급하지 않아야 한다.

2026년 10월 30일 05:34 KST 조회 기준, Ubuntu의 mitigation 필드는 빈 값이다. 공식 완화책이 기재되지 않았다는 뜻이지, 위험이 없다는 뜻은 아니다. 반대로 근거 없는 설정 변경을 공식 완화책처럼 제시하지도 않는다.

릴리스와 커널 계열, ESM 적용 여부, 업데이트를 받을 경로, 유지보수 가능 시간을 먼저 정리한다. 기존 접근 통제와 서비스 노출 범위를 재점검하는 일은 운영상 검토 항목으로 두되, 이번 CVE의 공식 해결책이나 방어 보증으로 보아서는 안 된다.

Ubuntu 보안 공지 RSS에서 식별자가 검색되지 않았다는 사실도 당시 확인 범위의 기록이다. 이후 공지와 패키지 배포 상태는 달라질 수 있다. 수정 커널 전 단계는 점검과 공지 추적이지 해결 완료가 아니라는 점을 기록에 분명히 남긴다.

Livepatch를 활용한 무중단 대응을 표현한 일러스트
개념 일러스트(daily-it.com 자체 제작)

자주 쓰는 패치 관리 루틴은 어떻게 잡을까?

공지 확인부터 적용 후 재확인까지를 반복 가능한 점검표로 만든다.

점검 순서는 공지 확인, 대상 식별, 변경 검토, 적용, 재확인이다. 대상 기록에는 릴리스·소스 패키지·지원 경로를 함께 남기고, 수정본이 나오면 제공 버전과 변경 범위를 검토한다. 패키지를 설치했다는 기록과 실제 실행 커널을 확인했다는 기록은 나누어 둔다.

자동 업데이트도 켜짐 여부만으로 판단하지 않는다. Canonical의 자동 업데이트 문서를 기준으로 /etc/apt/apt.conf.d/20auto-upgrades와 /etc/apt/apt.conf.d/50unattended-upgrades의 설정을 확인한다. /var/log/unattended-upgrades/의 로그에서는 적용 내역과 실패 여부를 살핀다. 여기서는 추가 명령이나 설정 예시를 제시하지 않는다.

자동 업데이트가 있다는 이유로 이번 커널 수정과 필요한 재부팅까지 끝났다고 가정해서는 안 된다. 완료 기준은 업데이트 명령의 종료가 아니라, 자기 패키지의 수정본 배포 확인과 설치 확인, 실제 실행 커널 재확인이다.

이 글을 참고해 작업하기 직전에도 CVE·USN·실제 커널 패키지 배포 상태를 반드시 다시 확인한다. 위 조회 시점의 pending 목표 버전을 현재 설치 권장 버전처럼 남겨 두지 않는 것까지가 마지막 점검이다.

공식 출처