무슨 일이 있었나요
리눅스 커널의 IPv4 TCP 코드에서 Use-After-Free(UAF) 취약점이 공개됐어요. 번호는 CVE-2026-98432이고 CVSS 점수는 9.8이에요. CVSS가 10점 만점이니까 거의 가장 높은 등급이라고 보시면 돼요.
요즘 리눅스 커널 CVE는 정말 많이 나와요. 2024년 초에 리눅스 커널 프로젝트가 직접 CVE 번호를 발급하는 기관(CNA)이 됐고, 그 뒤로 버그 수정 커밋 상당수에 CVE 번호가 붙고 있거든요. 그래서 커널 CVE 알림이 오면 '또 나왔네' 하고 넘기는 분들도 많은데요. 이번 건은 그러면 안 돼요. 문제가 생긴 곳이 TCP 스택이고 점수가 9.8이기 때문이에요. 웹서버, DB, 쿠버네티스 노드, 공유기까지 리눅스 위에서 TCP로 통신하지 않는 시스템은 거의 없잖아요.
Use-After-Free가 뭐냐면
UAF는 이름 그대로 '이미 해제한 메모리를 다시 쓰는' 버그예요. 호텔로 비유해볼게요. 체크아웃한 손님이 카드키를 반납하지 않고 그냥 갖고 있어요. 호텔은 방을 치우고 다음 손님에게 내줬는데, 이전 손님이 그 카드키로 문을 열고 들어오면 어떻게 될까요? 지금 묵는 사람의 짐을 만지거나 바꿔놓을 수 있겠죠.
메모리에서도 똑같은 일이 생겨요. 커널이 어떤 객체(예를 들면 TCP 연결 정보를 담은 소켓 구조체)를 '이제 안 쓴다'며 해제했는데, 코드 어딘가에 그 객체를 가리키는 포인터가 아직 남아 있는 거예요. 그사이 그 메모리 자리에 다른 데이터가 들어오고, 남은 포인터로 그 자리를 읽거나 쓰면 엉뚱한 데이터를 건드리게 돼요. 공격자가 그 빈자리에 원하는 데이터를 미리 채워 넣을 수 있다면(이걸 힙 스프레이라고 불러요) 커널의 실행 흐름을 조작하는 단계까지 갈 수 있어요.
왜 TCP 스택에서 특히 위험할까요
TCP는 생각보다 복잡한 상태 기계(state machine)예요. 연결 하나가 SYN, ESTABLISHED, FIN_WAIT, TIME_WAIT 같은 여러 상태를 거치는데, 그 와중에 재전송 타이머, keepalive 타이머, 들어오는 패킷 처리, 사용자 프로세스의 close() 호출이 동시에 일어나요. 여러 CPU 코어가 같은 소켓 객체를 붙잡고 있을 수도 있고요. 그래서 커널은 참조 카운트(refcount), 락, RCU 같은 장치로 '누가 아직 이 객체를 쓰고 있는지' 관리하는데요. 이 관리가 한 군데만 어긋나도 UAF가 생기기 쉬워요.
CVSS 9.8이라는 숫자에도 많은 정보가 담겨 있어요. 이 점수는 보통 네트워크로 접근 가능(AV:N), 공격 난이도 낮음(AC:L), 인증 불필요(PR:N), 사용자 상호작용 불필요(UI:N)에 기밀성·무결성·가용성 피해가 모두 높다는 조합에서 나와요. 쉽게 말하면 '로그인 없이 원격에서 패킷만 보내도 큰 피해를 줄 수 있다'고 평가됐다는 뜻이에요. 다만 점수를 누가 매겼는지(NVD, 배포판 보안팀, 발견한 연구자)에 따라 평가가 달라지기도 하니까 쓰시는 배포판의 공지도 꼭 같이 보세요.
업계 맥락: 비슷한 사례들
네트워크 스택 취약점은 예전부터 파장이 컸어요. 2019년 넷플릭스가 공개한 SACK Panic(CVE-2019-11477)은 조작한 TCP SACK 패킷만으로 리눅스 서버를 원격에서 다운시킬 수 있었어요. 2024년 윈도우 IPv6 취약점(CVE-2024-38063)은 CVSS 9.8을 받았고 '웜처럼 퍼질 수 있다'는 경고까지 나왔죠. 같은 해 리눅스 nf_tables의 UAF(CVE-2024-1086)는 로컬 권한 상승 취약점이었는데, 실제 공격에 쓰이면서 미국 CISA의 악용 취약점 목록(KEV)에 올라갔어요.
이 사례들에서 볼 수 있듯이 가장 무서운 건 원격 + 커널 조합이에요. 애플리케이션 취약점은 그 앱만 고치면 되지만, 커널 네트워크 스택에 문제가 있으면 그 위에서 도는 서비스가 전부 영향을 받거든요. TCP 연결을 받는 포트가 하나라도 열려 있으면 공격받을 수 있는 지점이 되니까 방화벽 뒤에 있다고 안심하기도 어려워요.
한국 개발자가 지금 할 일
1. 커널 버전부터 확인하세요. uname -r로 지금 돌고 있는 커널 버전을 보고, 쓰시는 배포판의 보안 공지(Ubuntu USN, Red Hat·Rocky 보안 권고, Debian Security Tracker 등)에서 이 CVE가 어느 버전에서 고쳐졌는지 확인하세요. 영향받는 버전과 수정 커밋은 원문과 배포판 공지를 기준으로 보는 게 안전해요.
2. 컨테이너 이미지를 업데이트해도 해결되지 않아요. 의외로 많이 헷갈리는 부분인데요, 도커 컨테이너는 호스트 커널을 같이 써요. 그래서 베이스 이미지를 아무리 최신으로 바꿔도 커널 취약점은 그대로 남아요. 쿠버네티스를 쓰신다면 노드(워커 머신)의 OS 이미지를 업그레이드해야 하고, EKS·GKE·AKS 같은 관리형 서비스라면 노드 그룹 업그레이드 공지를 챙겨보세요.
3. 커널을 업데이트했으면 재부팅해야 해요. 패키지만 설치하고 재부팅하지 않으면 계속 옛날 커널로 돌아가요. 재부팅이 부담스러운 환경이라면 Canonical Livepatch나 kpatch 같은 라이브 패치(재부팅 없이 실행 중인 커널을 고치는 기술)를 쓸 수 있는지 확인해보세요.
4. 우선순위를 정하세요. 인터넷에 직접 노출된 서버(웹서버, 외부 API 서버, VPN 게이트웨이)부터 처리하고 내부망 서버는 그다음에 하는 게 현실적이에요.
마무리
한 줄 정리: 커널 TCP 스택의 원격 취약점은 모든 리눅스 서버에 해당하는 문제예요. 컨테이너 이미지가 아니라 호스트 커널을 업데이트하고 재부팅까지 끝내야 패치가 끝나요.
여러분 팀은 커널 보안 패치를 어떻게 관리하시나요? 정해진 패치 주기가 있나요, 아니면 이렇게 큰 건이 나올 때마다 대응하시나요? 라이브 패치를 실제 운영 환경에서 쓰고 계신 분들 경험도 궁금해요.
🔗 출처: Hacker News