[긴급패치] CVE-2026-98432 — Anthropic PoC, 공개 12일 만에 성공

01 메모리 해제 공지가 원격 root 실행 실증으로

처음 공지의 제목은 꽤 건조했다. IPv4 연결에 쓰는 옵션 메모리를 RCU 유예 기간이 지난 뒤 해제한다는 내용이었다. 원인이 된 변경은 Linux 4.4에 들어갔다. 커널 결함 설명

문제는 같은 메모리를 여러 작업이 함께 쓰는 상황에서 생겼다. TCP 연결을 처리하는 한쪽 작업이 아직 옵션 메모리를 읽고 있는데, 다른 쪽에서 그 메모리를 해제할 수 있었다. 이미 반납한 메모리를 다시 사용하는 Use-After-Free다. 수정은 다른 작업이 읽기를 마칠 때까지 해제를 늦추는 방식이었다.

그런데 27일 발표에는 이 오류를 이용해 명령을 실행한 결과가 담겼다. Anthropic은 MPTCP 연결을 받는 Linux 서버에 패킷을 보내, 로그인 정보나 사용자의 클릭 없이 root 권한으로 명령을 실행했다고 밝혔다. 연구팀의 시험 환경에서는 커널 주소 정보를 얻는 데 48분, 이후 명령 실행에 추가로 5분이 걸렸다. 전체 공격을 ‘5분 만에 끝났다’고 읽으면 앞의 48분이 빠진다. Anthropic의 Linux 실증

타임라인의 원문은 Linux 공지, Anthropic 발표, Go 보안팀 공지 전달본에서 확인할 수 있다. 연구 환경의 공격 실증과 실제 운영 서버의 침해 여부는 별도로 판단해야 한다.

02 Go 서비스를 쓰면 왜 한 번 더 봐야 할까

MPTCP는 하나의 연결에 여러 네트워크 경로를 활용하는 TCP 확장이다. Linux가 지원하는 기능이지만, 커널이 지원한다고 모든 서비스가 자동으로 MPTCP 연결을 받는 것은 아니다. 애플리케이션이 MPTCP 소켓을 사용해야 한다. Linux MPTCP 문서

여기서 Go의 기본값이 중요해진다. Go 1.24는 연결을 받는 리스너에서 MPTCP를 기본 사용하도록 바뀌었다. 커널이 지원하고 해당 기본 동작이 적용되는 프로그램이라면, 개발자가 MPTCP 기능을 따로 구현하지 않았어도 사용하고 있을 수 있다. 실제 동작은 빌드에 사용한 Go 버전과 go.mod의 호환성 설정, GODEBUG, 소켓별 설정을 함께 봐야 한다. Go 기본값과 호환성 설명

개발자가 기억하는 기능 목록만으로는 확인이 끝나지 않는 셈이다. 서비스 코드를 바꾸지 않았더라도 빌드 설정이 달라졌을 수 있고, 같은 서버에서 다른 팀이 운영하는 프로그램이 연결을 받고 있을 수도 있다.

공개된 Anthropic 실증에는 공격자가 접근할 수 있는 MPTCP 리스너가 필요했다. 그렇다고 MPTCP 리스너가 없는 서버를 패치 검토에서 빼도 된다는 뜻은 아니다. Go 보안팀은 근본 결함이 MPTCP에 한정되지 않으며, MPTCP 리스너가 없는 시스템에서도 유사한 공격이 가능할 수 있다고 설명했다. Go 보안팀 안내

03 해결에 앞서 우리 서버가 해당하는지 확인하기

서버 운영자는 커널과 패키지를, Go 개발자는 실행 파일과 서비스 설정을 확인하면 된다. 아래 순서는 ZIEN Lens의 영향 버전 및 배포판별 패치 가이드를 참고했다. 이 절차는 영향 범위와 공개된 공격 경로를 확인하는 과정이며, 공격 코드를 실행해 취약 여부를 판정하는 테스트는 아니다.

배포판과 실행 중인 커널부터 확인한다

서버에서 다음 두 명령으로 기본 정보를 확인한다.

cat /etc/os-release
uname -r

