CVE-2026-119618 2.4.71 HTTP/2 패치

CVE-2026-119618이란 무엇인가요?

CVE-2026-119618은 Apache HTTP Server에서 HTTP/2 트래픽을 처리하는 모듈인 mod_http2의 치명적 취약점으로, 힙 손상과 원격 코드 실행으로 이어질 수 있습니다 ^[1].

Apache는 이를 “assign_headers()에 있는 Apache HTTP Server mod_http2의, 부적절한 동기화로 공유 자원을 동시에 사용하는 취약점”이라고 설명하며 “RCE로 이어질 수 있다”고 밝힙니다 ^[1]. 룩셈부르크의 국가 컴퓨터 긴급 대응팀 CIRCL은 HTTP/2 스트림을 동시에 처리하는 동안 워커가 다른 실행 컨텍스트에 할당된 헤더 테이블을 수정할 수 있으며, 공유 메모리에 대한 이러한 안전하지 않은 접근이 힙을 손상시킬 수 있다고 설명합니다 ^[2].

공격에 성공한 공격자는 로그인하지 않고도 Apache 웹 서버 프로세스의 권한으로 코드를 실행할 수 있습니다 ^[2][4]. BleepingComputer에 따르면 Apache HTTP Server는 전체 웹사이트의 약 5분의 1에서 쓰이는 것으로 추정됩니다 ^[4].

업스트림 수정은 modules/http2/h2_request.c의 쓰기 한 곳을 공유된 요청 헤더 테이블에서 현재 요청 자체의 입력 헤더로 바꾸는 것입니다 ^[2].

어떤 Apache 버전이 영향을 받나요?

Apache HTTP Server 2.4.55부터 2.4.70까지와 GitHub의 독립형 mod_h2 2.0.8부터 2.0.42까지가 영향을 받으며, 2.4.71에서 수정되었습니다 ^[1].

배포판 패키지는 버전 확인을 복잡하게 만듭니다. CIRCL은 배포업체가 관리하는 패키지를 쓰는 조직에 업스트림 버전 번호에만 의존하지 말고 보안 백포트를 확인하라고 권고합니다 ^[2]. CIRCL이 요약한 바에 따르면 Red Hat은 메모리 할당기 때문에 악용이 더 어렵다는 이유로 RHEL 9와 10 패키지를 치명적(Critical)이 아니라 중요(Important) 등급으로 평가하고, RHEL 8 이하는 영향이 없다고 밝힙니다 ^[2].

Red Hat은 일반적인 CVSS v3.1 점수를 9.8(Critical)로 제시합니다 ^[2][3]. Apache 자체 평가는 Critical입니다 ^[1].

내 Apache 서버는 취약한가요?

영향을 받는 빌드를 실행하면서 실제로 HTTP/2 연결을 받아들이는 경우에만 취약합니다. Red Hat은 HTTP/1.1 전용으로 설정된 서버는 취약하지 않다고 밝힙니다 ^[3]. CIRCL은 mod_http2가 설치되었거나 로드되었다는 이유만으로 해당 코드 경로에 도달할 수 있는 것은 아니라고 강조합니다 ^[2].

• HTTP/2는 Protocols 지시문이 제어합니다. “h2”는 TLS 위에서, “h2c”는 평문 위에서 HTTP/2를 활성화합니다 ^[2].
• Apache 코어의 기본 Protocols 값은 http/1.1 한 가지이며, mod_http2를 로드한다고 해서 이것이 저절로 바뀌지는 않습니다 ^[2]. BleepingComputer는 HTTP/2가 기본적으로 꺼져 있다고 전합니다 ^[4].
• 가상 호스트는 자체 Protocols 지시문을 설정할 수 있으므로, 전역 설정만 확인하면 HTTP/2가 활성화된 사이트를 놓칠 수 있습니다 ^[2].
• 리버스 프록시, 로드 밸런서, CDN이 HTTP/2를 종단하고 Apache에는 HTTP/1.1 트래픽만 전달한다면 클라이언트의 HTTP/2 세션만으로 Apache에 도달할 수 있게 되는 것은 아니지만, 각 구간의 프로토콜을 확인해야 합니다 ^[2].

CIRCL은 버전과 로드된 모듈(apachectl -v, apachectl -M), 설정된 가상 호스트(apachectl -S), 그리고 명시적인 모든 Protocols 설정을 검토하라고 제안합니다 ^[2]. 엔드포인트가 HTTP/2를 받아들인다는 테스트 결과가 그 백엔드가 취약하다는 것을 증명하지는 않으며, 부정적인 테스트 결과가 모든 포트나 가상 호스트가 HTTP/2를 거부한다는 것을 증명하지도 않습니다 ^[2].

