Linux 커널의 TCP 코드에서 발견된 취약점은 CVE-2026-98432로 추적되며, Ubuntu, Red Hat Enterprise Linux (RHEL) 및 기타 리눅스 배포판에 영향을 미칩니다. 해당 커널 자체 CVE 팀은 이 취약점에 대해 CVSS 척도에서 10점 만점에 9.8점을 매겼습니다.
Anthropic은 10월 27일, 자사의 AI 모델이 이 취약점을 이용해 원격 공격자가 자격 증명 없이 Linux 서버의 multipath TCP 리스너를 통해 root 권한으로 명령을 실행할 수 있게 하는 익스플로잇(exploit)을 작성했다고 밝혔습니다.
10월 29일 기준으로, Ubuntu와 RHEL은 패치된 커널을 아직 출시하지 않았습니다. Red Hat, Amazon, Oracle, SUSE는 이 취약점의 점수를 5.9점에서 8.1점 사이로 매겨 커널 팀이 제시한 9.8점보다 낮은 수치를 보였습니다.
이 취약점은 새로운 IPv4 TCP 연결을 설정하는 코드에 존재하는 경쟁 조건(race condition)입니다. 이는 커널이 이미 해제된 메모리를 읽게 만드는 버그 유형으로, use-after-free로 알려져 있습니다.
커널 패치는 Anthropic 연구원 Xinyang Ge가 이 버그를 보고한 공을 인정했습니다. CVE 기록이나 수정 사항 어디에도 multipath TCP (MPTCP)에 대한 언급은 없습니다. 해당 기능과 이 버그 사이의 연결고리는 Anthropic이 올린 게시물에서 비롯되었습니다.
MPTCP는 하나의 연결이 여러 네트워크 경로를 동시에 사용할 수 있도록 합니다. Linux에서는 애플리케이션이 소켓을 열 때 MPTCP를 요청해야 합니다. Go Security Team은 10월 29일, Go 1.24 버전부터는 Go 프로그램들이 리스닝하는 소켓에 대해 기본적으로 이를 수행한다고 밝혔습니다.
Anthropic의 게시물에 따르면 이 취약점은 “업스트림에서 패치되었으며 모든 유지보수 안정 커널 브랜치로 백포팅(backported)되었다”고 합니다. 배포판 사용자들에게는 해당 수정 사항이 벤더의 커널 패키지를 통해서만 도착합니다. Debian, Oracle Linux, SUSE, Amazon Linux 등은 적어도 일부 커널에 대해서는 패치된 패키지를 배포했지만, Ubuntu와 RHEL은 아직 그렇지 못했습니다.
패치가 적용된 배포판은 무엇인가요?
| 배포판 | 벤더 평점 | 10월 29일 기준 상태 | 패치된 패키지 또는 권고 사항 |
|---|
| Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS 및 26.10 | Priority High | 작업 진행 중 (Work in progress) | 출시됨 없음 (None released) |
| ... | Moderate, 5.9 (CVE 페이지) Important, 8.1 (권고 파일) | 영향을 받음 (Affected) | 출시됨 없음 (None released) |
| RHEL 7 | 해당 사항 없음 (Not applicable) | 영향받지 않음 (Not affected) | 필요하지 않음 (Not needed) |
| Amazon Linux 2023, kernel6.18 패키지 | Important, 7.0 | 10월 24일 패치됨 (Fixed October 24) | kernel6.18-6.18.56-125.164.amzn2023 (ALAS2023-2026-3251) |
| Amazon Linux 2023, kernel6.12 패키지 | Important, 7.0 | Amazon 권고 사항에 따라 10월 29일 패치됨; Amazon의 CVE 페이지는 여전히 보류 중 (Fixed October 29 in Amazon's advisory; Amazon's CVE page still says pending) | kernel6.12-6.12.113-138.209.amzn2023 (ALAS2023-2026-3335) |
| Amazon Linux 2, kernel 패키지 | Important, 7.0 | 패치 대기 중 (Pending fix) | 출시됨 없음 (None released) |
| Oracle Linux 7, 8, 9 및 10, UEK 커널 | Important, 8.1 | 10월 16일 패치됨 (Fixed October 16) | ELSA-2026-500397, ELSA-2026-500398, ELSA-2026-500399 |
| Debian trixie (stable) | 점수 없음 (No score listed) | 10월 16일 패치됨 (Fixed October 16) | linux 6.12.113-1 (DSA-6568-1) |
| Debian 12 (bookworm) | 점수 없음 (No score listed) | 10월 17일 및 10월 22일 패치됨 (Fixed October 17 and October 22) | linux 6.1.190-1 (DLA-4841-1)<br>linux-6.12 6.12.113-1~deb12u1 (DLA-4850-1) |
| SUSE Linux Micro 6.2, openSUSE Leap 16.0 | Important, 8.1 | 패치됨 (Fixed) | kernel-default 6.12.0-160000.40.1 이상 (or later) |
| SLES 15 SP4 ~ SP6 LTSS, SLES 16.0, SLE Micro 5.3 ~ 5.5 | Important, 8.1 | 테스트 중 (In testing) | 출시됨 없음 (None released) |
| SLES 15 SP7 | Important, 8.1 | 영향을 받음, 패치 진행 중 (Affected, fix in progress) | 출시됨 없음 (None released) |
Ubuntu는 또한 cloud, FIPS 및 real-time 커널을 취약하거나 작업 진행 중인 것으로 나열했습니다. Red Hat은 10월 29일, 해당 패치가 “향후 업데이트로 현재 보류되고 있다”고 밝혔습니다. 10월 30일까지 Red Hat은 RHEL 8, 9 및 10과 OpenShift 4를 '패치 대기 중'이 아닌 '영향 받음(Affected)'으로 나열했습니다. Red Hat이나 Ubuntu 어느 쪽도 출시 날짜를 제공하지 않았습니다.
취약점 작동 원리 (How the Bug Works)
레이스 컨디션(Race condition)은 TCP 핸드셰이크 과정에서 발생합니다. 연결이 완료되면, 커널은 보류 중인 요청에 저장된 IP 옵션을 복사하지 않고 새 소켓으로 전달합니다.
만약 해당 소켓이 다른 CPU가 재전송된 연결 요청에 대한 응답을 위해 여전히 옵션을 사용하고 있는 동안 파괴된다면, 커널은 해제된 메모리를 읽게 됩니다.
IPv6는 커널이 IPv6 연결의 옵션을 복사하기 때문에 이 레이스 컨디션의 영향을 받지 않습니다.
이 버그는 Linux 4.4에서 도입되었으며, 커널 개발자들은 CVE가 공개되기 10일 전인 10월 5일에 수정 사항을 적용했습니다.
수정된 내용은 다른 CPU들이 옵션을 읽는 작업을 마칠 때까지 커널이 기다린 후에 메모리를 해제하도록 합니다.
점수가 다른 이유
커널의 CVE 팀은 CVE를 공개한 지 9일 후인 10월 24일에 해당 CVE 기록에 9.8점을 추가했습니다.
해당 점수는 공격자가 IPv4 Record Route 또는 Timestamp 옵션을 포함하는 TCP 연결 요청을 보내고, 이어서 재요청하여 레이스를 이기려고 시도하는 경우를 가정합니다. 팀은 양쪽 모두가 "공격자 유발(attacker-induced)"이라고 평가하며 공격 복잡도를 낮게 책정했습니다.
이 경우, 해당 버그는 근처 커널 메모리를 공격자에게 전송하거나, 커널 메모리를 손상시키거나, 시스템을 충돌시킬 수 있다고 팀은 설명합니다.
10월 28일 기준으로 National Vulnerability Database (NVD)는 자체 점수를 추가하지 않았고, 커널 팀이 제시한 9.8점을 보여주었습니다. Ubuntu 페이지 역시 해당 점수를 보여줍니다.
Red Hat의 CVE 페이지는 이 결함을 'Moderate'로 평가하며, 레이스를 이기기가 어렵다는 이유로 5.9점을 부여했습니다. 여기서는 가장 가능성이 높은 결과가 커널 충돌이며, 메모리 손상은 이론적으로 가능할 뿐이고 "기밀성 또는 무결성에 대한 영향은 입증되지 않았다"고 명시합니다.
10월 29일에 업데이트된 Red Hat의 기계 판독 가능한 권고 파일(advisory file)에서는 영향을 'Important'로 나열하고, 높은 기밀성과 무결성 영향을 바탕으로 이 결함에 8.1점을 부여했습니다. Red Hat의 버그 추적기(bug tracker)는 같은 날 해당 이슈의 심각도를 medium에서 high로 변경했습니다. 이날 CVE 페이지는 Moderate와 5.9를 보여주었습니다.
Oracle과 SUSE 역시 이 취약점을 8.1점으로 평가했으며, 이는 Red Hat의 권고 파일과 동일한 CVSS 벡터를 사용합니다. 이러한 점수는 공격 복잡성(attack complexity)을 제외한 모든 지표에서 커널 팀의 평가와 일치하지만, 공급업체들은 이를 높게 평가하고 커널 팀은 낮게 평가했습니다. Amazon은 7.0점을 부여했습니다.
Anthropic이 구축했다고 밝힌 내용
Anthropic은 AI 모델 Claude가 발견하고 악용한 취약점에 대한 게시물에서 리눅스 익스플로잇(exploit)에 대해 설명했습니다. 이 내용은 Hacker News를 통해 10월 28일에 다루어졌습니다. Anthropic에 따르면, Claude는 '초기 프롬프팅(initial prompting)'을 거쳐 익스플로잇 코드를 작성했습니다.
이 익스플로잇은 두 단계로 작동합니다. 첫째, 레이스 컨디션(race)을 이용해 커널이 공격자에게 추가 바이트를 전송하게 만듭니다. 이 응답 중 하나에 커널 주소(kernel address)가 포함되면, 공격자는 커널의 메모리 주소 무작위화 기술인 KASLR(Kernel Address Space Layout Randomization)을 우회할 수 있습니다.
둘째, 동일한 버그는 버퍼 오버플로우(buffer overflow)를 일으켜 콜백 포인터(callback pointer)를 공격자가 이미 커널 메모리에 배치해 둔 페이로드(payload)의 주소로 덮어씁니다. 커널이 이 포인터를 호출할 때, 페이로드가 실행되어 공격자가 선택한 셸 명령어(shell command)가 root 권한으로 실행됩니다.
회사는 레이스 컨디션이 발생하면 해당 연결 시도만 실패할 뿐 시스템 전체를 충돌시키지는 않기 때문에, 공격자는 계속 시도할 수 있다고 밝혔습니다. 테스트 결과, 커널 주소를 유출하는 데 48분이 걸렸고, 명령어 실행에 도달하는 데는 추가로 5분이 소요되었습니다.
해당 게시물에는 익스플로잇 코드, Anthropic이 테스트한 커널 버전 또는 구성 정보가 포함되어 있지 않습니다.
Red Hat은 노출된 TCP 서비스에 접근할 수 있는 원격 공격자가 이 레이스를 유발할 수 있다고 말합니다. 하지만 Anthropic의 root 익스플로잇은 멀티패스 TCP 리스너(multipath TCP listener)를 가진 서버를 목표로 했습니다. 게시물에는 이러한 리스너가 없는 서버도 동일한 방식으로 장악될 수 있는지 여부는 언급되어 있지 않습니다.
10월 29일 기준으로, 공급업체들의 권고 사항, CVE 기록, 또는 Anthropic의 게시물 어디에서도 이 취약점을 이용한 공격이 보고된 바 없습니다. 이는 룩셈부르크의 CIRCL이 10월 28일에 마지막으로 업데이트한 CISA의 알려진 악용 취약점(Known Exploited Vulnerabilities) 카탈로그에도 나타나지 않습니다.
현재 취해야 할 조치
배포판에서 패치된 커널을 출시했다면, 해당 버전을 설치해야 합니다. 위 표에는 Debian, Oracle Linux, SUSE 및 Amazon Linux에 대한 패키지 및 권고 사항이 나열되어 있습니다.
직접 커널을 빌드하는 경우, 수정 버전은 Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 및 7.3에 포함되어 있습니다. 커널의 CVE 팀은 최신 안정화된 커널로 업데이트할 것을 권장합니다. 해당 팀은 커널 커뮤니티가 개별적인 수정 사항을 선택적으로 적용하는 것(cherry-picking)을 지원하지 않는다고 밝혔습니다.
Ubuntu, RHEL 및 일부 Amazon Linux와 SUSE 릴리스는 아직 설치할 패치된 커널이 없습니다. Red Hat에 따르면 현재 사용 가능한 완화 방법 중 배포가 용이하고 대부분의 설치 환경에 적합하며 안정적이라는 기준을 충족하는 것이 없다고 합니다. 다른 배포판들의 권고 사항에서도 이를 나열한 곳은 없습니다.
각 배포판의 권고 사항과 Anthropic의 게시물 모두 커널에서 멀티패스 TCP(Multipath TCP)를 비활성화하거나 IP 옵션을 포함하는 수신 연결 요청을 차단하는 것이 위험도를 낮출지 여부에 대해서는 언급하지 않았습니다.
Go 프로그램의 경우, Go Security Team은 프로그램 환경 변수에 GODEBUG=multipathtcp=0을 설정하면 런타임 시 기본적으로 MPTCP를 비활성화한다고 말합니다. 메인 모듈의 go.mod 파일에 godebug multipathtcp=0을 추가하는 것도 빌드 시점에 동일한 효과를 내지만, SetMultipathTCP를 호출하는 코드는 이 두 가지 설정을 모두 무효화(override)시킵니다.
해당 팀은 프로그램별로 MPTCP를 비활성화하는 것을 취약한 완화 방법이라고 지적합니다. 노출된 MPTCP 리스너 하나만 남아 있어도 시스템이 여전히 취약하며, 이 접근 방식은 모든 작동 가능한 익스플로잇(exploit)이 MPTCP에 의존한다고 가정하고 있습니다.
또한 해당 팀은 근본적인 버그가 MPTCP에 국한된 것이 아니며, MPTCP 리스너가 없는 시스템도 유사한 공격에 취약할 수 있고, 가장 좋은 해결책은 패치된 커널로 업그레이드하는 것이라고 말합니다.
*(이 기사는 Go 프로그램에 대한 Go Security Team의 지침을 추가하고 Red Hat이 '패치 보류(Fix deferred)' 대신 RHEL 8, 9 및 10과 OpenShift 4를 '영향 받음(Affected)'으로 명시하도록 업데이트되었습니다.)
