우분투가 CVE-2026-98432라는 치명적 등급(CVSS 9.8) 취약점에 대한 수정 커널을 아직까지 배포하지 못하면서, 22.04·24.04·26.04 LTS를 운영하는 조직들이 공식 업데이트 없이 노출된 상태로 남아 있다. 보고에 따르면 패치 공백은 거의 3주째 이어지고 있고, 벤더가 수정 시점(ETA)조차 공지하지 않았다. CVSS 9.8은 10점 만점 체계에서 사실상 최상위에 해당하는 점수로, 공격 난도가 낮으면서 원격에서 시스템을 완전히 장악할 수 있는 수준의 결함에 매겨진다.
우분투 LTS는 많은 기업과 클라우드 환경에서 장기 지원과 안정성을 이유로 표준 배포판으로 채택돼 있다. 세 개의 LTS 라인이 동시에 영향을 받는다는 점은, 단일 서비스가 아니라 상당 비중의 프로덕션 서버군이 한꺼번에 사각지대에 놓였음을 뜻한다. 그만큼 벤더 패치 하나의 지연이 개별 조직 차원을 넘어 생태계 전반의 노출 시간으로 번지는 구조다.
왜 커널 공백이 특히 위험한가
커널은 사용자 간, 테넌트 간, 그리고 권한 경계를 강제하는 최종 방어선이다. 애플리케이션 계층의 결함은 격리나 권한 분리로 피해를 가둘 여지가 있지만, 커널 수준의 원격 코드 실행은 그 격리 자체를 무력화한다. 특히 인터넷에 직접 노출된 호스트나, 여러 고객·조직의 워크로드가 같은 물리/가상 머신 위에서 커널 격리에 의존해 돌아가는 멀티테넌트 자체 호스팅 환경에서 위험이 가장 크다. 공식 커널 패키지가 나오기 전까지 이런 호스트는 해당 CVE가 허용하는 원격 혹은 로컬 공격에 그대로 노출된다.
벤더 업데이트가 비어 있는 상황에서 운영자가 택할 수 있는 길은 많지 않다. 원문이 제시하는 선택지는 세 가지다. 위험을 감수하고 기존 스톡 커널을 그대로 유지하거나, 존재한다면 트리 외부(out-of-tree) 완화책을 적용하거나, 이미 패치가 반영된 다른 릴리스나 커널로 워크로드를 옮기는 것이다. 어느 쪽도 간단하지 않다. 커널 교체는 드라이버 호환성과 재부팅 창(window) 확보라는 운영 부담을 동반하고, 완화책은 제대로 검증되지 않으면 오히려 새로운 장애 요인이 될 수 있다.
실무자가 지금 점검할 것
패치를 기다리는 동안에도 노출면을 줄이는 작업은 가능하다. 우선 해당 LTS 커널을 쓰는 자산을 식별하고, 그중 인터넷에 직접 노출되거나 신뢰 경계를 공유하는 멀티테넌트 호스트를 우선순위 상단에 두는 것이 합리적이다. 공격 경로가 네트워크를 경유한다면 방화벽·세그먼테이션으로 접근 가능한 서비스 범위를 좁히고, 불필요한 외부 노출을 차단해 공격 표면을 최소화하는 방향이 현실적인 차선이다. 또한 우분투 보안 공지 채널을 지속 모니터링해 패치가 올라오는 즉시 적용할 수 있도록 롤아웃 절차와 재부팅 계획을 미리 준비해 두는 편이 좋다.
다만 이 사안을 평가할 때 분명히 짚어둘 한계가 있다. 공개된 정보만으로는 취약점의 구체적 성격을 가늠하기 어렵다는 점이다. 원문은 등급(CVSS 9.8)과 영향 범위(22.04·24.04·26.04), 그리고 패치 부재라는 사실을 전할 뿐, 결함이 커널의 어느 서브시스템에 있는지, 실제 악용에 어떤 전제 조건이 필요한지, 원격 비인증 공격이 성립하는지 로컬 접근이 선행돼야 하는지 등 공격 벡터의 세부는 밝히지 않는다. 또한 실제 익스플로잇이 관측됐는지, 패치가 지연되는 배경이 무엇인지에 대한 설명도 없다.
따라서 현 시점의 결론은 과장도 축소도 없이 단순하다. 최상위 등급의 커널 결함이 핵심 LTS 라인 전반에 걸쳐 있고 공식 수정은 아직 없다는 사실 자체가 위험 신호이며, 각 조직은 자신의 노출 구조에 맞춰 보수적으로 대응 우선순위를 잡는 것이 안전하다. 세부 정보가 제한적인 만큼, 추가 공지가 나오기 전까지는 최악의 시나리오를 가정한 임시 조치를 전제로 삼는 편이 합리적인 판단이다.