CVE-2026-98276은 업스트림에서 수정되었습니다. 그런데 서버가 12번이나 다운되었습니다.

주요 내용

• CVE-2026-98276은 권한이 없는 로컬 사용자가 두 개의 소켓 호출을 동시에 실행함으로써 커널을 다운시키거나 루트 권한을 획득할 수 있게 합니다.
• 서버를 12번이나 다운시켰던 이 익스플로잇이 이제 EL 8, 9, 10에서 루트 권한을 획득합니다.
• 레드햇은 RHEL 7, 8, 9 또는 10에 대해 고정된 커널을 제공하지 않으며, 이에 대한 대응 조치도 제시하지 않고 있습니다.
• RHEL, AlmaLinux, CloudLinux 8 및 9, 그리고 Debian 12 및 13용 KernelCare 재부팅 없이 적용 가능한 패치가 출시되었습니다.

요약

전체 버전으로 이동 ↓

무슨 일이 있었는지: 2026년 10월 6일, 커널 CVE 팀은 CVE-2026-98276 공개됨, UDP 소켓에서 다음 요소 간의 경합으로 인해 발생한 ‘use-after-free’ 오류 bind() 그리고 sock_gettstamp(), 소켓의 마지막 패킷이 도착했을 때 프로그램에 이를 알리는 핸들러입니다. UDP 소켓을 열 수 있는 로컬 사용자라면 누구나 이를 트리거할 수 있지만, 네트워크를 통해서는 접근할 수 없습니다. 11월 4일, CloudLinux 8 서버를 대상으로 작동하는 익스플로잇이 사용되었으며, 12번이나 부숴버렸다. 이 섹션으로 이동 → (실제 서버에서 공격이 어떻게 나타났는지) . TuxCare는 이후 해당 서버에서 복구한 코드를 바탕으로 작동하는 루트 익스플로잇을 개발했다.

영향을 받는 대상: 해당 수정 사항을 적용하지 않은 모든 커널로, 이는 여전히 많은 운영 환경 시스템에 해당합니다. 여기에는 RHEL 7, 8, 9, 10과 Red Hat 커널을 사용하는 리빌드 버전(CloudLinux 8, 9, 10 포함)이 포함됩니다. 공유 호스팅은 특히 취약한 부분인데, 이는 해당 환경의 고객 계정이 모두가 공유하는 커널에서 자체 코드를 실행하는 경우가 많기 때문입니다. 이 섹션으로 이동 →

현재 상황:이는 제로데이 취약점이 아닙니다. 공격 사례가 보고되기 전부터 수정 패치가 업스트림 및 업스트림 안정화 브랜치에 이미 반영되어 있었으며, 공개된 익스플로잇 코드도 없습니다. TuxCare는 최신 AlmaLinux 8 커널을 포함해 EL 8, 9, 10에서 권한 상승이 가능함을 확인했으므로, 해당 환경에서는 로컬 루트 권한 침해로 간주하시기 바랍니다. EL 7의 경우, TuxCare의 평가에 따르면 시스템 충돌만 발생합니다. Debian은 커널을 수정했으며, Ubuntu, Oracle 및 Amazon은 일부를 수정했으나, Red Hat은 어떤 EL 버전에 대해서도 수정 사항을 배포하지 않았으며, 배포 일정도 밝히지 않았습니다. KernelCare의 재부팅이 필요 없는 패치는 RHEL, AlmaLinux 및 CloudLinux 8과 9에서 운영 중이며, EL 10은 테스트 피드에 포함되어 있습니다. 이 섹션으로 이동 →

오늘 해야 할 일: 설정할 sysctl 옵션도 없고 도움이 될 만한 방화벽 규칙도 없으므로, 패치를 적용하는 것이 유일한 해결책입니다. RHEL, AlmaLinux, CloudLinux 8 및 9, 그리고 Debian 12 및 13을 사용하는 KernelCare 사용자는 지금 바로 패치를 적용할 수 있습니다:

kcarectl --update

그런 다음 다음을 사용하여 확인해 보세요. kcarectl --patch-info | grep 'CVE-2026-98276'. EL 10(CloudLinux 10 포함)의 경우, 해당 패치는 현재 테스트 피드에 올라와 있으므로 업데이트 명령어에 –prefix test 옵션을 추가하십시오. 패치가 적용될 때까지는 신뢰할 수 없는 로컬 계정의 권한을 제한하거나 일시 정지하십시오. 이 섹션으로 이동 →

