무슨 일이 있었나요?
Ubuntu LTS 커널에서 원격 코드 실행(RCE)이 가능한 리눅스 커널 취약점(CVE-2026-98432)이 알려진 지 3주 가까이 됐는데, 아직 패치가 나오지 않았다는 주장이 나왔어요. Canonical의 공식 보안 공지가 아니라 freenode.net에 올라온 기사예요. 취약점의 구체적인 영향 범위나 Canonical의 공식 입장은 이 글을 쓰는 시점에 따로 확인하기 어려워요. 그래서 이 글은 당황하지 말고 내 서버 상태부터 직접 확인하는 방법과 배포판 커널 패치가 늦어지는 이유를 중심으로 정리했어요. 보안 뉴스는 출처를 교차 확인하는 게 가장 중요해요.
용어부터 정리해요
RCE(Remote Code Execution)는 공격자가 네트워크 너머에서 내 서버에 원하는 코드를 실행시킬 수 있다는 뜻이에요. 보안 취약점 중에서도 가장 위험한 등급이고, 그게 커널에서 일어난다면 사실상 서버 전체를 내주는 것과 같아요.
0day(제로데이)는 원래 개발사가 알기 전에, 또는 패치가 나오기 전에 공격에 쓰이는 취약점을 말해요. 원본 리눅스 커널(업스트림)에 이미 수정이 들어갔다면 엄밀히는 N-day라고 불러야 맞아요. 하지만 내가 쓰는 배포판에 패치가 안 나왔다면 사용자에게는 0day나 다름없어요. 이번 논란도 바로 이 차이에서 생긴 거예요.
CVE는 공개된 취약점마다 붙는 고유 번호예요. 2024년부터 리눅스 커널 팀이 CVE를 직접 발급하는 기관(CNA)이 되면서 커널 CVE 수가 급격히 늘었어요. 그래서 CVE 하나하나가 실제로 얼마나 위험한지 판단하는 게 예전보다 더 중요해졌어요.
배포판 커널 패치는 왜 늦어질까?
커널에서 이미 고쳤다는데 왜 Ubuntu는 아직이냐는 의문이 들 수 있어요. 이유는 구조에 있어요.
Ubuntu LTS는 안정성을 위해 특정 버전의 커널을 고정해서 오래 써요. 예를 들어 22.04는 5.15 계열, 24.04는 6.8 계열이 기본이에요. 그래서 최신 커널의 수정 코드를 그대로 가져올 수 없고, 옛 코드베이스에 맞게 백포트(backport)해야 해요. 새 버전의 수정 사항을 옛 버전에 맞게 고쳐서 옮겨 심는 작업이에요. 게다가 Ubuntu는 generic, lowlatency, AWS·Azure·GCP용 클라우드 커널, HWE(하드웨어 지원 확장) 커널 등 커널 종류가 아주 많아요. 하나를 고치면 수십 개 빌드를 다시 만들고 테스트해야 해요.
Ubuntu 커널 업데이트는 기본적으로 정기 업데이트 주기(SRU, Stable Release Update)에 맞춰 나가요. 아주 급하면 주기와 상관없이 따로 내보내기도 하지만, 급하다는 판단이 늦어지면 몇 주씩 공백이 생길 수 있어요. 이번 비판도 바로 이 긴급도 판단을 겨냥한 거예요.
다른 배포판은 어떨까?
배포판마다 전략이 달라요. Debian은 보안팀이 DSA(Debian Security Advisory)로 따로 대응하고, RHEL은 kpatch로 재부팅 없이 패치를 적용하는 라이브 패칭을 제공해요. Ubuntu에도 Canonical Livepatch가 있고, Ubuntu Pro 구독으로 쓸 수 있어요(개인은 일정 대수까지 무료). 다만 라이브 패치도 Canonical이 패치를 만들어야 나오기 때문에, 패치 준비 시간 문제 자체를 해결해 주지는 못해요. Fedora나 Arch처럼 최신 커널을 빠르게 따라가는 배포판은 업스트림 수정이 빨리 들어오는 대신, 새 커널 때문에 생기는 다른 문제를 감수해야 해요.
지금 바로 해볼 수 있는 점검
내 서버가 영향을 받는지는 직접 확인하는 게 가장 확실해요.
uname -r로 지금 돌고 있는 커널 버전 확인pro fix CVE-2026-98432로 해당 CVE의 상태와 해결 방법 확인pro security-status로 보안 업데이트 현황 한눈에 보기- Livepatch를 쓴다면
canonical-livepatch status로 적용 여부 확인 /var/run/reboot-required파일이 있는지 확인하기. 커널 패치는 받아 놓고 재부팅을 안 해서 옛 커널로 돌고 있는 서버가 생각보다 많아요
공식 패치가 아직 없다면 임시 대응도 필요해요. 공식 공지에서 영향받는 커널 모듈이나 기능이 특정되면, 그 모듈을 비활성화(blacklist)하는 게 흔한 방법이에요. 외부에 열린 포트와 서비스를 최소화하고 방화벽과 보안 그룹 규칙을 다시 점검하는 것도 기본이에요. 컨테이너 환경이라면 컨테이너가 호스트 커널을 공유한다는 점을 잊지 마세요. 이미지를 아무리 최신으로 빌드해도 호스트 커널이 취약하면 소용없어요.
한국 개발자에게 주는 시사점
국내 클라우드와 사내 서버에서 Ubuntu LTS는 정말 많이 쓰여요. 이번 일의 교훈은 Ubuntu가 나쁘다는 게 아니라 배포판이 알아서 챙겨 주겠지 하는 믿음에도 빈틈이 있다는 거예요. 운영하는 서버가 있다면 Ubuntu 보안 공지(USN)를 메일이나 RSS로 구독하고, 커널 업데이트 후 재부팅까지 챙기는 루틴을 만들어 두세요. 서버가 많다면 커널 버전과 재부팅 필요 여부를 모니터링 지표로 수집해 두는 것도 좋아요.
마무리
한 줄 정리: 업스트림에서 고쳐졌다고 내 서버가 안전한 건 아니에요. 배포판의 패치 상태는 공식 트래커에서 직접 확인하세요.
여러분 팀은 커널 보안 업데이트를 어떤 주기로, 어떻게 적용하고 있나요? 라이브 패치를 실제로 써 본 분들의 후기도 궁금해요!
🔗 출처: Hacker News