서버가 HTTP/2를 받아들이는지 어떻게 확인하나요?

CIRCL은 두 가지 점검을 제안합니다. 서버에서 직접 Apache 설정을 검토한 다음, 가능하면 프록시를 거치지 않고 Apache에 직접 연결해 네트워크에서 협상된 프로토콜을 테스트하는 것입니다 ^[2].

1. 버전과 모듈을 확인하세요. apachectl -v로 버전을, http2로 필터링한 apachectl -M으로 모듈이 로드되었는지 확인합니다 ^[2].
2. 가상 호스트를 나열하세요. apachectl -S는 설정된 모든 가상 호스트를 보여 주며, 각 호스트가 자체 Protocols 줄을 가질 수 있으므로 중요합니다 ^[2].
3. 모든 Protocols 지시문을 찾으세요. CIRCL은 /etc/apache2와 /etc/httpd에서 가상 호스트 재정의를 포함한 명시적 Protocols 설정을 검색하는 grep 명령을 제시하며, 경로는 배포판마다 다릅니다 ^[2].
4. TLS로 테스트하세요. HTTP 버전을 출력하는 --http2 옵션의 curl 요청으로 HTTPS 엔드포인트가 HTTP/2를 협상하는지 알 수 있습니다 ^[2].
5. 평문을 테스트하세요. --http2-prior-knowledge를 쓴 curl로 일반 HTTP 엔드포인트가 h2c를 받아들이는지 확인합니다 ^[2].

결과는 신중하게 읽어야 합니다. HTTP/2로 응답했다는 결과는 테스트한 엔드포인트가 HTTP/2를 받아들였음을 보여 줄 뿐 그 Apache 백엔드가 취약하다는 것을 확인해 주지는 않으며, 부정적인 결과가 모든 주소, 포트, 가상 호스트가 이를 거부한다는 것을 증명하지는 않습니다 ^[2]. CIRCL의 조언은 실제 적용되는 Apache 설정과 업체의 패치 패키지 상태를 함께 확인하라는 것입니다 ^[2]. 클라우드 환경에서 Wiz는 침해된 Apache 인스턴스가 인근 마이크로서비스나 클라우드 메타데이터 엔드포인트로 횡적 이동하는 진입점이 될 수 있다고 경고하며, 이는 공개 웹사이트만이 아니라 모든 인스턴스를 확인해야 하는 또 다른 이유입니다 ^[5].

CVE-2026-119618은 어떻게 해결하나요?

Apache HTTP Server 2.4.71 이상으로 업그레이드하거나 사용 중인 배포판의 패치된 패키지를 설치한 다음, Apache를 재시작하고 실행 중인 프로세스가 새 빌드를 쓰는지 확인하세요 ^[2][1].

1. Apache를 업데이트하세요. 2.4.71 또는 CVE-2026-119618에 대해 명시적으로 패치된 업체 빌드를 설치합니다 ^[2].
2. 독립형 mod_h2를 쓴다면 업데이트하세요. 해당 업체의 안내에 따르며, Wiz는 2.0.42를 넘어서는 버전으로 옮기라고 하지만 CIRCL은 확인 없이 더 새로운 독립형 릴리스가 있다고 가정하지 말라고 경고합니다 ^[5][2].
3. 재시작하고 확인하세요. 실행 중인 프로세스가 수정된 빌드를 쓰는지 확인합니다 ^[2].
4. 아직 패치할 수 없다면 HTTP/2를 비활성화하세요. Protocols를 http/1.1로 설정하고, 재정의하는 모든 가상 호스트에서 h2와 h2c를 제거하고, apachectl -t로 테스트한 뒤 다시 로드합니다 ^[2]. 이는 이 결함의 경로를 막아 주지만 코드를 고치는 것은 아닙니다 ^[2].
5. 접근을 제한하세요. 패치도 프로토콜 변경도 할 수 없는 경우 임시 조치로 신뢰할 수 있는 네트워크로만 접근을 제한합니다 ^[2].

BleepingComputer에 따르면 watchTowr 연구자들은 이를 “지금 패치하거나, 패치할 수 있을 때까지 h2를 끄라”고 요약했습니다 ^[4]. SecurityWeek는 이 문제가 기반 웹 서버에 영향을 주므로 WordPress 보안 업데이트로는 해결할 수 없다고 Defiant도 경고했다고 전합니다 ^[3].

CVE-2026-119618은 악용되고 있나요?