로컬 서비스 거부(DoS) 취약점은 대개 우선순위 목록의 맨 아래에 위치합니다. 공격자는 해당 시스템에 대한 접근 권한을 확보해야 하며, 일반적인 결과는 시스템 충돌과 재부팅에 그치고, 대부분의 조직은 해결해야 할 더 시급한 문제가 많기 때문입니다. CVE-2026-98276도 처음에는 그런 취약점 중 하나로 보였으나, 오래가지 않아 상황이 달라졌습니다.

이미 누군가가 그것을 사용했습니다. 11월 4일, CloudLinux 8 서버가 12번 다운되었습니다 이 버그에 대한 작동하는 익스플로잇을 바탕으로, 그리고 kernel.panic_on_oops = 1 설정이 완료된 후, 시스템이 다운될 때마다 완전한 재부팅이 필요했습니다. 이틀 뒤, TuxCare는 해당 서버에서 복구한 코드를 바탕으로 제작한 익스플로잇을 통해 AlmaLinux 8에서 루트 권한을 획득했으며, 현재 EL 8, 9, 10에서도 권한 상승이 확인되었습니다. 게다가 이를 차단할 수 있는 방법은 전혀 없습니다. 취약한 코드는 모든 프로세스가 자신이 연 UDP 소켓에서 호출할 수 있는 타임스탬프 ioctl 뒤에 숨어 있습니다.

벤더 커널도 뒤처지고 있습니다. 10월 6일 CVE가 공개되기 전에 이미 업스트림에 수정 패치가 반영되었고, 데비안은 몇 주 전에 수정된 커널을 배포했지만, 레드햇은 여전히 RHEL 7부터 10까지를 취약한 버전으로 분류하고 있으며, 수정된 커널도 없고 출시 일정도 밝히지 않고 있습니다.

타임스탬프 쿼리가 활성 소켓을 해제하는 방법

SIOCGSTAMP 그리고 SIOCGSTAMPNS, 그리고 _NEW 64비트 시간 처리를 위해 최신 커널에서 사용하는 기능들은 오래되고 별 볼 일 없는 ioctl 명령들입니다. 프로그램이 소켓에 대해 이 명령을 호출하여 마지막 패킷이 언제 도착했는지 묻고, 커널은 이를 통해 응답합니다. sock_gettstamp() 에서 net/core/sock.c. 소켓에 대한 요청이 처음 들어올 때, 핸들러는 또한 SOCK_TIMESTAMP ~에 물었다 sk->sk_flags.

문제는, 소켓 잠금 장치를 고정하지 않은 채로 이 작업을 수행한다는 점이며, 아래에 있는 보조 장치는 __set_bit(), 이는 원자적 작업이 아닙니다. CPU는 플래그 워드 전체를 읽은 다음, 한 비트를 OR 연산으로 결합하고 워드 전체를 다시 기록합니다. 읽기와 쓰기 사이에 다른 프로세스가 해당 워드의 다른 비트를 변경하면, 그 변경 사항은 사라집니다.

그 다른 작가는 bind(). UDP 소켓을 바인딩하는 동안, udp_lib_get_port() 세트 SOCK_RCU_FREE 그리고 소켓을 해시 테이블에 추가하면, UDP 수신 경로는 잠금을 걸지 않고도 해당 소켓을 찾을 수 있습니다. SOCK_RCU_FREE 이는 커널이 잠금 없이 읽는 사용자들에게 하는 약속입니다. 소켓이 닫힐 때, 커널은 RCU 유예 기간이 지나기를 기다린 후 소켓을 해제하므로, 여전히 해당 소켓을 참조 중인 사용자가 작업을 마칠 수 있습니다.

이 두 가지를 서로 다른 CPU에서 실행하면 타이밍이 제대로 맞지 않을 수 있습니다. ioctl은 바로 직전에 플래그를 읽습니다. bind() 세트 SOCK_RCU_FREE, 그런 다음 소켓이 이미 테이블에 등록된 후에 오래된 사본을 다시 기록합니다. 플래그는 사라졌지만, 락이 없는 읽기 작업에서는 소켓이 여전히 표시되며, 커널 내에서는 그 약속이 깨졌다는 사실을 전혀 알지 못합니다. 패킷이 수신 중인 상태에서 소켓을 닫으면, 커널은 수신 경로가 여전히 해당 메모리를 사용하고 있는 동안에도 즉시 메모리를 해제해 버립니다. 이것이 바로 ‘use-after-free’입니다.