그다음 실제 설치된 커널 패키지 이름과 릴리스 번호를 배포판 보안 공지의 수정 패키지와 대조한다. Ubuntu라면 일반 linux인지, HWE인지, linux-gcp 같은 클라우드 커널인지도 구분해야 한다. 배포판 이름과 운영체제 버전이 같아도 확인할 패키지는 달라질 수 있다.

업스트림 수정 버전과 숫자만 비교하면 판단을 잘못할 수 있다. 배포판은 기존 커널 버전을 유지하면서 보안 수정만 반영하기도 한다. 반대로 공지에 ‘수정 작업 중’이라고 적혀 있다면, 아직 설치할 수정 패키지가 나왔다는 뜻은 아니다. 배포판별 확인 항목

MPTCP 설정과 실제 리스너를 나눠 본다

현재 네트워크 네임스페이스의 MPTCP 설정은 다음과 같이 조회할 수 있다.

sysctl net.mptcp.enabled

값이 1이면 MPTCP 소켓을 만들 수 있는 상태다. 이 값 하나로 MPTCP 서비스가 실행 중이거나 외부에 노출됐다고 판단할 수는 없다. 컨테이너처럼 네트워크 네임스페이스가 나뉜 환경에서는 서비스가 실행되는 공간의 설정도 확인해야 한다. Linux MPTCP 설정 문서

MPTCP 진단을 지원하는 커널과 iproute2 환경에서는 리스너 조회도 참고할 수 있다.

sudo ss -M -l -n -p

표시된 소켓의 주소·포트·프로세스를 서비스 목록과 맞추고, 방화벽과 포트 공개 설정을 통해 공격자가 접근할 수 있는 경로인지 확인한다. 명령이 지원되지 않거나 결과가 비어 있다면 도구 지원 범위와 네임스페이스를 먼저 확인해야 한다. 빈 출력만으로 서버 전체를 안전하다고 판정하지 않는다. ss 옵션 설명

Go 개발자는 배포된 프로그램의 설정을 확인한다

개발 PC에 설치된 Go 버전만 확인하고 끝내기 쉽다. 여기서는 실제 서버에 배포한 실행 파일을 어떤 Go 버전과 설정으로 빌드했는지가 필요하다. 빌드 기록에서 버전을 확인하고, 프로젝트의 go.mod·go.work, //go:debug 지시문, 서비스 실행 환경의 GODEBUG를 함께 살펴본다. 코드에서 net.ListenConfig.SetMultipathTCP를 직접 호출하는지도 확인한다. Go 호환성 설정, Go 소켓 API

확인 결과는 두 가지로 나눠 적어두면 된다. 하나는 커널에 수정이 적용됐는지, 다른 하나는 공개된 실증 조건인 외부 접근 가능한 MPTCP 리스너가 있는지다. 뒤쪽 조건이 확인되지 않았다고 앞쪽의 패치 확인을 생략하지 않는다.

04 해결 방안은 실행 중인 커널까지 바꾸는 것

막상 대응을 시작하면 명령어보다 먼저 막히는 곳이 있다. 우리 서버에 맞는 수정 패키지가 아직 없거나, 패키지는 나왔는데 재부팅할 시간을 잡기 어려운 경우다. 커널 공지에서 ‘수정됨’을 봤다고 운영 서버의 작업까지 끝나는 것은 아니다.

우선 공급자의 공지에서 해당 커널 패키지의 수정 제공 여부를 확인한다. 제공됐다면 그 패키지로 업데이트하고, 일반적인 커널 교체 절차에서는 새 커널로 재부팅한다. 라이브 패치를 쓰는 환경이라면 이번 CVE를 지원하는지와 실제 적용 상태를 확인해야 한다. Linux 커널 팀도 수정 사항이 포함된 커널로 업데이트할 것을 권고한다. Linux 커널 대응 권고, ZIEN Lens 적용 확인 절차

운영자가 확인 결과를 공유할 때도 ‘패키지 설치 완료’에서 한 줄 더 나가면 좋다. 어떤 커널로 부팅됐는지, 서비스가 정상적으로 응답하는지까지 적는 것이다. 재부팅 뒤 uname -r을 다시 확인하고 수정 패키지와 대조하면, 설치는 해놓고 이전 커널을 계속 쓰는 상황을 걸러낼 수 있다.

