리눅스 커널 긴급 취약점, 우분투 서버는 안전할까? 영향과 패치 확인법

핵심 POINT

Anthropic은 2026년 10월 27일 연구 블로그에서 자사 내부 연구 모델이 리눅스 커널의 네트워크 처리 취약점(CVE-2026-98432)을 찾아냈고, 이를 이용해 원격에서 관리자 권한으로 명령을 실행하는 공격을 시연했다고 밝혔습니다. 해당 취약점은 이미 업스트림 커널에 패치가 반영됐지만, 배포판별로 수정 커널이 나오는 속도는 서로 다릅니다.

이번 글에서는 Anthropic의 연구 내용과 Red Hat, Ubuntu의 공식 공지를 바탕으로 취약점의 영향 범위와 시연 조건의 차이, 배포판별 패치 상태, 내 서버의 커널 버전과 패치 확인 방법, 패치 전까지 쓸 수 있는 임시 대응을 정리합니다. 패치 상태는 2026년 11월 3일 확인 기준이며, 배포판의 공식 안내에 따라 내용이 바뀔 수 있습니다.

■ 리눅스 커널 TCP 처리 취약점, 무엇이 발표됐나

출처: AI(ChatGPT) 생성 이미지

Ubuntu 보안 페이지에 공개된 설명에 따르면 이 취약점은 리눅스 커널의 IPv4 TCP 연결 처리 과정에서 생깁니다. 서버가 같은 연결 요청(SYN)을 다시 받아 한 CPU가 응답을 만드는 동안, 이미 만들어진 연결 소켓이 해제되면서 그 응답이 쓰는 옵션 메모리도 함께 해제될 수 있습니다. 이미 해제된 메모리를 다시 읽는 오류를 해제 후 사용(use-after-free)이라고 부릅니다.

Red Hat은 이 취약점을 인증 없이 네트워크로 공격할 수 있는 Critical 등급으로 평가했습니다. 공격에는 특별한 권한이나 사용자 조작이 필요하지 않고, 시스템 충돌이나 메모리 손상, 원격 코드 실행으로 이어질 수 있다고 설명했습니다. 다만 코드 실행은 정교한 타이밍과 메모리 제어가 필요하다고 덧붙였습니다. CVSS v3.1 기준 점수는 Red Hat과 Ubuntu 모두 9.8이며, Ubuntu 페이지에는 CVSS v4.0 기준 8.3(High)도 함께 표시돼 있습니다.

TCP는 거의 모든 네트워크 서비스의 기반이므로 영향 범위가 넓다는 점이 이번 이슈의 특징입니다. Red Hat은 외부에서 들어오는 TCP 연결을 받는 시스템이 가장 직접적으로 노출된다고 안내했습니다.

■ 시연된 공격 조건과 실제 영향 범위의 차이

출처: AI(ChatGPT) 생성 이미지

Anthropic은 내부 연구 모델이 짧은 초기 지시 뒤에 공격 코드를 작성했고, MPTCP 리스너가 열린 리눅스 서버에서 인증과 사용자 조작 없이 root 권한으로 명령을 실행하는 데 성공했다고 설명했습니다. 공격은 두 단계로 진행됐습니다. 먼저 커널 주소 배치를 무작위로 섞는 보호 기능(KASLR)을 우회하기 위해 커널 포인터를 알아냈고, 이어서 제어 흐름을 가로채 공격자가 고른 명령을 실행했습니다.

Anthropic은 경쟁 상태에서 지면 연결이 실패할 뿐 시스템 전체가 멈추지 않아 공격자가 성공할 때까지 반복할 수 있다고 설명했습니다. 시연에서는 커널 포인터를 알아내는 데 48분, 이후 명령 실행까지 5분이 걸렸다고 밝혔습니다. 시연에서는 이처럼 반복 시도와 시간이 필요했다는 뜻입니다.

여기서 구분할 점이 있습니다. 이 시연은 MPTCP 리스너가 열린 환경에서 이뤄졌지만, Red Hat은 OpenShift 안내에서 MPTCP가 이 취약점의 필수 조건이 아니며 MPTCP가 꺼진 기본 설정의 노드도 영향을 받는다고 밝혔습니다. 또한 Anthropic과 Red Hat 두 공지 모두 실제 공격에 악용된 사례는 언급하지 않았습니다. 영향받는 시스템 범위, 코드 실행이 시연된 환경, 실제 악용 여부는 서로 다른 문제로 나눠서 봐야 합니다.

