요약
내용: 2026년 9월 18일, CISA는 ‘알려진 악용 사례 취약점(Known Exploited Vulnerabilities)’ 목록에 리눅스 커널 취약점 3건을 추가했습니다. CVE-2025-39682는 커널 TLS 수신 경로에, CVE-2026-53266은 네트워크 브리지에 사용되는 ebtables SNAT 대상에, CVE-2025-39964는 AF_ALG 암호화 소켓의 경합 조건에 각각 위치합니다. 서로 관련 없는 세 가지 하위 시스템, 세 가지 서로 다른 노출 테스트. 이 섹션으로 이동 →
영향: 헤드라인에서 암시하는 것보다 훨씬 더 다양합니다. kTLS 버그로 인해 이후 레코드가 잘못된 제로 카피 및 큐잉 가정 하에서 처리될 수 있습니다. ebtables 버그는 커널의 쓰기 작업이 본래 수정할 의도가 전혀 없었던 파일 기반 페이지에 기록되도록 할 수 있으며, 레드햇은 이를 메모리 손상, 서비스 거부(DoS), 또는 권한 상승으로 이어질 수 있는 경로로 설명합니다. AF_ALG 경합 현상은 그 자체만으로도 로컬 크래시나 암호화된 출력 데이터를 손상시키지만, 현재 공개된 익스플로잇 코드는 이를 연쇄적으로 활용하여 대상 커널에서 루트 셸을 확보합니다. 이 섹션으로 이동 →
중대성: 헤드라인에서 다루는 것보다 더 미묘한 차이가 있습니다. 레드햇(Red Hat)은 이 취약점들에 각각 7.0, 7.5, 7.3을 부여하고, 이를 차례로 ‘중간(Moderate)’, ‘중요(Important)’, ‘중간(Moderate)’으로 분류합니다. 이는 레드햇의 중대성 등급 체계가 단순한 수치 이상의 요소를 반영하기 때문입니다. NVD와 리눅스 CNA는 이들 중 일부에 대해 서로 다른 공격 경로를 적용하고 있으며, 이것이 9.8, 8.8, 7.8과 같은 더 높은 수치가 나온 이유입니다. 이 섹션으로 이동 →
영향을 받는 대상: RHEL 및 AlmaLinux, Rocky Linux, Oracle Linux, CloudLinux를 포함한 RHEL 리빌드 버전이며, 영향 범위는 CVE마다 다릅니다. CVE-2025-39682의 경우, Red Hat은 EL9와 EL10만 영향을 받는 것으로 표시하고 있습니다. 나머지 두 CVE는 영향 범위가 더 넓으며, CVE-2026-53266의 경우 확장 지원 대상에 RHEL 6까지 포함되어 있습니다. 또한 각 버그에는 실제 노출 위험을 줄여주는 전제 조건이 있습니다. 이 섹션으로 이동 →
상태: 제로데이 취약점이 아닙니다. 모든 업스트림 수정 사항은 이 목록이 작성되기 이전에 이루어졌으며, kTLS 및 AF_ALG 수정 사항은 목록 작성 시점보다 1년 이상 앞서 적용되었습니다. 레드햇의 기록에 따르면 현재 이 세 가지 취약점은 알려진 익스플로잇으로 분류되어 있지만, CISA나 레드햇 모두 KEV와 연계된 상태 정보를 넘어서는 공격 체인, 표적 또는 텔레메트리 데이터를 공개하지 않았으며, 랜섬웨어 활용 여부는 ‘알 수 없음’으로 기재되어 있습니다. 또한 세 가지 중 두 가지에 대한 공개 익스플로잇 코드도 현재 존재합니다. 이 섹션으로 이동 →
지금 바로 다음을 수행하세요: 특정 벤더의 커널을 설치하고 재부팅하여 해당 커널로 전환하거나, 실행 중인 커널에 적용 가능한 라이브 패치가 있는 경우 KernelCare를 통해 재부팅 없이 패치를 적용하세요. 또한 af_alg 모듈 블랙리스트 설정은 건너뛰세요. 여기서 확인한 Enterprise Linux 커널에는 AF_ALG가 내장되어 있으므로, 블랙리스트 설정은 아무런 효과가 없습니다. 이 섹션으로 이동 →
어떤 af_alg 해결 방법도 신뢰하기 전에, 실행 중인 커널에 AF_ALG가 어떻게 통합되어 있는지 확인하십시오:
grep -E 'CONFIG_CRYPTO_USER_API' /boot/config-(uname-r)2>/dev/null||grep-E'CONFIGCRYPTOUSERAPI'/lib/modules/(uname -r)/config
만약 CONFIG_CRYPTO_USER_API=y 출력에 나타나며, AF_ALG는 컴파일되어 포함되어 있고 어떤 모듈 블랙리스트도 이를 비활성화할 수 없습니다.
재부팅 없이 KEV Kernel Trio 종료하기
실행 중인 커널에 대한 KernelCare 패치가 있는 경우, 재부팅이나 워크로드 재시작 없이 수정 사항이 적용됩니다.
2026년 10월 2일 기준 KernelCare 현황: CVE-2025-39682는 2025년 10월부터 나열된 EL9 및 EL10 스트림에서 해결되었습니다. CVE-2026-53266은 2026년 7월부터 EL8 및 EL9에서 지원되고 있으며, RHEL 10 및 AlmaLinux 10은 9월 30일에 출시되었으나 아직 안정판 피드에는 포함되지 않았습니다. KernelCare는 또한 9월 30일에 RHEL 8, CloudLinux 8, AlmaLinux 9, RHEL 10 및 AlmaLinux 10용 CVE-2025-39964 릴리스를 공개했으나, 이들 역시 아직 안정판 피드에 포함되지 않았으므로 정확한 커널에 대한 피드 제공 여부를 확인하시기 바랍니다. EL7, Amazon Linux 2, Debian, Ubuntu 및 기타 배포판은 아직 검토 중이거나 출시를 기다리고 있습니다. 해당 커널을 사용하기 전에 실행 중인 정확한 커널에 대한 지원 여부를 확인하십시오.
자세한 내용
같은 날 KEV에 등록된 세 건의 커널 CVE는 마치 하나의 사건처럼 보일 수 있습니다. 하지만 실제로는 세 건의 별개 사건으로, 공통된 버그 유형도 없고, 공통된 하위 시스템도 없으며, 호스트가 취약한지 여부를 알려주는 단일 테스트도 없습니다.
이들이 공통적으로 다룬 부분은 시기와 이를 둘러싼 논란이었습니다. 이 목록은 BOD 26-04에 따라 연방 민간 기관에 3일간의 시정 기한을 부여했으며, 이후 보도에서는 심각도 점수 9.8을 인용하고 레드햇이 세 가지 취약점 모두에 대해 활발한 악용이 진행 중임을 독립적으로 확인했다고 주장했습니다. 레드햇의 기록에는 해당 CVE들이 알려진 악용 사례로 표시되어 있지만, 이 상태는 레드햇이 공개한 텔레메트리 데이터보다는 KEV 등재와 관련이 있으며, 9.8이라는 수치는 레드햇이 RHEL에 적용하는 것과는 다른 평가 기준에서 나온 것이므로 맥락을 고려해야 합니다.
버그 중 새로운 것은 하나도 없습니다. kTLS 수정 사항은 2025년 8월 19일에 업스트림에 반영되었고, AF_ALG 수정 사항은 2025년 9월 16일에, ebtables 수정 사항은 2026년 5월 23일에 반영되었습니다. 따라서 이는 ‘n-day 패치’ 문제이며, 각 호스트에 대해 중요한 질문은 해당 수정 사항이 실제로 실행 중인 커널에 반영되었는지 여부입니다.
KEV 상장 정보가 알려주는 것과 알려주지 않는 것
CISA는 9월 18일 이 세 가지 CVE를 모두 KEV 카탈로그에 추가하고, 연방 민간 기관을 대상으로 BOD 26-04에 따른 시정 조치 기한을 9월 21일로 정했다. KEV 기준으로는 3일은 짧은 기간이다.
‘포함’이란 CISA가 신뢰할 수 있다고 판단하는 악용 증거를 보유하고 있음을 의미합니다. 이는 해당 증거가 공개되었다는 뜻은 아니며, 실제로 이 경우 증거는 공개되지 않았습니다. 카탈로그 항목에는 기술적 세부 사항이 포함되어 있지 않으며, 첨부된 경보에는 공격 체인이나 표적에 대한 내용이 전혀 언급되어 있지 않습니다. 또한 세 항목 모두 알려진 랜섬웨어 캠페인 사용 여부를 ‘알 수 없음’으로 기재하고 있습니다.
레드햇의 기록에는 현재 이 세 가지 모두에 대해 ‘알려진 악용’ 플래그가 표시되어 있지만, 레드햇은 자체적인 악용 세부 정보, 공격 체인, 표적 또는 원격 측정 데이터를 공개하지 않았으며, 이 플래그는 레드햇의 독립적인 관찰 결과가 아닌 KEV의 목록을 따르고 있습니다. 이를 KEV가 제공하는 신호와 동일한 것으로 간주해야 하며, 별도의 출처로 보아서는 안 됩니다.
따라서 이 목록을 CISA가 해당 취약점이 악용되고 있다는 증거를 확보했다는 신뢰할 만한 신호로 간주한 뒤, 각 취약점에 대한 실제 전제 조건을 종합적으로 검토해야 합니다. KEV 지정은 우선순위를 높여주지만, 실질적인 시급성은 여전히 호스트에서 각 취약 경로에 접근 가능한지 여부에 달려 있습니다.
점수가 일치하지 않으니, 점수가 일치할 때까지 기다려서는 안 됩니다
현재 유포되고 있는 9.8, 8.8, 7.8이라는 수치는 실제 값이며, 레드햇의 제품별 점수는 이와 또 다릅니다. CVE-2025-39682는 7.0, CVE-2026-53266은 7.5, CVE-2025-39964는 7.3입니다. 이러한 차이는 공격 경로와 악용 가능성 및 영향도에 대한 가정의 차이에서 비롯됩니다.
CVE-2025-39682가 대표적인 예입니다. NVD는 이 취약점에 9.8점을 부여한 반면, 레드햇은 RHEL 기준 7.0점을 부여했습니다. 두 기관 모두 이 취약점을 ‘네트워크를 통해 접근 가능’한 것으로 간주하지만, 레드햇은 공격 복잡도를 ‘높음’으로, 기밀성 및 무결성 영향도는 더 낮게 평가했기 때문에 동일한 버그가 서로 매우 다른 등급으로 분류되었습니다.
이러한 구분은 분석에 있어 중요하지만, 이를 이유로 수정 조치를 미뤄서는 안 됩니다. 이 세 가지 모두 CISA의 KEV 목록에 포함되어 있으며, 중요한 것은 어느 점수가 더 높은지가 아닙니다. 시스템에서 해당 취약점이 노출된 경로에 접근할 수 있는지 확인하고, 이를 기준으로 우선순위를 정한 뒤, 수정된 커널이나 라이브 패치를 적용하고, 실행 중인 커널이 실제로 해당 패치의 적용 범위에 포함되는지 확인하십시오.
커널 TLS 버그와 제로 길이 레코드
CVE-2025-39682는 커널 TLS의 수신 측에 존재하며, 이는 핸드셰이크 후 애플리케이션이 TLS 레코드 처리의 일부를 커널로 오프로드할 수 있게 해주는 커널 내 레코드 계층입니다.
각 recvmsg() 이 호출은 연속된 데이터 레코드 일련이나 단일 비데이터 레코드 중 하나만 처리해야 하며, 두 가지가 혼합된 경우는 절대 처리해서는 안 됩니다. 이미 큐에 등록된 길이가 0인 레코드는 rx_list 해당 레코드 유형 검증을 무사히 통과해 버리기 때문에, 그 뒤의 레코드들은 잘못된 제로 카피 및 큐잉 가정을 바탕으로 처리됩니다. 이러한 불일치로 인해 수신 경로가 레코드와 보유 중인 버퍼에 대해 가졌던 가정이 무너지게 되며, 이것이 바로 레드햇이 이 문제를 단순한 가용성 버그보다 더 심각하게 평가하는 이유입니다.
접근성이야말로 중요한 부분입니다. ~를 갖추는 것이 CONFIG_TLS 커널 수준만으로는 충분하지 않습니다. TLS 상위 계층 프로토콜은 TCP 소켓에 연결되어야 하는데, 이는 사용자가 이를 선택했을 때만 발생합니다. 예를 들어, kTLS를 사용하도록 구성된 nginx 배포 환경, 호환되는 OpenSSL kTLS 경로를 기반으로 빌드된 애플리케이션, 또는 TLS를 통한 NFS 등이 이에 해당합니다. tlshd. kTLS가 의도적으로 활성화되어 있고 해당 애플리케이션에서 이를 비활성화할 수 있는 경우, 오프로드를 비활성화하면 일정 수준의 CPU 비용이 발생하지만 레코드 처리가 사용자 공간으로 되돌아갑니다. 이를 패치 적용을 대체하는 수단이 아닌, 임시적인 완화 조치로 간주하십시오.
이 수정 사항은 업스트림 커밋에 반영되었습니다. 62708b9452f8, 2025년 8월 19일자. 레드햇은 2025년 9월 29일에 수정된 RHEL 9 및 RHEL 10 커널을 배포했으며, 9.2 SAP 및 9.4 EUS 스트림은 10월 말에 이어 배포되었습니다. 이 CVE와 관련하여 레드햇은 RHEL 6, 7, 8이 영향을 받지 않는다고 밝혔습니다. 해당 취약점 코드는 리눅스 6.0의 업스트림에 도입되었으며, RHEL 9 및 10 커널 스트림에는 존재하지만 4.18 기반의 RHEL 8 또는 그 이전 버전에는 존재하지 않습니다. 이후 이 결함을 악용해 커널 메모리 손상을 유발하고 특정 kernelCTF 타깃에 대해 루트 셸을 획득하는 공개 익스플로잇 코드가 등장했습니다. 이는 실제 운영 환경의 RHEL 커널에 적용 가능한 이식형 익스플로잇과는 다르지만, 리시브 패스(receive-path) 버그가 어딘가에서 무기화되었음을 의미합니다.
잘못된 페이지에 데이터를 기록하는 Ebtables SNAT 버그
CVE-2026-53266은 세 가지 취약점 중 레드햇 CVSS 점수가 7.5로 가장 높으며, 레드햇 심각도 등급은 ‘중요(Important)’로 분류되고, 가장 흥미로운 오류 발생 양상을 보입니다.
ebtables의 SNAT 타겟은 ARP 패킷이 브리지를 통과할 때, 선택적으로 해당 패킷 내의 발신자 하드웨어 주소를 재작성할 수 있습니다. 이는 다음을 통해 이루어집니다. skb_store_bits(), 이는 패킷의 비선형 조각들에 데이터를 기록합니다. 이러한 조각 중 하나는 다음을 통해 불러온 파일 페이지로 뒷받침될 수 있습니다. splice, 따라서 이 경로를 통해 수정할 의도가 전혀 없었던 파일 기반 페이지에 쓰기 작업이 반영될 수 있습니다. 레드햇은 이를 CWE-825에 매핑하며, 그 결과로 메모리 손상, 서비스 거부 또는 권한 상승으로 이어질 수 있다고 설명합니다.
전제 조건은 엄격합니다. 브리지에 관리자가 설정한 ARP 재작성 기능이 포함된 ebtables SNAT 규칙이 반드시 있어야 하며, 공격자는 이를 활성화할 수 없습니다. 브리지에 연결된 많은 호스트는 ebtables NAT를 전혀 사용하지 않습니다. 간단한 초기 확인으로, NAT 테이블에 ARP 재작성 SNAT 규칙이 있는지 살펴보세요:
sudo ebtables -t nat -L | grep -i 'snat-arp'
이를 어떤 결론을 내리기 위한 증거라기보다는 초기 구성 확인으로 간주하십시오. 일치하는 출력이 없는 것은 해당 호스트에 해당 규칙이 구성되어 있지 않음을 강력하게 시사합니다. 규칙과 일치하는 경우, 귀사의 변경 절차에 따라 해당 호스트를 수정 대기열의 상단으로 이동시켜야 합니다. 재작성이 실제로 필요하지 않은 경우, 수정된 커널이 적용될 때까지 해당 규칙을 비활성화하면 취약점을 줄일 수 있지만, 변경 사항을 적용하기 전에 네트워크 설계에 따라 유효성을 검증해야 합니다.
업스트림 수정 사항은 다음 커밋입니다. 67ba971ae025, 2026년 5월 23일자. 레드햇은 해당 목록이 공개되기 훨씬 전인 7월에 RHEL 8과 9에 대한 수정 사항을 적용했으며, 이어 9월 24일에 RHEL 10과 RHEL 7 ELS, 그리고 9월 30일에 RHEL 6 ELS에 대한 수정 사항을 적용했습니다. RHEL 9 kernel-rt는 여전히 영향을 받는 것으로 표시되어 있습니다.
하나의 AF_ALG 소켓을 사용하는 두 명의 작성자
CVE-2025-39964는 커널 암호화 API를 사용자 공간에 노출하는 소켓 인터페이스인 AF_ALG의 동시성 버그입니다. 동일한 AF_ALG 소켓에 대한 두 개의 동시 쓰기 작업이 서로 얽히게 되어 소켓별 컨텍스트의 일관성이 깨질 수 있습니다.
레드햇은 이 직접적인 취약점이 로컬 사용자가 시스템을 다운시키거나 암호화 결과를 손상시킬 수 있게 한다고 설명합니다. 이후 평가 점수는 엇갈립니다. NVD의 기본 점수는 5.5로, 가용성 영향만 반영됩니다. 반면 리눅스 CNA는 7.8로 평가했으며, 레드햇은 기밀성 및 무결성 영향을 추가한 평가 기준에 따라 7.3을 부여했습니다. 결정적인 차이는 공개된 익스플로잇에 있습니다. 한 저장소에서는 이 레이스 조건을 커널 메모리 손상, 커널 주소 유출, 덮어쓰기로 이어지는 일련의 과정을 보여줍니다. core_pattern, 그리고 루트 셸을 확보합니다. 저자의 자체 메모와 독립적인 검토 결과 모두 하드코딩된 오프셋과 커널 간에 적용되지 않을 수 있는 KASLR 우회 기법을 지적하고 있으므로, 이는 지원되는 RHEL에 대한 이식 가능한 익스플로잇이라기보다는 특정 빌드에서 검증된 권한 상승 체인입니다. 어느 쪽이든, ‘크래시만 발생한다’는 주장은 더 이상 성립하지 않으며, 공유 또는 멀티테넌트 호스트 환경에서는 이것이 중요한 문제입니다.
업스트림 수정 사항은 다음 커밋입니다. 1b34cbbf4f01, 2025년 9월 16일자입니다. 또한 이 CVE는 등록 후 레드햇이 가장 신속하게 수정 패치를 배포한 사례이기도 합니다. 9월 21일 당시, 레드햇은 해당 CVE에 대한 수정 사항을 어떤 제품에서도 공개하지 않았습니다. 첫 번째 수정 사항은 9월 22일에 공개되었으며, 9월 24일까지 RHEL 8, 9, 10, RHEL 7 ELS 및 확장 지원 버전에 대한 수정 패치가 배포되었습니다.
아무 효과도 없는 AF_ALG 해결 방법
이 녀석은 사람들을 물게 될 거야.
레드햇은 앞서 CVE-2025-39964에 대한 지침을 통해 다음을 방지할 것을 권고했습니다. af_alg 모듈이 로드되는 것을 막습니다. 현재 페이지에는 더 이상 해당 줄이 포함되어 있지 않은데, 다행인 일입니다. 왜냐하면 여기서 확인한 Enterprise Linux 커널에서는 이 기능이 전혀 작동하지 않았기 때문입니다. 해당 커널에서는 AF_ALG가 로드 가능한 모듈로 제공되는 대신 커널에 내장되어 있습니다. AlmaLinux 8, 9, 10 및 CloudLinux 8에 포함된 커널은 CONFIG_CRYPTO_USER_API=y, AF_ALG 구현체와 이에 대한 프론트엔드가 내장되어 있습니다. 이 modules.builtin 파일 목록 kernel/crypto/af_alg.ko, 그리고 이 패키지에는 별도의 af_alg.ko.
A modprobe.d 따라서 블랙리스트는 오류 없이 허용될 수 있지만, 내장 구성 요소를 비활성화할 수는 없습니다. 다음의 경우도 마찬가지입니다. modprobe.blacklist=af_alg 커널 명령줄에서. 테스트한 구성 중 AF_ALG를 비활성화하는 지원되는 sysctl 또는 부팅 매개변수는 발견되지 않았습니다.
그런데 대부분의 사람들이 무심코 선택하는 방법은 정반대입니다:
lsmod | grep af_alg
출력이 비어 있다고 해서 AF_ALG가 비활성화되었다는 증거는 아닙니다. 여기서 검증된 커널에서는 이는 AF_ALG가 모듈로 로드된 것이 아니라 내장되어 있다는 점과 일치하며, 이는 다음을 통해 확인할 수 있습니다. CONFIG_CRYPTO_USER_API 이 게시물 맨 위에 있는 grep 명령어를 사용하여 modules.builtin. 이 명령어가 아무 결과도 반환하지 않는다고 해서 해당 호스트를 보호 대상이라고 간주해서는 안 됩니다. 설정에 다음과 같이 표시되어 있다면 =y, 실제 선택지는 커널 패치나 재부팅 없이 적용되는 패치뿐입니다. 다층 방어 전략의 일환으로, 철저히 테스트된 seccomp 정책은 다음을 차단할 수 있습니다. socket() 선택된 워크로드에 대해서는 AF_ALG 주소 패밀리를 사용하도록 요구하지만, 이는 워크로드에 따라 다르며 호스트의 일반 로컬 사용자에 대해서는 별다른 도움이 되지 않습니다.
누가 영향을 받나요?
다음은 2026년 10월 2일까지 검토된 소스 자료를 바탕으로 한 세 가지 주요 엔터프라이즈 리눅스 제품군의 현황입니다. 각 셀에는 공급업체별 커널 상태가 먼저 표시되며, AlmaLinux와 CloudLinux의 경우 두 가지가 서로 다른 유형의 수정 사항이므로, 차이가 있는 부분에는 KernelCare의 재부팅 없이 적용되는 수정 범위 정보가 추가로 기재되어 있습니다. 날짜만 보지 말고 라벨 내용을 확인하시기 바랍니다:
| 유통 | 39682 | 53266 | 39964 |
| RHEL | 9일과 10일(2025년 9월 29일)에 수정됨; 6, 7, 8일은 영향을 받지 않음 | 2026년 7월 8일과 9일, 9월 24일 10 및 7 ELS, 9월 30일 6 ELS에서 수정됨; 9 kernel-rt는 여전히 영향을 받음 | 7 ELS부터 10까지(2026년 9월 22일부터 24일까지) 수정됨; 9 kernel-rt는 여전히 영향을 받음 |
| AlmaLinux | 공급업체는 9 및 10 버전(2025년 9월 29일)에 대한 수정 사항을 확정했으며, 8 버전은 영향을 받지 않습니다. 9 및 10 버전을 위한 KernelCare의 재부팅 불필요 패치는 2025년 10월부터 안정판 피드에 포함되어 있습니다. | 공급업체는 8(7월 14일)과 9(2026년 7월 8일) 버전을 수정했으며, 10 버전은 아직 배포되지 않았습니다. 8 및 9 버전에 대한 KernelCare의 재부팅 없이 적용 가능한 패치는 7월부터 안정판 피드에 포함되어 있으며, 10 버전은 9월 30일에 출시되었으나 아직 안정판 피드에는 포함되지 않았습니다. | 공급업체는 8(9월 22일)과 9(2026년 9월 23일) 버전을 확정했으며, 10 버전은 아직 배포되지 않았습니다. 9 및 10 버전을 위한 KernelCare 재부팅 불필요 패치는 9월 30일에 출시되었으나, 아직 안정판 피드에는 포함되지 않았으며, 8 버전은 아직 출시되지 않았습니다. |
| CloudLinux | 8, 9, 10 트랙의 AlmaLinux에는 영향을 미치지 않음 | 4.18.0-553.142.1 버전부터 CL8 커널에 포함되었으며, 9 및 10 버전은 AlmaLinux를 따릅니다. | CL8용 KernelCare 라이브 패치가 출시되었습니다(2026년 9월 30일). 아직 안정판 피드에는 포함되지 않았으므로 정확한 커널 버전을 확인하시기 바랍니다. |
Rocky Linux와 Oracle Linux는 위 표에 별도로 기재되어 있지 않지만, RHEL과 동일한 업스트림 코드를 따르고 있으므로, 날짜가 일치한다고 가정하기보다는 각 배포판의 공지 사항과 실제 실행 중인 커널 버전을 직접 확인하시기 바랍니다. RHEL 8(8.4, 8.6, 8.8) 및 RHEL 9(9.2, 9.4, 9.6)용 레드햇의 확장 업데이트 지원(EUS) 스트림도 9월 23일부터 24일 사이에 수정 패치를 받았으며, 이전 주요 릴리스인 RHEL 6 및 7은 확장 수명 주기 지원(ELS)을 통해 유지 관리되고 있는데, 표에 기재된 ELS 항목은 바로 이를 가리킵니다.
두 가지 간단한 참고 사항입니다. CloudLinux 8에서는 다음 출처의 커널을 4.18.0-553.142.1 onward에는 이미 CVE-2026-53266에 대한 수정 사항이 반영되어 있으니 확인해 보세요. uname -r 취약점이 있다고 단정하기 전에. 또한 레드햇은 9월 말 CVE-2026-53266에 대해 RHEL 6의 영향을 받지 않음(Not affected) 상태를 영향을 받음(Affected)으로 변경했으며, 9월 30일에 RHEL 6 ELS 수정 패치를 배포했습니다. 이는 확장 수명 주기 지원(Extended Life Cycle Support) 하에서 여전히 RHEL 6 또는 CloudLinux 6을 실행 중인 모든 사용자에게 중요한 사항입니다.
데비안(Debian), 우분투(Ubuntu), 아마존 리눅스(Amazon Linux)는 각기 자체 일정에 따라 이러한 CVE를 추적합니다. RHEL의 내용을 참고하기보다는 사용 중인 커널에 해당하는 보안 권고문을 직접 확인하시기 바랍니다.
KernelCare의 재부팅 없이 적용 가능한 패치는 이 게시물 상단 근처의 상태 상자에 표시된 타임라인에 따라 RHEL 계열에도 적용되므로, 위의 RHEL 행은 재부팅 없이 적용 가능한 패치 옵션이 없는 것이 아니라 레드햇 자체 커널을 반영한 것입니다.
실행 중인 커널 패치 및 검증
디스크에 저장된 수정된 커널 패키지는 메모리 내의 커널을 변경하지 않습니다. 일반적인 업데이트를 수행하려면, 사용 중인 릴리스와 정확히 일치하는 수정된 커널 패키지를 설치하고, 시스템을 재부팅한 후 실제로 어떤 커널이 실행 중인지 확인하십시오:
uname -r
디스크에 있는 최신 버전이 아니라, 레드햇(Red Hat)이나 재구축 권고 사항과 비교해 보십시오. 3주 전에 업데이트를 설치한 후 한 번도 재부팅하지 않은 호스트는 여전히 구버전 커널을 실행 중입니다.
지원되는 패치가 있는 경우, KernelCare는 재부팅 없이 활성 커널에 해당 수정 사항을 적용합니다. 이러한 수정 사항은 앞서 언급한 스트림을 통해 재부팅이 필요 없는 라이브 패치 형태로 제공되며, 라이브 패치의 제공 여부는 커널별로 다릅니다. 자동 업데이트가 활성화된 구성에서는 새로운 패치를 주기적으로 가져오며, kcarectl --update 필요할 때 요청합니다. 실행 중인 커널에서 다음 세 가지 중 어떤 것이 지원되는지 확인하십시오:
kcarectl --patch-info | grep -E 'CVE-2025-39682|CVE-2026-53266|CVE-2025-39964'
실행 중인 커널에 해당 CVE가 표시되지 않는 경우, 다른 배포판, 다른 마이너 스트림 또는 부팅된 적이 없는 패키지 업데이트를 근거로 해당 CVE가 적용되었다고 추측해서는 안 되며, CVE가 표시될 때까지 검증된 임시 완화 조치를 유지해야 합니다. CloudLinux 8은 특별한 경우로, 라이브 패치 쿼리에서 별도의 패치가 표시되지 않더라도 최신 커널에 CVE-2026-53266에 대한 수정 사항이 이미 기본적으로 포함되어 있을 수 있습니다.
이 중 제로데이 취약점이 있나요?
아닙니다. 모든 수정 사항은 목록에 등재되기 전에 업스트림에서 이미 공개되었으며, 레드햇은 CVE-2025-39682에 대한 수정된 커널을 거의 1년 전에 이미 배포한 상태였습니다. 이번에 공개된 새로운 내용은 CISA의 KEV 지정뿐인데, 이는 해당 취약점이 악용되고 있는 것으로 알려져 있음을 나타내지만, 구체적인 악용 방법은 공개하지 않습니다. 이는 흔히 볼 수 있는 ‘n-day’ 사례입니다. 적용되지 않은 오래된 커널 수정 사항이야말로 공격자들이 노리는 바로 그 대상입니다.
하지만 이 익스플로잇 코드에 대해서는 정확히 짚어둘 필요가 있습니다. 현재 CVE-2025-39682와 CVE-2025-39964에 대해 정상 작동하는 권한 상승 PoC가 포함된 공개 저장소가 존재하며, 이 둘 모두 하드코딩된 오프셋을 가진 특정 커널CTF 스타일의 타깃을 대상으로 제작되었습니다. 이는 패치는 되었으나 재부팅되지 않은 운영 환경의 시스템에 대한 이식 가능한 익스플로잇이 아니라, 실질적인 무기화 사례입니다. 따라서 “누구나 어떤 호스트든 루트 권한을 획득할 수 있다”는 주장이 마찬가지로 틀렸다고 하더라도, “공개된 PoC가 없다”는 주장은 현재 시점에서 명백히 틀린 말입니다.
KEV 커널 트리오가 중요한 이유
이 세 가지 방법 중 어느 것도 광범위하고 사전 조건이 없는 공격 경로를 제공하지 않습니다. 하나는 kTLS가 필요하고, 다른 하나는 관리자가 구성한 특정 ebtables 규칙이 필요하며, 세 번째는 로컬 접근 권한이 필요합니다. 다만, 공개된 익스플로잇 연구 결과에 따르면 특정 커널을 대상으로 한 권한 상승 체인이 확인되었습니다. 이것이 다행스러운 부분입니다.
주변의 모든 것에서 교훈을 얻을 수 있습니다. CISA가 공식 발표를 하기 전에도 이 세 가지 문제 모두 수정 가능했으며, 업스트림 수정, 벤더의 백포트, 시스템 배포, 그리고 악용은 서로 다른 일정에 따라 진행됩니다. 한편, 유포된 취약점 점수들은 사람들에게 잘못된 긴급성을 심어주었고, 한 CVE에 대한 공급업체의 초기 임시 해결책은 보호 대상으로 지정된 커널에서는 아무런 효과도 내지 못했습니다. 또한 레드햇이 CVE-2025-39964에 대한 패치를 배포하기도 전에 3일 기한이 지나버렸기 때문에, 해당 CVE에 대한 연방 정부의 시정 기한이 도래했을 때 공급업체의 커널 패치는 단순히 사용할 수 없는 상태였습니다.
기존 방식으로 패치가 적용된 플릿의 경우, 적절한 일정에 따라 수정된 커널을 설치하고 재부팅하되, ebtables ARP 재작성 호스트와 kTLS 호스트를 우선적으로 처리하십시오. 재부팅 조율이 병목 현상이 되는 플릿의 경우, KernelCare는 정상적인 유지보수가 진행되는 동안 실행 중인 커널에서 지원 대상 경로를 차단합니다.
연표
| 날짜 | 이벤트 |
| 8월 19, 2025 | 업스트림 kTLS 수정 사항 62708b9452f8 CVE-2025-39682에 대한 랜딩 페이지 |
| 9월 16, 2025 | 업스트림 AF_ALG 수정 1b34cbbf4f01 CVE-2025-39964 랜딩 페이지 |
| 9월 29, 2025 | 레드햇, CVE-2025-39682에 대한 수정된 RHEL 9 및 RHEL 10 커널 배포 |
| 10월 2025 | KernelCare, Enterprise Linux 9 및 10용 CVE-2025-39682 재부팅 없이 적용 가능한 패치 출시 |
| 5월 23, 2026 | 업스트림 ebtables 수정 사항 67ba971ae025 CVE-2026-53266에 대한 랜딩 페이지 |
| 7월 2026 | 레드햇, RHEL 8 및 9의 CVE-2026-53266 취약점 수정… 커널케어, 엔터프라이즈 리눅스 8 및 9용 재부팅 없이 적용 가능한 패치 출시 |
| 9월 18, 2026 | CISA는 이 세 가지 CVE를 모두 KEV 카탈로그에 추가했습니다. |
| 9월 21, 2026 | 연방 민간 기관에 대한 BOD 26-04 시정 조치 기한 |
| 2026년 9월 22일부터 24일까지 | 레드햇은 RHEL 7 ELS, 8, 9, 10 전반에 걸쳐 CVE-2025-39964에 대한 수정 사항을 배포했으며, CVE-2026-53266에 대한 수정 범위를 RHEL 10 및 RHEL 7 ELS로 확대했습니다(RHEL 8 및 9는 이미 7월에 수정되었습니다). |
| 9월 30, 2026 | 레드햇(Red Hat)은 CVE-2026-53266에 대한 RHEL 6 ELS 수정 패치를 배포했습니다. 커널케어(KernelCare)는 나열된 스트림에 대한 CVE-2025-39964 릴리스와, 아직 안정판 피드에 포함되지 않은 RHEL 10 및 AlmaLinux 10용 CVE-2026-53266 릴리스를 공개했습니다. 해당 커널에 대한 피드 제공 여부를 확인하십시오. |
참조
이 게시물의 주요 출처는 CISA ‘악용된 것으로 알려진 취약점’ 카탈로그 (카탈로그 버전 2026.10.01), 2026년 9월 18일자 CISA 경보, 구속력 있는 운영 지침 26-04, Red Hat의 CVE-2025-39682, CVE-2026-53266, CVE-2025-39964에 대한 레드햇의 CVE 페이지, CVE-2025-39682, CVE-2026-53266, CVE-2025-39964에 대한 NVD 항목, 그리고 업스트림 수정 사항 62708b9452f8, 67ba971ae025 및 1b34cbbf4f01에 대한 정보를 포함합니다.