xeloxa/cve-2026-23918-apache-h2-pocCVE-2026-23918(Apache mod_http2 이중 해제)에 대한 개념 증명 익스플로잇입니다. 다중 모드 DoS(Rapid-RST, Slow-Drip) 및 Apache 2.4.66에 대한 수동적 RCE/취약점 탐지를 제공합니다.
이것은 Apache의 mod_http2(CVE-2026-23918)에 존재하는 double-free 취약점에 대한 개념 증명 익스플로잇입니다. h2_mplx.c 스트림 정리 경로에 영향을 주는 까다로운 버그입니다.
기본적으로, 타이밍을 잘 맞추면 서버가 동일한 스트림을 두 번 정리하도록 만들 수 있으며, 이는 일반적으로 SIGSEGV와 워커 크래시로 이어집니다.
멍청하게 굴지 마세요. 승인된 테스트에만 사용하세요. 소유하지 않은 대상에 사용하면 모든 책임은 본인에게 있습니다. 이 도구로 인한 결과에 대해 저는 책임을 지지 않습니다.
CVE-2026-23918은 Apache 2.4.66에 영향을 줍니다. 이번 달(2026년 5월) 초 2.4.67에서 패치되었습니다.
이것은 Apache가 초기 RST_STREAM 프레임을 처리하는 방식의 레이스 컨디션입니다. 클라이언트가 HEADERS 프레임을 보내고 멀티플렉서가 스트림을 등록하기도 전에 즉시 RST_STREAM을 보내면, 두 개의 서로 다른 콜백이 정리를 시도합니다.
하나의 콜백은 리셋을 처리하고, 다른 콜백은 스트림 종료를 처리합니다. 둘 다 m_stream_cleanup()을 호출하여 동일한 포인터를 정리 배열에 푸시합니다. Apache가 결국 해당 스트림을 파괴하려고 할 때, 두 번째 시도는 이미 해제된 메모리에 접근하게 됩니다.
DoS: 매우 쉽습니다. 단일 연결로 워커를 크래시시킬 수 있습니다. Apache가 워커를 다시 생성하므로, 매우 적은 대역폭으로 서버를 지속적인 압박 상태로 유지할 수 있습니다. 이것이 이 PoC가 시연하는 내용이며, Apache 2.4.66에서 테스트되어 작동이 확인되었습니다.
RCE: 이론적으로는 가능하지만 대부분의 공격자에게 실용적이지 않습니다. 다음이 필요합니다:
mmap, Debian/Ubuntu/Docker의 기본값)공개된 RCE 익스플로잇은 존재하지 않으며, 이를 구축하는 것은 간단하지 않은 엔지니어링 작업입니다. 대부분의 조직에 대한 실제 영향은 RCE가 아닌 신뢰할 수 있는 DoS입니다.
Python 3.9+와 h2 라이브러리가 필요합니다.
git clone https://github.com/xeloxa/CVE-2026-23918-Apache-H2-PoC.git
cd CVE-2026-23918-Apache-H2-PoC
pip install -r requirements.txt
로컬 랩 크래시:
# 공격적인 DoS
python3 cve-2026-23918.py --target 127.0.0.1 --port 8443 --mode dos
대상이 취약한지 확인:
# 이는 수동적 방식으로, 헤더와 H2 지원만 확인합니다
python3 cve-2026-23918.py --target example.com --mode rce-detect
지속적인 압박:
# 낮은 대역폭, 긴 지속 시간
python3 cve-2026-23918.py --target 10.0.0.50 --mode slow-drip -d 60
2.4.66을 실행 중이라면 2.4.67로 업그레이드해야 합니다.
지금 당장 업데이트할 수 없다면, 설정에 Protocols http/1.1을 추가하여 HTTP/2를 비활성화할 수 있습니다 (또는 목록에서 h2를 제거). 성능 면에서는 이상적이지 않지만 크래시를 막을 수 있습니다.
여러 Debian 및 Ubuntu 빌드에서 테스트했습니다. DoS는 매우 안정적입니다. RCE는 훨씬 더 "까다로우며" 대상의 힙 상태가 매우 예측 가능하지 않는 한 실제 시나리오에서는 기대하지 않는 것이 좋습니다.