Go 개발자도 이 단계에서는 서버 운영자와 같은 결과를 확인해야 한다. Go 버전을 올리거나 애플리케이션을 다시 배포하는 작업만으로 Linux 커널의 결함이 수정되지는 않는다. 이번 CVE의 수정이 실행 중인 커널에 적용됐다면, 이 취약점 대응을 위해 Go 코드 변경이나 MPTCP 비활성화까지 반드시 추가해야 하는 것은 아니다.

05 당장 패치할 수 없다면 무엇부터 할까

패치가 아직 안 나왔다는 답을 들으면 운영자는 기다리는 동안 무엇을 해야 할지 고민하게 된다. 그 마음은 커뮤니티 반응에서도 드러났다. Reddit의 r/sysadmin에서는 MPTCP를 사용하는 프로그램이 얼마나 흔한지 묻는 글과 함께, 먼저 조치하자는 댓글이 올라왔다.

u/pdp10의 댓글을 한국어로 옮기면 이렇다.

“다들 기억하세요. 즉시 조치하고, 그 여파는 나중에 걱정합시다.”

— u/pdp10, r/sysadmin 댓글

급한 마음은 이해되지만 서비스가 어떤 연결을 받고 있는지는 확인해야 한다. 점검에서 외부 접근 가능한 MPTCP 리스너가 발견됐다면, 꼭 필요한 접근만 남기도록 네트워크 경로를 제한하거나 MPTCP 사용을 임시로 끄는 방안을 검토할 수 있다. 변경 뒤에는 신규 연결과 서비스 정상 동작을 확인한다. 이런 조치는 공개된 공격 경로의 노출을 줄이기 위한 것으로, 커널 패치를 대신하는 완료 기준은 아니다. 공격 실증 조건, Linux MPTCP 동작

Go 프로그램에는 GODEBUG=multipathtcp=0으로 MPTCP 기본 사용을 끄는 방법이 있다. 실제 서비스를 시작하는 환경에 반영하고 재시작해야 하며, 코드의 명시적인 소켓 설정이 이를 덮어쓰는지도 확인해야 한다. 터미널 한 곳에서 환경변수를 바꿨다고 이미 실행 중인 서비스까지 바뀌지는 않는다. Go 설정, 소켓별 설정

임시 조치를 했다면 수정 패키지가 나왔는지 다시 확인할 일정도 같이 잡아두는 편이 좋다. 서비스는 정상이고 당장 경고도 사라지면, 미뤄둔 커널 업데이트가 다른 일에 밀리기 쉽다. 기록에는 임시 조치와 커널 패치 완료를 따로 남겨야 다음 담당자도 상황을 알 수 있다.

06 정리

이번 공지를 처음 보면 ‘우리도 Go를 쓰나’부터 확인하고 싶어진다. 그런데 서버 목록을 펼쳐보면 개발 언어만으로 답이 나오지는 않는다. 어떤 커널이 실행 중인지, 그 패키지에 수정이 들어갔는지, 실제로 어느 프로그램이 MPTCP 연결을 받고 있는지까지 확인해야 한다.

Linux 운영자와 Go 개발자가 확인 결과를 맞춰보면 이야기는 훨씬 짧아진다. 운영자는 실행 커널과 패치 상태를, 개발자는 배포된 프로그램의 빌드 설정과 리스너를 가져오면 된다. 수정 패키지가 없다면 임시 조치와 재확인 일정을 정하고, 있다면 적용 뒤 서비스까지 살펴본다.

공격 실증에 걸린 48분과 5분은 눈길을 끈다. 운영 현장에서 오래 걸리는 쪽은 재부팅 시간을 잡고, 서비스가 잘 올라오는지 확인하고, 담당자끼리 결과를 맞추는 일일 수 있다. 그 과정까지 끝낸 뒤 ‘이 서버는 수정된 커널로 동작 중’이라고 남길 수 있다면, 그때는 이 공지를 닫아도 된다.