CVE-2026-98432: Ubuntu와 RHEL은 여전히 패치가 없고, Claude 모델은 이미 익스플로잇을 작성했다

CVE-2026-98432에 관한 두 가지 사실은 함께 놓으면 불편하다. 이는 Linux 커널의 IPv4 TCP 핸드셰이크에서 발생하는 use-after-free로, 로그인도 상호작용도 없이 네트워크를 통해 도달할 수 있으며, 커널 CVE 팀은 이에 9.8점을 부여했다. 2026년 10월 30일 기준 Ubuntu는 22.04, 24.04, 26.04, 26.10용으로 출시된 수정이 없고, Red Hat은 RHEL 8, 9, 10을 영향을 받는 버전으로 등재했지만 수정도, 승인된 완화 조치도 없다. 두 번째 사실은 10월 27일 Anthropic이 발표한 연구로, 미공개 Claude 모델이 MPTCP 리스너가 있는 서버에 대해 인증 없이 원격 루트 권한을 얻는 작동하는 개념 증명을 만들어냈다는 내용이다 — 커널 주소를 유출하는 데 약 48분, 명령 실행까지는 5분이 더 걸렸다.

두 대형 엔터프라이즈 리눅스 벤더가 아직 패치하지 못한 취약점에, 부분적으로 기계가 작성한 실제 동작하는 익스플로잇까지 갖춘 상황은 결코 정기적인 Patch Tuesday가 아니다. 이것은 커널 업그레이드 프로세스와 에이전트 접근 정책이 서로 관련이 있는지 여부를 결정하는 사건이다.

버그, 한 문단으로

TCP 연결이 설정되는 동안 수신 패킷에 첨부된 IP 옵션은 복사되지 않고 새 소켓에 전달됩니다. 핸드셰이크가 재전송되면 해당 패킷은 옵션 버퍼를 소유한 CPU와 다른 CPU에서 처리될 수 있으며, 그러면 두 번째 CPU가 첫 번째 CPU가 이미 해제한 메모리를 읽을 수 있습니다. 요청 마이그레이션 경로에도 유사한 경쟁 조건이 존재합니다. 영향을 받는 범위는 커널 4.4부터 시작됩니다. 즉, 유지 관리되는 커널을 여전히 실행 중인 대부분의 머신이 해당됩니다. 업스트림 수정인 커밋 code>e3f33b0a1d89/code>는 다른 코어가 더 이상 참조를 보유할 수 없을 때까지 옵션 버퍼 해제를 지연합니다.

악용 가능성은 그 메커니즘에서 비롯됩니다. 인증 없음, 사용자 상호작용 없음, 네트워크에서 접근 가능한 경로, 그리고 반복 시도가 가능한 경쟁 조건입니다. PoC가 실용적인 이유에 대한 Anthropic 자체의 요약은 바로 그 속성입니다. 즉, 경쟁에서 지면 한 번의 핸드셰이크가 실패할 뿐 머신이 크래시하지 않으므로 공격자는 다시 시도합니다.

세 공급업체, 세 가지 심각도 수치

점수 분할은 체화할 만한 부분입니다. 왜냐하면 그것이 이번 주에 스캐너가 티켓을 열지 여부를 결정하기 때문입니다.

• 커널 CVE 팀 — 9.8, 치명적. 네트워크에서 접근 가능, 권한 필요 없음, 상호작용 필요 없음.

• Red Hat — 8.1, 중요. 회사의 입장은 그 경쟁에서 실질적으로 이기기 어렵다는 것입니다.

• Ubuntu — 높은 우선순위이며, 확인한 페이지에는 숫자 점수가 게시되지 않았습니다.

9.8과 8.1 사이의 격차는 버그에 대한 견해 차이가 아니라, 레이스에서 이길 확률에 대한 견해 차이다. 둘 다 방어 가능한 주장이며, 그 차이는 운영상 중요하다. 공개 PoC가 있는 9.8은 비상 상황이고, 어려운 레이스가 있는 8.1은 예정된 수정 작업이다. 누군가 실제 하드웨어에서 재현 수치를 발표하기 전까지는, 프런티어 모델이 이를 이겼다고 보고되었으므로 레이스는 이길 수 있다는 것이 정직한 해석이다.