그리고 수정 에릭 뒤마제(Eric Dumazet)의 작품은 소켓 잠금 장치를 적용하고 있다 sock_gettstamp(), 하지만 오직 ~일 때만 SOCK_TIMESTAMP 실제로 설정이 필요하므로, 공통 경로는 잠금 상태가 유지되지 않습니다. 이 CVE 기록 이 보고서는 이정우와 이원기가 작성한 것으로 밝히고 있으며, KASAN은 이 보고서에 인용된 내용이 기자들이 명명한 테스트 프로그램에서 나온 것이라고 밝혔다. exploit.

같은 커밋 메시지에서는 다음과 같이 지적하고 있습니다. sk_set_memalloc() 그리고 sk_clear_memalloc() 또한 변경 sk_flags 잠금 기능이 없는 경우입니다. 해당 호출자(nbd, iSCSI, NVMe over TCP, sunrpc 및 WireGuard)는 먼저 감사가 필요하므로, 업스트림에서는 별도의 패치를 계획 중입니다. 이는 추후 별도로 처리될 수정 사항이며, 이번 CVE의 일부는 아닙니다.

이 수정 사항이 적용되지 않은 커널에는 여전히 해당 문제가 남아 있으며, 실제 운영 중인 수많은 엔터프라이즈용 커널에서도 아직 이 수정 사항을 반영하지 않았습니다.

공격을 받은 서버는 CloudLinux 8 커널을 실행하고 있었으며, 시스템이 다운될 때마다 커널 로그에 동일한 흔적이 남았습니다. 먼저 다음 파일의 153행과 156행에서 경고 메시지가 나타났는데, net/ipv4/af_inet.c, 내부 inet_sock_destruct(), 소켓을 닫는 코드입니다. 그 다음에는 NULL 포인터 참조 오류가 발생했는데, 이는 udp_destruct_common() 소켓이 닫히거나 __sk_mem_raise_allocated() 호출된 곳: __udp_enqueue_schedule_skb() 패킷이 대기열에 추가되는 과정에서 발생했습니다. 이 두 가지 현상은 클로즈 경로와 수신 경로가 이미 사라진 소켓을 놓고 경쟁할 때 예상되는 현상입니다.

서버에는 kernel.panic_on_oops = 1, 많은 호스팅 환경에서 이 방식을 채택하고 있어, 문제가 있는 커널이 간신히 버티는 대신 재부팅되도록 합니다. 그 결과 모든 ‘oops’ 오류가 재부팅으로 이어졌으며, 총 12번 발생했습니다. 해당 서버에서는 루트 권한이 노출된 적이 없었고, 오류만 발생했을 뿐이며, 공개된 익스플로잇 코드도 발견되지 않았습니다.

서버가 뚜렷한 이유 없이 재부팅되고 있다면, 이전 부팅 시의 커널 로그에서 해당 함수 이름들을 확인해 보십시오. 이를 위해서는 영구 저널이 필요합니다:

journalctl -k -b -1 | grep -E 'inet_sock_destruct|udp_destruct_common|__sk_mem_raise_allocated|__udp_enqueue_schedule_skb'

일치 결과가 그 자체로 공격의 증거는 아니지만, 패치가 적용되지 않은 커널의 경우, 누가 로그인해 있었는지, 그리고 어떤 프로그램을 실행 중이었는지 확인해 볼 만한 충분한 이유가 됩니다.

‘크래시 버그’에서 ‘루트 버그’로

커널 CVE 팀은 CVE-2026-98276에 대해 7.8점의 ‘높음(High)’ 등급을 부여했으며, 이 취약점은 로컬 공격 경로를 가지며, 공격 난이도는 낮고, 권한 수준은 낮으나 기밀성, 무결성 및 가용성에 미치는 영향은 높은 것으로 평가했습니다. 레드햇(Red Hat)은 이 취약점을 7.0점으로 ‘중간(Moderate)’ 등급으로 평가했으며, 수세(SUSE) 와 아마존(Amazon) 역시 7.0점을 부여했습니다. 평가 점수 차이의 전부는 공격 복잡성에 기인하는데, 해당 벤더들은 공격자가 ‘레이스 조건(race condition)’을 성공적으로 유발해야 하기 때문에 이 부분을 높게 평가했습니다. 이론적으로는 타당한 지적이지만, CloudLinux 8 사고 사례는 실제 운영 서버에서도 이 레이스 조건을 반복적으로 성공적으로 유발할 수 있음을 보여줍니다.