■ 우분투와 레드햇의 패치 상태

‍

업스트림 커널에는 수정이 반영됐지만 배포판 커널은 별도로 빌드해 배포합니다. 아래 표는 2026년 11월 3일 확인한 공식 공지의 요약이며, 실제 서버의 영향 여부는 설치된 커널 패키지 및 배포판별 최신 보안 권고를 기준으로 판단해야 합니다.

Ubuntu 보안 페이지는 22.04, 24.04, 26.04 LTS의 기본 커널과 일부 HWE 커널(하드웨어 지원을 위해 따로 제공되는 최신 커널)을 수정 작업 진행 중으로 표시합니다. 일부 HWE 커널은 취약으로만 표시돼 있으므로 사용 중인 커널 패키지를 정확히 확인해야 합니다.

Red Hat은 RHEL 8, 9, 10과 OpenShift Container Platform을 영향 제품으로 안내하며 수정 배포를 서두르고 있다고 밝혔습니다. RHEL 커널을 쓰는 OpenStack Platform, Virtualization 같은 제품과 RHEL CoreOS도 영향을 받을 수 있어 기반 커널을 최신으로 맞추라고 안내했습니다. OpenShift에 대해서는 임시 안내를 검토 중이며 확정되면 공지를 갱신하겠다고 밝혔습니다. 표의 내용은 배포판의 공식 안내에 따라 바뀔 수 있으므로 적용 전 각 배포판의 최신 공지를 다시 확인해야 합니다.

■ 내 서버의 커널 버전과 패치 확인 방법

출처: AI(ChatGPT) 생성 이미지

서버에 접속해 아래 순서로 확인합니다. 아래 명령은 Red Hat, Ubuntu 공지에 실린 내용이 아니라 각 배포판에서 일반적으로 쓰는 확인 방법입니다. 배포판과 설정에 따라 결과가 다를 수 있으므로 운영 서버에서는 담당자와 확인한 뒤 실행하고, 최종 판단은 배포판 보안 페이지를 기준으로 합니다.

1. 실행 중인 커널 버전 확인

터미널에서 아래 명령을 실행해 현재 실행 중인 커널 버전을 확인합니다. 우분투 HWE 커널을 쓰는 서버는 이 버전으로 어떤 커널 패키지인지 구분할 수 있습니다.

uname -r

2. 배포판 업데이트 목록 확인

우분투는 저장소 정보를 갱신한 뒤 커널 업데이트가 올라와 있는지 확인합니다. RHEL 계열은 보안 권고 목록에서 해당 취약점을 찾습니다.

# Ubuntu
sudo apt update
apt list --upgradable | grep linux-image

# RHEL 계열
sudo dnf updateinfo list --cve CVE-2026-98432

3. 변경 이력으로 수정 여부 참고

커널 패키지의 변경 이력에서 해당 CVE의 수정 여부를 참고할 수 있습니다. 다만 변경 이력에 CVE 번호가 표시되지 않거나 설치된 커널과 실행 중인 커널이 다를 수 있으므로, 최종 패치 여부는 배포판의 공식 보안 공지와 현재 실행 중인 커널 버전을 함께 대조해야 합니다.

# Ubuntu
apt changelog linux-image-$(uname -r) | grep CVE-2026-98432

# RHEL 계열
rpm -q --changelog kernel | grep CVE-2026-98432

4. 업데이트 후 재부팅과 재확인

수정 커널을 설치한 뒤에는 서비스 영향을 조율해 재부팅하고, 다시 uname -r 명령으로 실행 중인 커널이 바뀌었는지 확인합니다. 설치만 하고 재부팅하지 않으면 이전 커널이 계속 실행됩니다.

■ 패치 전까지 쓸 수 있는 임시 대응

‍

Red Hat은 영향받는 네트워크 트래픽을 걸러 노출을 줄일 수 있지만 패치를 대신하지는 못하며, 커널 보안 업데이트가 유일한 완전한 해결책이라고 안내했습니다. 임시 방법으로는 IP 옵션이 붙은 IPv4 TCP 패킷을 차단하는 nftables 규칙을 제시했습니다. 일반 응용 프로그램 트래픽은 대부분 영향이 없을 것으로 예상된다고 설명했지만, 규칙을 적용하기 전에 자사 트래픽과 네트워크 구성에 맞는지 검토하고 운영 환경이 아닌 곳에서 먼저 시험하라고 경고했습니다.