누가 해결책을 가지고 있고, 누가 그렇지 않은가

10월 29–30일 기준으로 상황은 고르지 않은데, 이는 안정적인 커널이 곧 패치된 커널이라고 가정하는 이들을 잡아채는 양상이다.

• Debian 12 bookworm — 6.1.190-1에서 DLA-4841-1을 통해 수정되었습니다.

• Debian 13 trixie — DSA-6568-1을 통해 6.12.113-1에서 수정되었습니다.

• Ubuntu 22.04, 24.04, 26.04, 26.10 — 릴리스된 수정 버전 없음, 작업 진행 중.

• Ubuntu 16.04, 18.04, 20.04 — 취약함, 수정 버전 미배포.

• RHEL 8, 9, 10 및 OpenShift 4 — 영향을 받았으며, 수정 버전이 없고 Red Hat이 승인한 완화 조치도 없습니다.

• RHEL 6 및 7 — 영향을 받지 않음.

• Amazon Linux 2023 — 커널 6.18은 수정된 것으로 보고됨; Oracle Linux UEK는 수정된 것으로 보고됨; SUSE는 일부 릴리스는 수정되었고 다른 릴리스는 여전히 테스트 중이라고 보고하면서 버전은 명시하지 않음.

수정 사항을 포함하는 업스트림 안정 릴리스는 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3이며, 이는 배포판 패키지를 사용하지 않고 커널을 직접 컴파일하는 경우 자신의 빌드와 대조해 확인해야 할 목록입니다.

MPTCP가 계속 등장하는 이유

이 버그는 MPTCP에만 국한된 문제가 아니며, 바로 이 지점에서 많은 보도가 잘못된다. Red Hat은 접근 가능한 모든 TCP 서비스를 잠재적 트리거로 간주한다. MPTCP가 제공하는 것은 입증된 경로이고, 트래픽을 제공하는 것은 Go다. 버전 1.24 이상의 Go는 커널에서 MPTCP가 켜져 있으면 Linux 리스닝 소켓에 대해 기본적으로 멀티패스 TCP를 활성화한다. Go 보안팀은 10월 29일 이 조합에 대해 경고했다.

따라서 "MPTCP를 비활성화"하는 것은 Anthropic이 입증한 경로를 제거할 뿐 취약점 자체를 제거하지는 않는다. 이는 특정한 단서가 붙은 방어 가능한 임시 조치다. 오늘날 Go 서비스에서 해 둘 만한 가치가 있으며, 패치된 커널을 대체하는 것은 아니다.

검사는 짧습니다:

• code>ss -Mltnp/code> — 현재 MPTCP를 사용 중인 소켓을 나열합니다.

• code>net.mptcp.enabled/code> — 커널 기능이 애초에 켜져 있는지 여부입니다.

• code>net.ipv4.tcp_migrate_req — 기본적으로 꺼져 있습니다. 켜 두었다면 다시 꺼 주세요.

특히 Go의 경우, code>GODEBUG=multipathtcp=0/code>을 런타임에 설정하거나, code>godebug/code> 줄을 code>go.mod/code>에 추가하면 바이너리에서 이 기능을 사용하지 않도록 설정됩니다.

이 중 어느 것도 공급업체가 보증한 것이 아니다. Red Hat은 자사 기준을 충족하는 완화 조치가 없다고 분명히 밝히는데, 이는 희망을 걸어볼 만한 우회 방안 목록보다 더 유용한 문장이다.

Anthropic이 실제로 발표한 내용

연구는 범위가 좁고 특정적이다. 아직 공개되지 않은 Claude 모델에 CVE와 MPTCP 리스너가 있는 대상을 주었을 때, 이 모델은 약 48분 만에 커널 주소를 유출하는 체인을 생성했고 약 5분 뒤에는 명령 실행에 도달했다. Anthropic은 해당 익스플로잇을 공개하지 않았으며, 10월 29일 기준으로 벤더와 CVE 기록 모두 실제 공격이 발생했다고 보고하지 않았다. 이 취약점은 CISA의 KEV 목록에 없다. 10월 30일에는 제3자 GitHub 저장소가 레이스 조건 트리거 및 메모리 유출 실험 도구, 즉 전체 코드 실행에는 이르지 않는 재현 하네스를 공개했다.

