아파치 취약점 CVE-2026-119618, HTTP/2 켜둔 서버는 2.4.71로

아파치 취약점 CVE-2026-119618이 11월 11일 공개됐습니다. 아파치 HTTP 서버의 HTTP/2 모듈 mod_http2에서 메모리가 깨지고, 인증 없이 원격에서 명령을 실행할 수 있는 결함입니다. 같은 날 배포된 2.4.71이 이 구멍을 막습니다. HTTP/2를 켜둔 서버라면 지금 버전부터 확인해야 합니다.

영향 범위는 2.4.55부터 2.4.70까지입니다. 레드햇은 이 결함에 CVSS 3.1 기준 9.8을 매겼습니다. 공격 경로는 네트워크, 복잡도는 낮음, 권한과 사용자 조작은 필요하지 않은 조합입니다.

웹 서버 프로세스 권한으로 명령이 실행된다는 뜻은 그 서버에 얹힌 다른 서비스까지 위험해진다는 것입니다. 보안 업체 Wiz는 자사 데이터 기준 클라우드 환경의 64%에 취약한 자원이 있고, 클라우드 환경의 51%에는 인터넷에 직접 노출된 인스턴스가 있다고 적었습니다.

아파치 취약점의 원인, assign_headers의 경쟁 조건

HTTP/2는 연결 하나로 요청 여러 개를 동시에 주고받습니다. mod_http2는 이 요청들을 여러 스레드로 나눠 처리하는데, 문제는 그 과정의 동기화입니다.

레드햇 설명을 그대로 옮기면, 작업 스레드가 공유 락프리 할당자를 통해 연결 스레드가 소유한 메모리에 써버리는 구조입니다. 한 스레드가 다른 스레드의 메모리를 건드리면 서버 내부 메모리가 깨지고, 그 손상을 조작 가능한 형태로 만들면 원격 코드 실행으로 이어집니다.

발견 경로는 두 갈래입니다. Anthropic의 OSS 스캐너가 10월 26일 ANT-2026-MAPKT6MZ로 보고했고, 구글 클라우드 취약점 연구팀의 Anthony Weems와 Simon Scannell이 11월 3일 따로 보고했습니다. 아파치 재단은 11월 11일 2.4.71을 배포했습니다.

조건이 하나 있습니다. h2 또는 h2c를 켠 서버만 해당됩니다. Protocols 지시어로 HTTP/1.1만 서비스하는 서버는 이 결함의 영향을 받지 않습니다.

영향 범위 2.4.55~2.4.70, 2.4.71에서 고친 CVE 3건

2.4.71에는 critical 1건, important 1건, low 1건이 함께 들어갔습니다. 버전은 아파치 재단 보안 문서 기준입니다.

mod_h2를 깃허브 배포본으로 따로 쓰는 경우도 확인해야 합니다. 아파치 재단은 2.0.8부터 2.0.42까지를 영향 범위로 적었습니다. 배포판 패키지가 아니라 모듈을 직접 빌드해 쓴다면 이 번호를 먼저 봐야 합니다.

나머지 두 건은 성격이 다릅니다. mod_md는 인증서 관리 모듈이라 NULL 포인터 역참조로 자식 프로세스가 종료되는 정도이고, mod_vhost_alias는 2.4.69와 2.4.70 두 버전만 해당하는 1바이트 덮어쓰기입니다. 급한 건 첫 번째입니다.

지금 할 일, 2.4.71 업그레이드와 HTTP/2 끄기

순서는 단순합니다. 패키지를 올릴 수 있으면 올리고, 쓰는 배포판에 아직 2.4.71이 없으면 HTTP/2를 잠시 끕니다.

임시 조치는 설정에서 프로토콜을 HTTP/1.1로 좁히는 것입니다. httpd.conf나 가상호스트 설정에 Protocols http/1.1 한 줄을 두고, 기존에 적힌 h2와 h2c를 뺍니다. 재시작한 뒤 실제로 HTTP/2 협상이 사라졌는지 확인해야 조치가 끝난 것입니다.

내 서버가 대상인지부터 확인하려면 버전과 모듈을 봅니다. httpd -v(데비안·우분투는 apache2 -v)로 버전을, httpd -M | grep http2(데비안·우분투는 apache2ctl -M)로 모듈 로드 여부를 확인합니다. 버전이 2.4.55~2.4.70이고 http2_module이 보이면 대상입니다.

끄는 조치는 HTTP/2의 이점을 포기하는 선택입니다. 요청 여러 개를 연결 하나로 처리하는 기능이니만큼, 패키지가 나오는 대로 올리는 편이 낫습니다.

배포판 패치 상황, RHEL 8은 영향 없음

레드햇은 11월 11일 같은 날 mod_http2 에러타를 냈습니다. RHEL 10은 RHSA-2026:98978, RHEL 9는 RHSA-2026:98981입니다. 확장 지원(EUS)과 SAP용 스트림도 함께 나왔습니다.

흥미로운 건 등급입니다. 레드햇은 이 결함을 RHEL 9·10에서 Important로 낮춰 매겼습니다. 두 버전의 mod_http2가 HTTP/2 스트림마다 별도 할당자를 써서, 같은 락프리 할당자를 공유하는 구조보다 악용 난이도가 크게 올라간다는 설명입니다. 전체 등급은 Critical, 자사 제품 등급은 Important인 셈입니다.

RHEL 8 이하는 영향 없음으로 정리됐습니다. 취약한 코드가 2.0.8 이전 mod_h2에는 없기 때문입니다. JBoss Core Services와 Hardened Images는 아직 Affected로 남아 있습니다.

해커뉴스 반응, RCE라는 표현부터 갈렸다

해커뉴스 스레드(31점, 댓글 18개)에서 눈에 띈 지적은 심각도 표기가 아니라 용어였습니다. "메모리 손상이 언제부터 RCE와 같은 말이 됐나"라는 댓글이었고, 컨트롤 가능한 손상이면 임의 코드 실행까지 갈 수 있다는 반론이 바로 붙었습니다.

한 댓글은 RCE라고 부르려면 실제로 동작하는 익스플로잇이 있어야 한다고 했고, 다른 댓글은 아파치 재단 보고서가 RCE 가능하다고 적었으니 관계 기관 중 하나는 동작하는 익스플로잇을 갖고 있을 것이라고 받았습니다. 레드햇 문서를 인용한 댓글도 있었습니다. 기본 설정 서버에 대한 신뢰할 만한 익스플로잇이 공개 연구로 확인됐다는 문장입니다.

Wiz는 자기 글을 쓴 시점에 공개된 익스플로잇이 없고 실제 악용 보고도 없다고 적었습니다. 레드햇은 공개 연구에서 재현됐다고 적었습니다. 두 문장은 충돌이라기보다 공격 도구는 아직 풀리지 않았지만 재현은 됐다는 뜻으로 읽힙니다.

댓글 중에는 2.4.55부터 2.4.70이라니, 내 버전은 그렇게 최신이 아니라서 다행이라는 자조도 있었습니다. 오래된 서버를 그대로 두는 습관이 이번엔 방패가 된 셈인데, 다음 CVE에서도 같은 말이 통하지는 않습니다.

HTTP/2를 켜둔 아파치 서버라면 오늘 2.4.71로 올리고, 패키지가 아직 없으면 Protocols http/1.1로 잠시 막습니다. 로그에서 의심스러운 HTTP/2 요청을 찾는 일은 그다음입니다.

원문 보기 — Apache HTTP Server 2.4 취약점 목록

분석 원문 — Critical RCE Vulnerability in Apache HTTP Server

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.