인터넷 주소창에 사이트 주소를 치면, 저 너머 어딘가의 컴퓨터가 “여기 있어요” 하고 화면을 보내 줍니다. 이 일을 하는 프로그램을 웹서버라고 하는데, 그중 30년 가까이 세계에서 가장 오래, 가장 넓게 쓰여 온 것이 무료 공개 소프트웨어 아파치(Apache HTTP Server, 줄여서 httpd)입니다. 회사 홈페이지, 대학 사이트, 쇼핑몰, 개인 블로그, 오픈소스 미러 서버까지 정말 많은 곳에서 돌아가고 있어요.
그런데 어제(11월 11일) 아파치 개발팀이 새 버전 2.4.71을 내면서 ‘치명적(critical)’ 등급 취약점 CVE-2026-119618을 고쳤다고 밝혔습니다. 레드햇은 이 구멍에 10점 만점에 9.8점을 매겼어요. 로그인도 필요 없이, 인터넷으로 서버에 닿기만 하면 남의 명령을 실행할 수 있는 종류이기 때문입니다. 다만 조건이 하나 있습니다. HTTP/2라는 기능을 켜 둔 서버만 해당된다는 것. 오늘은 이 소식이 무슨 뜻인지, 내 서버가 해당되는지 3단계로 확인하는 법, 그리고 오늘 밤 할 일을 쉽게 정리해 보겠습니다.
한눈에 보기: 무슨 일이 있었나
| 항목 | 내용 |
|---|---|
| 대상 | 아파치 웹서버(Apache HTTP Server)의 HTTP/2 담당 부품 mod_http2 |
| 번호 | CVE-2026-119618 |
| 등급 | 아파치 개발팀 ‘critical(치명적)’, 레드햇 CVSS 9.8점 |
| 해당 버전 | 아파치 2.4.55 ~ 2.4.70 (따로 받아 쓰는 mod_h2 모듈은 2.0.8 ~ 2.0.42) |
| 고친 버전 | 아파치 2.4.71 (2026년 11월 11일 공개) |
| 조건 | HTTP/2(h2 또는 h2c)를 켜 둔 서버만. HTTP/1.1만 쓰면 해당 없음 |
| 최악의 결과 | 로그인 없이 원격에서 서버 프로그램 권한으로 명령 실행 → 서버 장악·정보 유출·서비스 중단 |
| 지금 공격 중? | 실제 공격 보고는 아직 없음(보안업체 위즈 설명). 다만 레드햇은 “공개 연구에서 안정적인 공격이 시연됐다”고 적음 |
| 발견자 | 앤트로픽의 오픈소스 스캐너(10월 26일 신고), 구글 클라우드 취약점 연구팀(11월 3일 신고) |
눈여겨볼 점은 발견자입니다. 이번 구멍을 처음 신고한 쪽이 AI 회사 앤트로픽의 자동 오픈소스 점검 도구였어요. 요즘 AI가 코드 속 버그를 사람보다 빠르게 찾아내면서, 오래된 인기 소프트웨어에서도 중요한 구멍이 연달아 나오고 있습니다. 찾는 속도가 빨라진 만큼, 고치는 쪽도 빨라야 하는 시대가 된 셈이죠.
HTTP/2가 뭐길래? 한 줄짜리 계산대 vs 여러 줄 계산대
웹서버와 브라우저가 대화하는 규칙을 HTTP라고 합니다. 예전 방식(HTTP/1.1)은 마트 계산대에 비유하면 손님이 한 줄로 서서 하나씩 계산하는 방식이었어요. 사진 50장이 있는 페이지라면 50번을 차례로 주고받아야 했죠.
HTTP/2는 한 번 연결해 놓고 여러 요청을 동시에 주고받습니다. 계산대 하나에 직원 여럿이 붙어 물건을 한꺼번에 찍는 셈이라 페이지가 훨씬 빨리 뜹니다. 그래서 요즘 많은 사이트가 HTTP/2를 켜 둡니다.
| 구분 | HTTP/1.1 | HTTP/2 |
|---|---|---|
| 비유 | 한 줄로 서서 한 명씩 계산 | 한 계산대에서 여러 물건을 동시에 계산 |
| 속도 | 요청이 많으면 느림 | 여러 요청을 한 연결로 처리해 빠름 |
| 아파치 설정 이름 | http/1.1 |
h2(HTTPS 위), h2c(암호화 없는 연결) |
| 이번 구멍과의 관계 | 해당 없음 | 켜져 있으면 해당 |
원리: 두 직원이 메모지 한 장을 같이 쓰면 생기는 일
아파치는 HTTP/2 요청 여러 개를 동시에 처리하려고 일꾼(스레드) 여러 명을 씁니다. 그런데 레드햇 설명에 따르면, 일꾼 한 명이 다른 일꾼(연결 담당)이 쓰는 메모리 공간에 ‘잠금’ 없이 끼어들어 글을 쓸 수 있는 틈이 있었어요. 아파치 개발팀 공지에서도 원인을 “공유 자원을 동시에 쓰면서 순서를 제대로 맞추지 않은 문제”라고 적었습니다.
비유하자면 두 직원이 메모지 한 장에 “누가 먼저 쓸지” 약속 없이 동시에 적는 상황입니다. 글자가 뒤엉키면 나중에 그 메모를 읽는 사람이 엉뚱한 지시를 따르게 되겠죠. 컴퓨터에서는 이것을 ‘경쟁 상태(레이스 컨디션)’, 그 결과 메모리가 망가지는 것을 ‘힙 손상’이라고 부릅니다. 공격자는 요청 타이밍을 교묘하게 맞춰 이 뒤엉킴을 일부러 만들고, 그 틈에 자기 명령을 끼워 넣을 수 있다는 것이 이번 구멍의 핵심이에요.
| 어려운 말 | 쉬운 뜻 |
|---|---|
| RCE(원격 코드 실행) | 멀리서 남의 컴퓨터에 내 명령을 실행시키는 것. 보안 구멍 중 가장 위험한 종류 |
| 인증 없이(Unauthenticated) | 아이디·비밀번호 없이도 공격 가능 |
| 레이스 컨디션 | 여러 일꾼이 같은 물건을 동시에 만지다 순서가 꼬이는 문제 |
| 힙 손상 | 프로그램이 쓰는 메모리 공간이 망가지는 것 |
| CVSS 9.8 | 취약점 위험도 점수(10점 만점). 9점 이상은 ‘매우 위험’ |
| mod_http2 | 아파치에서 HTTP/2 대화를 맡는 부품(모듈) |
내 서버, 해당될까? 3단계 확인
세 질문에 모두 “예”라면 오늘 업데이트 1순위입니다. 하나라도 “아니요”면 이번 구멍과는 거리가 멀어요(그래도 최신 버전 유지는 늘 좋습니다).
| 단계 | 질문 | 확인 방법(예시) |
|---|---|---|
| 1 | 웹서버가 아파치인가? | 리눅스 서버에서 systemctl status httpd 또는 systemctl status apache2. 엔진엑스(nginx)·IIS만 쓰면 해당 없음 |
| 2 | 버전이 2.4.55 ~ 2.4.70인가? | apachectl -v 또는 apache2 -v / httpd -v |
| 3 | HTTP/2가 켜져 있나? | 설정 파일에서 grep -Ri "Protocols" /etc/httpd /etc/apache2 로 찾아 h2·h2c가 있는지 확인. 서버 전체 설정과 각 가상호스트(VirtualHost)를 모두 볼 것 |
예를 들어 apachectl -v 결과가 Server version: Apache/2.4.70이고 설정에 Protocols h2 http/1.1이 있다면, 세 질문 모두 “예”입니다. 반대로 Apache/2.4.52처럼 2.4.55보다 낮거나, Protocols 줄에 http/1.1만 있다면 이번 구멍에는 해당되지 않아요.
한 가지 함정이 있습니다. 지난 5월 다른 HTTP/2 구멍(CVE-2026-23918) 때문에 2.4.67~2.4.70으로 서둘러 올렸던 서버도 이번에는 다시 해당된다는 점이에요. “얼마 전에 업데이트했으니 괜찮겠지”가 통하지 않는 경우입니다.
배포판마다 업데이트 상황이 다르다
아파치를 직접 내려받아 설치했다면 2.4.71로 올리면 됩니다. 하지만 대부분은 레드햇·우분투·데비안 같은 리눅스 배포판이 만든 패키지로 설치해서 씁니다. 이때는 버전 번호가 2.4.71이 아니어도 배포판이 고친 패키지를 따로 내놓기 때문에, 배포판의 보안 공지를 기준으로 봐야 해요. 11월 12일 기준으로 보도된 상황은 이렇습니다.
| 환경 | 상황(11월 12일 보도 기준) |
|---|---|
| 아파치 공식 소스 버전 | 2.4.71에서 수정 |
| 레드햇 엔터프라이즈 리눅스(RHEL) 9 | 수정 패키지 배포(mod_http2-2.0.26-7.el9_9.1). 이 버전은 구조상 공격이 훨씬 어려워 등급은 ‘Important’ |
| RHEL 10 | 수정 패키지 배포(mod_http2-2.0.29-5.el10_3.1), 등급 ‘Important’ |
| RHEL 6·7·8 | 문제 코드가 없어 해당 없음 |
| 데비안 unstable(sid) | apache2 2.4.71-1로 수정 |
| 데비안 bookworm·trixie·forky | 취약, 수정 패키지 아직 없음 |
| 아마존 리눅스 2·2023 | 수정 대기 중 |
| 우분투 | 보도 시점에 상태 안내 페이지 없음 — 우분투 보안 공지(USN)를 지켜볼 것 |
즉, “업데이트 명령을 돌렸는데 바뀐 게 없다”면 아직 배포판 패키지가 안 나온 것일 수 있어요. 이럴 때 쓰는 것이 아래의 임시 방법입니다.
당장 못 올린다면: HTTP/2 잠시 끄기
아파치 공식 공지에는 따로 우회법이 적혀 있지 않지만, 보안업체 위즈는 업데이트 전까지 설정에서 h2·h2c를 빼고 HTTP/1.1만 남기라고 권했습니다. 레드햇도 HTTP/1.1만 쓰는 서버는 해당되지 않는다고 밝혔고요.
| 바꾸기 전(예시) | 바꾼 뒤 |
|---|---|
Protocols h2 h2c http/1.1 |
Protocols http/1.1 |
가상호스트 안의 Protocols h2 http/1.1 |
그 줄도 Protocols http/1.1로 |
바꾼 뒤에는 apachectl configtest로 설정에 오타가 없는지 확인하고, systemctl reload httpd(또는 apache2)로 다시 읽게 합니다. 그다음 다른 컴퓨터에서 curl -sI --http2 https://내사이트주소를 쳐 보세요. 첫 줄이 HTTP/2가 아니라 HTTP/1.1로 나오면 꺼진 것입니다. 사이트가 조금 느려질 수는 있지만, 업데이트 전까지 문을 잠가 두는 값으로는 충분히 싸요. 업데이트를 마친 뒤 다시 켜면 됩니다.
서버가 없는 일반 사용자는?
이번 구멍은 웹사이트를 운영하는 쪽의 서버 문제입니다. 휴대폰이나 집 PC로 웹 서핑만 한다면 직접 고칠 것은 없어요. 다만 이런 분들은 한 번 챙겨 보세요.
| 이런 분이라면 | 할 일 |
|---|---|
| 호스팅·웹빌더로 쇼핑몰·홈페이지 운영 | 호스팅 업체 공지에서 “Apache 2.4.71” 또는 “CVE-2026-119618” 조치 여부 확인 |
| 집에서 NAS·라즈베리파이로 웹페이지 공개 | 제조사 업데이트 확인, 외부 공개 포트가 꼭 필요한지 점검 |
| 회사 홈페이지 담당(비전공) | 개발·외주 업체에 “아파치 버전과 HTTP/2 사용 여부” 한 줄 문의 |
| 도커 이미지로 아파치 사용 | httpd 이미지를 새 버전으로 다시 받아 컨테이너 재생성 |
| 그냥 인터넷 이용자 | 따로 할 일 없음. 다만 ‘보안 업데이트’ 사칭 메일·문자의 링크는 누르지 않기 |
오늘 밤 할 일 5가지
| 순서 | 할 일 | 걸리는 시간 |
|---|---|---|
| 1 | apachectl -v로 버전 확인 (2.4.55~2.4.70인지) |
1분 |
| 2 | 배포판 업데이트(dnf upgrade / apt update && apt upgrade)로 수정 패키지가 나왔는지 확인·설치 |
5분 |
| 3 | 아직 수정 패키지가 없으면 Protocols http/1.1로 HTTP/2 임시 끄기 |
5분 |
| 4 | apachectl configtest 후 재시작, curl --http2로 꺼졌는지 확인 |
3분 |
| 5 | 호스팅·NAS·외주를 쓰면 업체 공지 확인 또는 문의 | 5분 |
정리: 빠르게 찾아지는 시대, 빠르게 고치는 습관
이번 아파치 구멍은 “HTTP/2를 켠 2.4.55~2.4.70 서버”라는 조건이 붙지만, 조건에 맞으면 로그인 없이 서버를 통째로 내줄 수 있는 9.8점짜리 문제입니다. 아직 실제 공격 소식은 없지만, AI 도구가 패치 내용만 보고도 공격 방법을 금세 만들어 내는 요즘에는 ‘공격 보고가 없는 지금’이 가장 싸게 막을 수 있는 시간이에요.
정리하면 세 줄입니다. ① 버전 확인, ② 업데이트(안 되면 HTTP/2 잠시 끄기), ③ 업체를 쓰면 공지 확인. 내 사이트를 찾아오는 방문자를 위해, 오늘 밤 10분만 투자해 보세요.