그 조합이 흥미로운 부분이다. 능력은 입증되었고, 무기는 공개되지 않았으며, 이를 가능하게 하는 세부 사항, 즉 취약한 경쟁 상태를 신뢰할 수 있는 상태로 바꾸는 재시도 속성은 글로 공개되어 있다. 이제 그 경쟁 상태를 재현할 수 있는 사람은 그것을 계속 밀고 나갈 가치가 있는 이유를 알게 된다.

이번 주에 할 일

• 수정 사항이 있는 경우 패치하고 재부팅하십시오. 설치되었지만 재부팅되지 않은 커널 수정은 수정이 아닙니다. 다음을 통해 확인하십시오: code>uname -r/code>

• 패치가 없는 배포판 — Ubuntu 22.04~26.10, RHEL 8~10 — 의 경우, 벤더의 라이브 패치를 적용할지, 수정된 버전으로 이동할지, 아니면 Go 서비스에서 MPTCP를 끈 상태로 노출을 감수할지 지금 결정하십시오.

• MPTCP 노출 여부를 가정하지 말고 인벤토리로 파악하세요. 기본값은 구성이 아니라 Go에서 변경되었으며, 기본값 변경은 구성 diff에서 보이지 않습니다.

• 재부팅을 미리 연습하세요. 이런 종류의 수정에는 완전한 재시작이 필요하며, 가장 많은 시간을 잃는 조직은 유지보수 시간 창 안에서 장애 조치(failover) 절차를 처음으로 확인하는 조직입니다.

이 CVE가 실제로 제기하는 두 가지 질문

첫 번째는 익스플로잇 생성에 관한 것이며, 철학적인 문제가 아니다. 한 모델이 아주 많은 인간 연구자들이 찾지 못한 시퀀스를 특정한 활성화 구성을 갖춘 타깃에서 한 시간 이내에 찾아냈다. 익스플로잇이 공개되든 되지 않든, 시간표는 바뀌었다: 공개 권고문과 작동하는 익스플로잇 사이의 간격은 이제 그 권고문을 읽는 모델들을 기준으로 측정된다.

두 번째는 벤더가 패치할 수 없을 때 패치가 무엇을 의미하는지에 관한 것입니다. 커널을 제공하는 배포판과 수정 사항이 포함된 커널은 같은 객체가 아니며, 그 둘 사이의 간극이 바로 이 글의 독자 대부분에게 이 취약점이 존재하는 곳입니다. OrcaRouter AI Incident Archive는 이와 같은 사건을 원출처, 심각도, 신뢰도를 기준으로 인덱싱하며, 이는 뉴스 주기가 지나간 뒤에도 남겨둘 가치가 있는 버전의 이야기입니다.

하지 말아야 할 일은 이것을 “공급업체를 기다리자”는 항목으로 분류하는 것입니다. 공급업체 자체 페이지에도 아직 기다릴 것이 없다고 나와 있습니다.

출처 주석: 메커니즘, 커널 4.4부터의 영향 범위, 업스트림 커밋 code>e3f33b0a1d89/code>, 안정 버전 목록 및 완화 지침은 2026년 10월 30일에 열람한 CVE 기록과 배포판 권고문에서 비롯됩니다. 9.8, 8.1 및 Ubuntu High 등급은 각각 커널 CVE 팀, Red Hat, Canonical의 것입니다. 배포판별 패치 상태는 Debian의 DLA-4841-1 및 DSA-6568-1, Red Hat과 Ubuntu의 CVE 페이지, 그리고 같은 날짜의 벤더 성명에서 비롯됩니다. 개념 증명 타임라인, 48분 및 5분 수치, 재시도 속성은 익스플로잇을 공개하지 않은 Anthropic의 10월 27일 연구에서 나온 것입니다. 10월 30일 실험실 저장소는 제3자 것으로 설명되며 우리 것이 아닙니다.