Wiz가 2026년 11월 11일 게시한 글 기준으로, 사용 가능한 익스플로잇은 없었고 실제 악용 보고도 없었습니다 ^[5]. 다만 상황은 빠르게 변하고 있습니다.

• Red Hat은 공개된 연구가 mod_http2가 활성화된 서버에 대한 안정적인 익스플로잇을 시연했다고 밝히지만, 권고문에서 그 연구를 특정하지는 않습니다 ^[3]. CIRCL은 이것만으로는 실제 악용이 입증되는 것은 아니라고 지적합니다 ^[2].
• GitHub에 공개된 개념 증명은 메모리 손상과 Apache 충돌을 재현했다고 보고하지만 원격 코드 실행을 입증하지는 않습니다 ^[3].
• Wiz 데이터에 따르면 클라우드 환경의 64%에 영향을 받는 버전을 실행하는 리소스가 있고 51%에 공개적으로 노출된 인스턴스가 있습니다. Wiz는 이것이 설정을 고려하지 않은 수치이므로 반드시 악용 가능한 시스템은 아니라고 밝힙니다 ^[5][3].

CIRCL은 조사할 가치가 있는 징후를 나열합니다. 예기치 않은 워커 충돌, 비정상적인 재시작, 의심스러운 자식 프로세스, 무단 파일 변경, 예상치 못한 외부 연결입니다 ^[2]. 이는 단서일 뿐 확인된 침해 지표가 아니며, 패치한다고 해서 업데이트 이전에 심어진 지속성이 제거되지는 않습니다 ^[2].

Apache HTTP/2 취약점은 누가 발견했나요?

Apache는 2026년 10월 26일 이 결함을 보고한 Anthropic의 OSS Scanner와, 11월 3일 독립적으로 보고한 Google Cloud Vulnerability Research의 Anthony Weems와 Simon Scannell을 공로자로 밝힙니다 ^[1].

Anthropic의 발견은 내부 식별자 ANT-2026-MAPKT6MZ로 기재되어 있습니다 ^[1]. SecurityWeek는 두 보고를 독립적인 발견으로 설명합니다 ^[3]. 이는 자동화 및 AI 지원 도구가 널리 쓰이는 오픈소스 소프트웨어에서 심각한 버그를 찾아내는 또 하나의 사례입니다. 이러한 흐름이 의미하는 바는 AI That Finds Security Bugs: What Glasswing and New CVEs Mean for You에서 살펴봅니다.

수정 사항은 반영되고 2.4.71이 출시된 날은 11월 11일로, Apache가 oss-security 메일링 리스트에 이 문제를 공개한 날과 같습니다 ^[1][2].

Apache 2.4.71은 그 밖에 무엇을 수정하나요?

Apache HTTP Server 2.4.71은 총 3개의 CVE를 수정하며, 치명적 1개, 중요 1개, 낮음 1개입니다 ^[1].

• CVE-2026-106023(중요): 요청 처리 중 mod_md의 NULL 포인터 역참조로 자식 프로세스가 충돌할 수 있으며, 2.4.30부터 2.4.70까지 영향을 받습니다 ^[1].
• CVE-2026-109163(낮음): mod_vhost_alias의 1바이트 스택 버퍼 덮어쓰기로, Apache는 이를 “CVE-2026-63292 이후”라고 표기합니다(앞선 결함은 2.4.69에서 수정됨). 2.4.69와 2.4.70이 영향을 받습니다 ^[1].

직전 릴리스인 2026년 10월의 2.4.69는 CVE 20개를 수정했습니다 ^[1]. 이를 건너뛴 관리자도 2.4.71로 옮기면 그 수정 사항을 함께 받습니다. 최근의 또 다른 서버 결함은 CVE-2026-98432 Explained: The Linux TCP Flaw and How to Protect Your Servers를 참고하세요.

관리자는 앞으로 무엇을 지켜봐야 하나요?

공개된 원격 코드 실행 익스플로잇, 사용 중인 배포판의 업체 백포트, 실제 공격 보고를 지켜보세요 ^[3][5].

CIRCL은 HTTP/2가 활성화된 인스턴스의 목록을 만들고, 각 mod_http2 빌드가 영향을 받는지 확인하고, 노출된 시스템은 지체 없이 패치하되 인터넷에 직접 연결된 웹사이트, API, 공유 호스팅, HTTP/2를 전달하는 프런트엔드 뒤의 Apache 서버를 우선하라고 권고합니다 ^[2]. 의심스러운 활동을 발견한 조직은 사고 대응 절차를 따르고 자국의 CSIRT에 연락해야 합니다 ^[2].