확인된 것
구멍은 진짜 있다
2026년 10월 15일 공개된 리눅스 커널 취약점이고, 우분투 CVE 페이지는 우선순위 High, CVSS 9.8로 표시합니다. Anthropic은 10월 27일 글에서 자사 AI 모델이 이 버그로 인증 없이 원격 root 명령 실행까지 가는 익스플로잇을 썼다고 밝혔습니다.
00. 잠깐, “뚫렸다”는 정확히 무슨 뜻?
벨로키: 뉴스 제목만 보면 전 세계 우분투가 털린 줄 알겠다진정해. 숫자부터 차분히 보자
아직 아닌 것
“실제로 털렸다”는 보고는 없다
10월 29일 기준으로 실제 공격(야생 악용) 보고는 벤더·CERT·커널 CVE팀 어디에도 없고, 미국 CISA의 악용 확인 목록(KEV)에도 없습니다. Anthropic도 익스플로잇 코드는 공개하지 않았습니다.
그래서 정확한 표현은: “우분투가 쓰는 리눅스 커널에 원격 root가 가능하다고 시연된 구멍이 있고, 우분투 패치는 아직 작업 중”입니다. 털린 건 아니지만, 느긋할 일도 아닙니다.
01. TCP 접속 = 가게 문 노크 세 번
STORY 01 · 접속
똑똑, 서버 가게 열었나요?벨로키가 들고 온 쪽지는 접속 요청에 붙은 정보야. 문을 두드리는 순서부터 따라가 보자.
서버에 접속할 때마다 컴퓨터끼리는 먼저 3단계 인사(3-way handshake)를 합니다. 웹사이트든 SSH든 DB든, TCP를 쓰는 서비스는 전부 이 인사부터 해요. 가게로 치면 이렇습니다.
🙋 손님: “계세요? 들어가도 돼요?”
SYN · 쪽지에 포스트잇(IP 옵션)을 붙일 수도 있음🏪 가게: “네, 들어오세요!”
SYN-ACK · 이때 손님 쪽지를 접수 대기표에 꽂아 둠🙋 손님: “그럼 들어갑니다”
ACK🏪 가게: 손님을 정식 자리로 안내
대기표 → 정식 손님 자리(자식 소켓)로 옮김
대기표 → 정식 손님 자리(자식 소켓)로 옮김
버튼을 눌러 노크 순서를 따라가 보세요.
잠깐! ‘재노크’가 뭐예요?
손님이
그럼 답장을 가로채는 건가요? 아니요. 여기서 공격의 핵심은 답장 가로채기가 아니라, 서버 안에서 재노크를 처리하는 작업과 메모리를 해제하는 작업의 순서가 엇갈리는 것입니다. 예를 들어 답이 늦게 도착해 접속이 진행되는 사이 재전송도 함께 처리될 수 있어요. 공격자는 특수한 요청과 타이밍을 이용해 해제된 메모리가 다시 쓰이도록 시도할 수 있지만, 재노크 한 번만으로 성공하는 것은 아닙니다. 아래 그림은 이 복잡한 과정을 단순화한 개념 설명이에요.
손님이
SYN으로 노크했는데 가게의 답 SYN-ACK이 유실되거나 늦게 도착하면, 손님은 답을 못 들었다고 생각해 같은 요청을 다시 보낼 수 있어요. 이게 재노크(SYN 재전송)입니다. 네트워크에서 정상적으로 일어나는 일이에요.그럼 답장을 가로채는 건가요? 아니요. 여기서 공격의 핵심은 답장 가로채기가 아니라, 서버 안에서 재노크를 처리하는 작업과 메모리를 해제하는 작업의 순서가 엇갈리는 것입니다. 예를 들어 답이 늦게 도착해 접속이 진행되는 사이 재전송도 함께 처리될 수 있어요. 공격자는 특수한 요청과 타이밍을 이용해 해제된 메모리가 다시 쓰이도록 시도할 수 있지만, 재노크 한 번만으로 성공하는 것은 아닙니다. 아래 그림은 이 복잡한 과정을 단순화한 개념 설명이에요.
여기서 중요한 등장인물은 포스트잇입니다. IPv4 패킷에는 “지나온 길을 기록해 줘(Record Route)”, “시간 찍어 줘(Timestamp)” 같은 옵션을 붙일 수 있어요. 커널은 이 포스트잇을 메모리에 따로 보관합니다.
02. 구멍: 이미 파쇄한 포스트잇을 옆 직원이 읽는다
STORY 02 · 타이밍
잠깐, 아직 읽고 있었는데?!한 직원은 읽는 중, 다른 직원은 파쇄 중. 두 작업의 타이밍이 엇갈리면 문제가 생겨.
벨로키: 그 포스트잇 아까 파쇄기에 넣었는데요?옆 직원: …나 지금 그거 읽는 중인데
문제는 3단계에서 4단계로 넘어갈 때 생깁니다. 커널은 손님을 정식 자리로 옮기면서 포스트잇을 복사하지 않고 원본을 그대로 넘겨요. 정식 손님이 나가면 그 포스트잇은 즉시 파쇄됩니다(kfree).
그런데 손님이 같은 노크(SYN)를 한 번 더 보내면, 다른 CPU의 직원이 “어, 답장 다시 보내줘야지” 하면서 대기표에 꽂힌 같은 포스트잇을 읽습니다. 이 직원은 “읽는 중” 표시만 하고 잠그지 않아요(rcu_read_lock). 타이밍이 딱 맞으면 이미 파쇄된 종이를 읽게 됩니다. 이게 use-after-free(해제 후 사용)입니다.
게임으로 치면 이미 상점에 팔아버린 아이템을 장착 버튼으로 누른 상태예요. 보통은 버그 메시지로 끝나지만, 공격자가 그 빈 슬롯에 자기가 원하는 데이터를 먼저 채워 두면 “팔린 칼” 대신 “내가 만든 칼”을 쥐여줄 수 있습니다. 그게 원격 코드 실행으로 이어지는 큰 그림입니다.
벨로키의 빈 칸 소동 · 개념 비유
파쇄된 쪽지 자리에 다른 쪽지가 들어오면?
① 직원 A: 접속이 정식 자리로 옮겨지고 이후 해당 연결이 끝나는 과정에서, 쪽지가 더는 필요 없다고 판단해 보관함을 비웁니다. ACK가 없어서 곧바로 파쇄한다는 뜻은 아니에요.
② 직원 B: 재노크에 답하려고 기존 대기표가 가리키던 쪽지를 읽습니다. 이때 B가 새 메모리를 할당하는 게 아니라, 이미 해제된 메모리를 여전히 참조할 수 있다는 게 문제예요.
③ 공격자의 시도: 비워진 보관함이 나중에 다른 쪽지에 재사용될 수 있다는 점을 노려, 공격자가 준비한 내용이 우연히 그 자리에 들어가도록 시도합니다. 실제로 같은 자리에 들어갈지는 메모리 할당과 타이밍 등 여러 조건에 달려 있어요.
④ 엇갈린 읽기: 그 자리에 다른 내용이 들어간 뒤 B가 이전 주소를 읽으면, 원래 포스트잇 대신 달라진 데이터를 볼 수 있습니다. 이것이 추가적인 악용의 출발점이 될 수 있지만, 데이터가 들어갔다고 곧바로 root가 되는 것은 아닙니다.
보관함과 쪽지는 메모리와 데이터를 설명하기 위한 비유입니다. 실제 내부 과정이나 공격 성공을 보장하는 순서는 아닙니다.
🦖 벨로키의 서랍: 그래서 어떻게 공격으로 이어져요?
직원 A가 쪽지를 버려 서랍을 비웠지만, 직원 B는 아직 그 서랍의 위치를 기억하고 있어요. 공격자는 서버에 새 데이터를 처리하게 해서, 그 내용이 마침 같은 빈 서랍에 들어가도록 시도합니다. 서버가 메모리를 재사용할 수 있다는 점을 노리는 거예요.
이후 B가 옛 주소를 보고 서랍을 열면 원래 쪽지 대신 공격자가 넣은 내용을 읽을 수 있어요. 서버가 그 내용을 옛 데이터처럼 처리하면 정보가 새거나 비정상적인 동작이 생길 가능성이 있습니다.
다만 “쪽지에 root라고 적으면 끝”은 아니에요. 같은 자리가 재사용되고 B가 그 내용을 읽는 것부터 여러 조건과 타이밍이 맞아야 해요. 코드 실행이나 root 권한까지 이어지려면 추가적인 악용 단계가 필요합니다. 이 서랍 이야기는 원리를 단순화한 비유이며, 이 취약점의 구체적인 공격 절차를 보여주는 것은 아닙니다.
직원 A가 쪽지를 버려 서랍을 비웠지만, 직원 B는 아직 그 서랍의 위치를 기억하고 있어요. 공격자는 서버에 새 데이터를 처리하게 해서, 그 내용이 마침 같은 빈 서랍에 들어가도록 시도합니다. 서버가 메모리를 재사용할 수 있다는 점을 노리는 거예요.
이후 B가 옛 주소를 보고 서랍을 열면 원래 쪽지 대신 공격자가 넣은 내용을 읽을 수 있어요. 서버가 그 내용을 옛 데이터처럼 처리하면 정보가 새거나 비정상적인 동작이 생길 가능성이 있습니다.
다만 “쪽지에 root라고 적으면 끝”은 아니에요. 같은 자리가 재사용되고 B가 그 내용을 읽는 것부터 여러 조건과 타이밍이 맞아야 해요. 코드 실행이나 root 권한까지 이어지려면 추가적인 악용 단계가 필요합니다. 이 서랍 이야기는 원리를 단순화한 비유이며, 이 취약점의 구체적인 공격 절차를 보여주는 것은 아닙니다.
벨로키 가게 · 연구진이 설명한 공격의 큰 흐름
바뀐 쪽지가 어떻게 root 명령까지 이어졌을까?
Anthropic은 MPTCP 접속을 받는 리눅스 서버를 대상으로 한 실험에서 이 버그를 여러 단계로 연결했다고 설명합니다. 아래는 그 내용을 단순화한 가게 비유예요.
① 가게 내부 지도가 새어 나와요. 공격자가 바뀐 쪽지를 읽는 실수를 이용해 직원 B가 답장에 원래보다 많은 내용을 담도록 만들어요. 그 안에 가게의 숨겨진 내부 위치 정보가 섞여 나오면서 커널 메모리 위치를 알아냅니다.
② 업무 안내판이 바뀌어요. 같은 버그를 다시 이용해 메모리의 내용을 덮어쓰고, 직원이 다음에 어디로 가서 일할지 알려 주는 안내판(콜백 포인터)을 바꿉니다.
③ 직원이 잘못된 곳으로 가요. 서버가 그 안내판을 따라가면 공격자가 미리 준비한 동작으로 실행 흐름이 넘어가고, 기존 커널 기능들을 거쳐 공격자가 고른 명령이 root 권한으로 실행됐다고 연구진은 밝혔어요.
왜 root인가요? 일반 손님이 사장 열쇠를 직접 받은 게 아니라, 가게 전체를 관리하는 커널 권한으로 일하는 직원의 업무 흐름이 바뀐 거예요.
이것은 연구진이 발표한 특정 실험의 개념적 설명입니다. 바뀐 쪽지를 한 번 읽었다고 자동으로 root가 되는 것은 아니며, 여러 조건과 추가 단계가 필요합니다. Anthropic 연구 발표 원문
🎮 타이밍 시뮬레이터 (개념 설명용)
CPU A
정식 자리
정식 자리
CPU B
재노크 답장
재노크 답장
실제 공격 절차나 수치가 아니라, “누가 먼저 버리고 누가 늦게 읽느냐”만 보여주는 그림입니다.
고친 방법: “다 읽을 때까지 기다렸다 파쇄”
수정 패치는 포스트잇을 바로 버리지 않고 RCU 유예 시간이 지난 뒤에 버리도록 바꿨습니다(kfree_rcu). 쉽게 말해 “지금 이 종이 읽는 사람 있어요?”를 한 바퀴 확인하고 나서 파쇄기에 넣는 거예요. IPv6는 원래 포스트잇을 복사해서 넘기기 때문에 이 첫 번째 문제는 없다고 우분투 공지에 적혀 있습니다.
언제부터
Linux 4.4 시절 코드
대기표를 리스너 잠금 없이 처리하게 바꾼 오래전 변경에서 시작됐다고 보도됐습니다. 즉 10년 가까이 숨어 있던 구멍.
조건
IPv4 + 옵션 + 재전송
커널 CVE팀 시나리오: IPv4 옵션이 붙은 SYN을 보내고 다시 보내 경쟁 상태(race)를 노림. 두 번째 경로는 tcp_migrate_req=1 등 소켓 이전 설정이 켜진 경우.
조용함
실패해도 티가 안 남
Anthropic에 따르면 타이밍을 놓치면 그 연결 하나만 실패하고 서버는 멀쩡합니다. 로그가 조용하다고 안전하다는 뜻은 아닙니다.
03. 같은 버그인데 왜 9.8점도 있고 5.9점도 있나
🦖 벨로키의 위험 경보: 9.8 / 10점이면 얼마나 심각해요?
CVSS는 취약점의 심각도를 0~10점으로 나타내는 기준이에요. CVSS 3.1에서 9.0~10.0은 Critical(심각)이고, 9.8은 그 구간에서도 높은 점수입니다. “성공 확률 98%”가 아니라, 평가 기준상 공격 조건과 성공 시 영향이 심각하다는 뜻이에요.
가게로 비유하면 밖에서 가게에 접근할 수 있고, 회원증이나 직원의 클릭이 필요 없다고 평가됐어요. 피해는 장부를 몰래 보는 일(기밀성), 장부를 바꾸는 일(무결성), 가게 문을 못 열게 하는 일(가용성)이 각각 크게 생길 수 있다고 봤습니다. 공격 복잡도 ‘낮음’은 CVSS의 조건 평가이며, 공격 구현이 쉽거나 매번 성공한다는 뜻은 아닙니다.
실제 위험은? 서버가 네트워크에 노출돼 있는지, 어떤 커널과 설정을 쓰는지, 수정이 적용됐는지 확인해야 해요. Ubuntu 공지는 별도로 CVSS 4.0에서 8.3점도 표시하며, 두 버전은 평가 체계가 달라 점수를 단순 비교할 수 없습니다. Ubuntu 공식 점수 · CVSS 3.1 기준
CVSS는 취약점의 심각도를 0~10점으로 나타내는 기준이에요. CVSS 3.1에서 9.0~10.0은 Critical(심각)이고, 9.8은 그 구간에서도 높은 점수입니다. “성공 확률 98%”가 아니라, 평가 기준상 공격 조건과 성공 시 영향이 심각하다는 뜻이에요.
가게로 비유하면 밖에서 가게에 접근할 수 있고, 회원증이나 직원의 클릭이 필요 없다고 평가됐어요. 피해는 장부를 몰래 보는 일(기밀성), 장부를 바꾸는 일(무결성), 가게 문을 못 열게 하는 일(가용성)이 각각 크게 생길 수 있다고 봤습니다. 공격 복잡도 ‘낮음’은 CVSS의 조건 평가이며, 공격 구현이 쉽거나 매번 성공한다는 뜻은 아닙니다.
실제 위험은? 서버가 네트워크에 노출돼 있는지, 어떤 커널과 설정을 쓰는지, 수정이 적용됐는지 확인해야 해요. Ubuntu 공지는 별도로 CVSS 4.0에서 8.3점도 표시하며, 두 버전은 평가 체계가 달라 점수를 단순 비교할 수 없습니다. Ubuntu 공식 점수 · CVSS 3.1 기준
| CVSS 3.1 항목 | 평가 | 벨로키 가게 비유 |
|---|---|---|
| 공격 경로 | 네트워크 | 밖에서 가게에 접근 가능 |
| 공격 복잡도 | 낮음 | CVSS 기준상 특수한 외부 조건이 필요하지 않다고 평가 |
| 필요 권한 / 사용자 행동 | 없음 / 없음 | 회원증이나 직원의 클릭이 필요 없음 |
| 영향 범위 | 변경 없음 | 같은 보안 권한 범위 안에서 영향 평가 |
| 기밀성 / 무결성 / 가용성 | 각각 높음 | 장부 유출 / 장부 변경 / 영업 중단의 피해 가능성 |
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H · 출처 확인 2026-10-30
점수는 “얼마나 쉽게 성공하느냐”를 어떻게 보느냐에 따라 갈렸습니다. 커널 CVE팀은 인증 없이 네트워크로 닿고 공격 난도도 낮다고 봤고, Red Hat은 경쟁 타이밍을 맞추기가 어렵다며 현실적 최악을 서비스 중단 정도로 봤어요.
9.8커널 CVE팀
우분투
우분투
8.1Oracle · SUSE
(RH VEX)
(RH VEX)
7.0Amazon
5.9Red Hat
공개 페이지
공개 페이지
10월 29일 보도 기준. Red Hat은 기계 판독용 VEX 데이터에선 8.1로 올렸다는 보도가 있으나 공개 페이지는 5.9였습니다.
벨로키 한 줄 요약: 점수 싸움은 전문가들한테 맡기고, 우리는 “Anthropic AI가 실험실에서 실제로 root까지 갔다”는 사실 하나만 기억하면 됩니다. 이론상 어렵다던 타이밍을 기계는 지치지 않고 계속 두드릴 수 있거든요.
04. 내 우분투는? 버전별 상태
우분투 CVE 페이지(10월 28일 갱신) 기준 linux 패키지 상태입니다. “작업 중” 옆의 버전은 수정 예정 패키지 번호이고, 배포 날짜는 적혀 있지 않습니다.
다른 배포판은 벌써 고쳤다
| 배포판 | 상태 (10/29 보도 기준) |
|---|---|
| Debian 13 / 12 | 수정 완료 (10/16~) |
| Oracle Linux (UEK) | 수정 완료 (10/16) |
| Amazon Linux 2023 | 일부 커널 수정, 기본 커널·AL2는 대기 |
| openSUSE Leap 16.0 등 | 일부 수정, SLES 일부는 진행 중(보도마다 차이) |
| RHEL 8·9·10, Alma·Rocky | 수정 보류(Fix deferred), 일정 미정 취약한 건 맞지만 수정 일정을 아직 잡지 않았다는 뜻입니다. “안 고친다”는 확정이 아니에요. Red Hat 공개 페이지는 타이밍 맞추기가 어렵다며 5.9(Moderate)로 봤지만, VEX 데이터에는 8.1(Important)로 올라갔다는 보도가 있어 등급이 재검토 중입니다. Alma·Rocky는 RHEL 소스를 다시 빌드하므로 보통 RHEL을 따라가지만, 각 배포판 공지를 따로 확인하세요. |
| Ubuntu 지원 릴리스 전부 | 취약, 수정 작업 중 |
업스트림 커널 수정 버전: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10, 7.3 (커널 CVE 공지를 인용한 보도 기준). 배포판 커널은 버전 번호가 달라도 수정이 백포트되므로 배포판 공지로 판단하세요.
05. MPTCP는 또 뭐야?
Anthropic이 공격에 성공했다고 밝힌 대상은 멀티패스 TCP(MPTCP) 리스너가 있는 서버였습니다. MPTCP는 와이파이와 LTE를 동시에 쓰는 것처럼 한 연결을 여러 길로 나눠 보내는 TCP 확장이에요.
알려진 것
리눅스에서 MPTCP는 기본으로 켜지는 게 아니라 앱이 요청해야 쓰입니다. 다만 Go 1.24 이상으로 만든 서버는 지원 환경에서 MPTCP 리스너를 기본으로 쓴다고 보도됐습니다.
모르는 것
CVE 기록과 패치에는 MPTCP 언급이 없습니다. MPTCP가 없는 서버도 같은 방식으로 털리는지는 아무도 공개적으로 말하지 않았어요. 그래서 “MPTCP 끄면 끝”이라고 믿으면 안 됩니다.
06. 지금 할 일 체크리스트
STORY 03 · 대응
업데이트하고 재부팅까지!벨로키의 방패는 수정된 커널이야. 실제로 적용됐는지 재부팅 후 버전까지 확인하자.
벨로키: 업데이트 했어요! …재부팅은요?커널은 재부팅해야 새 버전이 실제로 돌아갑니다
0 / 8 완료
# 지금 돌고 있는 커널 버전
uname -r
# 업데이트 가능한 커널 패키지 보기
apt list --upgradable 2>/dev/null | grep -i linux-image
# 소켓 이전 설정 (읽기만 함)
sysctl net.ipv4.tcp_migrate_req
# 최근 커널 로그에서 관련 크래시 흔적
sudo dmesg | grep -Ei 'ip_options_build|skb_under_panic'임시 방어 이야기: 일부 분석 글은 경계 방화벽에서 IPv4 옵션이 붙은 패킷을 버리는 방법을 “보조 수단”으로 제안합니다. 하지만 어떤 벤더도 이걸로 막힌다고 확인하지 않았고, Red Hat은 기준을 만족하는 완화책이 없다고 했습니다. 테스트 없이 믿지 말고, 본 처방은 커널 업데이트 + 재부팅입니다. Ubuntu Pro의 Livepatch 제공 여부는 공지를 확인하세요.
07. 자주 묻는 질문
집에서 쓰는 우분투 데스크톱도 위험한가요?
이 버그는 외부에서 들어오는 TCP 접속을 받는 쪽에서 터집니다. 공유기 뒤에 있고 외부로 열어 둔 서비스가 없는 데스크톱은 인터넷에 노출된 서버보다 위험이 낮습니다. 그래도 수정 커널이 나오면 업데이트하세요.
클라우드 VPS(AWS·GCP·Azure의 우분투)는요?
우분투 공지에 따르면 linux-aws, linux-azure, linux-gcp 같은 클라우드용 커널도 “취약·작업 중”입니다. 웹·SSH 포트가 인터넷에 열려 있는 서버가 가장 우선순위가 높습니다.
도커 컨테이너 이미지만 새로 받으면 되나요?
아니요. 컨테이너는 커널을 따로 갖지 않고 호스트 커널을 씁니다. 이미지 재빌드가 아니라 호스트(노드) 커널을 업데이트하고 재부팅해야 합니다.
AI가 해킹을 했다는 건 무슨 의미예요?
Anthropic은 내부 연구용 Claude 모델에 초기 지시를 준 뒤 모델이 익스플로잇을 작성했다고 밝혔고, 실험 환경에서 커널 주소 유출까지 약 48분, 이후 5분 만에 root 명령 실행에 성공했다고 했습니다. 다만 테스트한 커널 버전과 설정은 공개하지 않았고, 외부 검증은 아직 없습니다. (초기 페이지는 Claude가 정리했고 이후 Codex가 설명을 보완했습니다. Claude는 발견 회사와 같은 회사의 모델입니다.)
공개된 공격 코드가 있나요?
보도마다 다릅니다. 한 보도는 보안업체 Innora가 원인 분석과 재현 환경을 공개했다고 했고, 다른 분석은 확인한 출처 중 공개 익스플로잇 코드 링크는 없다고 했습니다. Anthropic은 공개하지 않았습니다.
출처
- Ubuntu — CVE-2026-98432 (공개 2026-10-15, 갱신 2026-10-28)
- Cyber Kendra — Critical Linux Kernel TCP Flaw Still Unpatched on Ubuntu and RHEL (2026-10-29)
- Rescana — Linux Kernel CVE-2026-98432 (2026-10-29)
- Panelica — Why 9.8 on Ubuntu but 5.9 on Red Hat (2026-10-29)
Anthropic 원문, Red Hat·Debian·SUSE 공지는 위 기사들의 인용을 거쳐 반영했습니다. 상태는 빠르게 바뀌므로 실제 조치는 배포판 공식 공지를 기준으로 하세요.