점수와 실제 증거 사이에는 더 큰 격차가 있었지만, 그 격차는 이제 좁혀졌습니다. 7.8 점수는 이와 같은 소켓 ‘use-after-free’ 취약점이 권한 상승으로 이어질 수 있다고 가정하고 있으며, TuxCare가 이제 이를 입증해 냈습니다. TuxCare 팀은 공격받은 서버에서 복구한 코드를 바탕으로 제작한 익스플로잇을 사용하여 기본 커널이 탑재된 AlmaLinux 8에서 루트 권한을 획득했으며, 이후 EL 8, 9, 10에서도 권한 상승이 가능함을 확인했습니다. 여기에는 최신 AlmaLinux 8 커널인 4.18.0-553.184.1.el8_10도 포함됩니다. 이 익스플로잇은 완벽하게 신뢰할 수 있는 것은 아니지만, 여러 차례 성공적으로 작동했습니다. EL 7의 경우, TuxCare의 평가에 따르면 로컬 크래시만 발생합니다. EL 계열의 다른 모든 버전에서는 이를 로컬 루트 권한 획득으로 간주하고, 7.0의 벤더 점수가 시사하는 것보다 더 높은 우선순위를 부여해야 합니다.

CloudLinux 9와 10은 AlmaLinux 커널을 사용하므로 AlmaLinux 항목에 따라 처리됩니다. Ubuntu의 경우 상태는 커널 버전에 따라 달라지므로, 릴리스 번호보다는 실제로 실행 중인 패키지를 확인하시기 바랍니다. 직접 커널을 빌드하는 경우, 위에 언급된 안정화 릴리스 중 어느 것이든 해당 수정 사항이 포함되어 있습니다.

TuxCare의 ‘Endless Lifecycle Support (ELS)’가 지원하는 구버전들은 여러분이 생각하는 것보다 훨씬 양호한 상태입니다. 이 수정 사항이 적용된 ELS 커널은 10월 14일부터 26일 사이에 CentOS 6, Oracle Linux 6, CentOS 8.5 및 Ubuntu 20.04용으로 배포되었으며, AlmaLinux 9.2 및 9.6용 확장 지원 커널도 함께 제공되었습니다.

대부분의 커널 버그에는 패치가 적용되기 전까지 조정할 수 있는 설정 항목, 언로드해야 할 모듈, 또는 변경해야 할 sysctl 등이 있습니다. 하지만 이 버그에는 그런 것이 전혀 없습니다. sock_gettstamp() 이는 커널 소켓 코드이며, sysctl이나 부팅 옵션을 통해 비활성화할 수 없습니다. UDP 소켓을 생성할 수 있는 일반 사용자라면 누구나 이 소켓에 접근할 수 있으며, 기본 설치 환경에서는 모든 사용자가 이에 해당합니다.

방화벽으로는 소용이 없습니다. 공격의 발단은 공격자가 제어하는 소켓에 대한 몇 가지 시스템 호출인데, 이 중 어느 것도 iptables나 nftables를 통과하지 않기 때문입니다.

SELinux 정책으로 인해 타임스탬프 ioctl이 차단될 수 있습니다. 하지만 CloudLinux에서는 cPanel 및 WHM을 사용하려면 SELinux를 비활성화해야 하므로, 많은 호스팅 서버에서는 이 방법을 고려할 수 없습니다.

이제 남은 것은 호스트에서 코드를 실행할 수 있는 사용자를 제한하는 것입니다. 공유 호스팅의 경우, 여기에는 셸 액세스, 크론 작업, 그리고 자체 바이너리를 실행할 수 있는 모든 고객 애플리케이션이 포함됩니다. 패치가 적용될 때까지 신뢰할 수 없는 계정을 제한하거나 일시 정지하고, 원인을 알 수 없는 재부팅이 발생하는지 주의 깊게 관찰하십시오. 이때, 재부팅은 실패한 시도만 보여줄 수도 있다는 점을 염두에 두어야 합니다. 그런 다음 패치를 적용하십시오.