이 규칙은 정상 네트워크 통신에 영향을 줄 수 있으므로, 운영 서버에 적용하기 전에 네트워크 담당자와 영향 범위를 확인하고 원격 접속 장애에 대비한 복구 절차를 마련해야 합니다. 또한 규칙의 효과는 해당 호스트가 받는 입력 트래픽에 한정될 수 있어, 클라우드와 컨테이너 환경에서는 네트워크 경계와 호스트별 통제 범위를 구분해야 합니다.

아래는 Red Hat 보안 공지에 실린 규칙입니다. 파일로 저장한 뒤 문법을 검사하고 적용합니다.

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

커널을 수정 버전으로 업데이트한 뒤에는 아래 명령으로 임시 규칙을 제거합니다. OpenShift 노드에서는 규칙이 노드의 호스트 네트워크 트래픽에만 적용되고 파드 사이 트래픽은 걸러지지 않으므로, 클러스터 앞단 경계에서 거르는 방법도 함께 검토해야 합니다.

sudo nft delete table inet cve_2026_98432

이 규칙은 노출을 줄일 뿐 취약점을 완전히 막지는 못합니다. 일반적인 보안 관리 차원에서 외부에 열려 있는 TCP 서비스 목록도 함께 점검해 볼 수 있습니다. SK쉴더스는 취약점 진단과 모의해킹, 보안관제 서비스를 통해 기업의 서버 취약점 점검과 외부 노출 자산 관리, 이상 징후 모니터링을 지원하고 있습니다.

■ 자주 묻는 질문

‍

Q. 모든 리눅스 서버에서 root 탈취가 가능한가요?

A. Anthropic이 시연한 공격은 MPTCP 리스너가 열린 서버를 대상으로 했습니다. 다만 Red Hat은 OpenShift 안내에서 이 취약점이 MPTCP를 필수 조건으로 하지 않으며 MPTCP가 꺼진 기본 설정의 노드도 영향을 받는다고 밝혔고, 시스템 충돌이나 메모리 손상 가능성도 함께 설명했습니다. 영향을 받는 범위와 코드 실행이 실제로 시연된 환경은 구분해서 봐야 합니다.

Q. 이 취약점이 실제 공격에 악용되고 있나요?

A. Anthropic과 Red Hat 두 공지 모두 실제 공격에 악용된 사례는 언급하지 않았습니다. 다만 Anthropic이 공격 시연 내용을 공개한 만큼 패치 적용을 미루지 않는 것이 좋습니다.

Q. IPv6만 쓰면 괜찮은가요?

A. Ubuntu 보안 페이지의 설명에 따르면 첫 번째 문제는 IPv6에는 해당하지 않습니다. 다만 같은 설명에서 IPv6에도 연결 요청 이동 과정의 비슷한 문제가 있고, 이는 별도 패치로 다룰 예정이라고 밝혔습니다. IPv6만 쓴다고 해서 안전하다고 단정하지 말고 배포판 공지를 확인해야 합니다.

Q. 커널 업데이트 후 반드시 재부팅해야 하나요?

A. 일반적으로 커널은 재부팅해야 새 버전이 적용됩니다. 재부팅 후 uname -r 명령으로 실행 중인 커널 버전이 바뀌었는지 확인합니다. 무중단 커널 패치 서비스를 쓰는 환경이라면 해당 서비스의 안내를 따릅니다.

Q. 클라우드 서버나 컨테이너는 어떻게 하나요?

A. Red Hat은 OpenShift 노드가 영향을 받는다고 안내했고, 노드가 쓰는 RHEL CoreOS 커널을 최신으로 맞추라고 밝혔습니다. 그 밖의 클라우드 가상 서버와 컨테이너 환경은 공지에 별도 설명이 없으므로, 일반적으로 컨테이너가 호스트 커널을 함께 쓴다는 점을 감안해 호스트 커널과 사용 중인 배포판 공지를 확인하는 것이 좋습니다.

[콘텐츠 출처]

Anthropic Research, Discovering and exploiting vulnerabilities in critical, real-world software with Claude (2026.10.27)

Red Hat, RHSB-2026-016 Use-after-free - kernel IPv4 (2026.10.30 게시, 페이지 표기 기준 2026.11.02 갱신)

Red Hat Customer Portal, CVE-2026-98432

Ubuntu Security, CVE-2026-98432 (2026.10.30 갱신)