KernelCare의 재부팅 없이 적용 가능한 패치는 업스트림의 수정 사항을 있는 그대로 포팅하며, 플래그 업데이트 시 소켓 잠금을 적용합니다. 데이터 구조의 변경이 없는 사소한 변경 사항이므로 재부팅 없이 적용 가능한 패치로 적합하며, Red Hat이 아직 어떤 EL 버전에 대해서도 수정된 커널을 제공하지 않는 동안 EL 제품군 전반에 배포되고 있습니다. 이는 커널 버그이므로 LibCare는 관련이 없습니다.

EL 7은 예외입니다. TuxCare의 평가에 따르면, 이 문제는 권한 상승 없이 로컬에서 발생하는 크래시이므로 Red Hat보다 먼저 패치를 적용할 계획은 없습니다. 패치가 운영 환경에 배포된 모든 곳에서는, KernelCare 자동 업데이트를 사용하는 호스트가 정상적인 일정에 따라 패치를 적용받거나, kcarectl –update 명령을 사용하여 즉시 패치를 적용할 수 있습니다. EL 10(CloudLinux 10 포함)의 경우, 현재 테스트 피드에 포함되어 있으므로 kcarectl –update –prefix test 명령을 사용하십시오. 어느 경우든 재부팅은 필요하지 않습니다. 그런 다음 패치가 실제로 적용되었는지 확인하십시오:

kcarectl --patch-info | grep 'CVE-2026-98276'

만약 아무것도 출력되지 않는다면, KernelCare가 해당 CVE에 대한 패치를 적용하지 않은 것이므로, 시스템이 취약한 상태라고 단정하기 전에 해당 호스트가 이미 수정된 벤더 커널을 실행 중인지 확인하십시오. TuxCare CVE 트래커에서는 배포판별 재부팅 없이 적용 가능한 패치 현황을 실시간으로 확인할 수 있습니다.

지금 바로 KernelCare를 다운로드하세요 →

잠금 작업 몇 줄과 긴 기다림

업스트림 수정 사항은 몇 줄에 불과하지만, RHEL 사용자들은 여전히 설치할 수 있는 벤더 커널이 없습니다.

일반적인 기준으로는 아무도 이 문제를 눈치채지 못했을 것입니다. 패치는 CVE가 공개되기 전에 적용되었고, CVE는 실제 공격이 발생하기 한 달 전에 공개되었으며, 익스플로잇 코드도 공개된 바가 없습니다. 이론적으로 볼 때, 벤더 심각도 점수가 7.0인 로컬 크래시 버그는 우선순위가 높지 않습니다.

그러던 중, 많은 호스팅 서버에서 실행 중인 RHEL 계열 커널에 대해 공급업체 측의 수정 패치가 아직 제공되지 않은 상황에서, 실제 작동하는 익스플로잇이 프로덕션 호스팅 서버에 등장했습니다. 이틀도 채 지나지 않아, 그 익스플로잇 코드는 루트 권한을 획득하는 익스플로잇으로 변모했습니다. 공유 호스팅은 로컬 버그가 발생할 경우 최악의 시나리오에 가깝습니다. 수많은 고객이 로컬 계정에서 자체 코드를 실행할 수 있으며, 그중 단 한 명만으로도 호스팅 서버를 마비시키거나 장악하여 해당 서버에 접속한 다른 모든 사용자에게 피해를 줄 수 있습니다.

따라서 멀티테넌트 서버를 운영 중이라면, 이 문제를 ‘로컬 DoS’로 분류하지 마십시오. EL 8부터 10까지의 버전에서는 로컬 루트 권한이 침해됩니다. 로그에서 시스템 중단 징후를 확인하고, 신뢰할 수 없는 계정의 권한을 강화하며, 가능한 경우 재부팅 없이 적용할 수 있는 패치를 설치하거나, 배포판에 수정된 커널이 제공되는 경우 재부팅하여 해당 커널로 전환함으로써 문제를 해결하십시오.

지금 바로 KernelCare를 다운로드하세요 →

사건의 전말

출처

이 게시물의 주요 출처는 커널 CVE 공지, CVE 기록 및 업스트림 수정 사항과 더불어 Red Hat ( 버그 추적 시스템 포함), Debian, Ubuntu, SUSE, Amazon, Oracle의 공급업체 페이지입니다. 또한 CloudLinux의 사고 보고서, NVD 항목, OSV 기록, 그리고 2026년 11월 9일 기준 TuxCare의 KernelCare 및 ELS 릴리스 기록도 인용되었습니다.