NGINX HTTP/3·HTTP/2 동시 패치: CVE-2026-42530·42055 분석

이 글은 2026년 6월 NGINX가 동시에 패치한 두 개의 Critical 취약점을 분석한다. CVSS 9.2라는 숫자 뒤에 숨은 실제 위험도와 대응 우선순위를 따져본다.

들어가며

KISA 보안 공지에 NGINX 권고가 올라온 걸 보고 내 서버부터 확인했다. CVSS 9.2 Critical이라는 숫자가 먼저 눈에 들어왔고 NGINX는 거의 모든 인프라의 최전선에 깔려 있는 물건이라 무시하기 어려웠다. 그런데 공지를 뜯어보니 KISA 글은 HTTP/3 취약점 하나(CVE-2026-42530)만 다루고 있었다. F5 원본 advisory와 NGINX 릴리스 노트를 대조해 보니 같은 1.31.2 릴리스에서 Critical 두 건이 함께 막혔다. 둘 다 9.2점인데 성격이 꽤 다르다. 이 글은 그 두 건을 묶어서 정리한다.

한눈에 보는 두 취약점

6월 17일 NGINX 1.31.2 릴리스가 동시에 막은 Critical은 두 개다. 둘 다 원격·비인증 공격자가 워커 프로세스를 죽일 수 있고 특정 조건에서 코드 실행으로 번질 수 있다.

핵심 차이는 영향 범위다. HTTP/3 건은 최근 버전대(1.31.0~1.31.1)에 한정되지만 HTTP/2 프록시 건은 1.13.10부터 무려 수년치 버전이 걸린다. 대신 발동 조건은 HTTP/2 쪽이 훨씬 까다롭다.

CVE-2026-42530 — HTTP/3 QUIC의 Use-After-Free

HTTP/3 세션이 짧게 살았다 사라지는 스트림의 메모리를 계속 가리키는 lifetime mismatch가 원인이다. 공격자는 특수 제작한 HTTP/3 세션으로 QPACK 인코더 스트림을 재개방해 이 결함을 건드린다.

조금 더 풀어보면 이렇다. HTTP/3에서 QPACK 인코더 스트림은 단방향(unidirectional) 스트림으로, 잠깐 열렸다 닫히는 짧은 수명을 가진다. 그런데 이 스트림이 쓰던 메모리를 세션 레벨 포인터가 붙들고 있다. 스트림이 닫히면 메모리는 해제(free)되지만, 세션 포인터는 여전히 그 주소를 유효한 것처럼 들고 있다. 공격자가 닫힌 인코더 스트림을 다시 열도록 유도하면 해제된 메모리를 다시 참조하는 Use-After-Free가 발생한다.

sequenceDiagram
    participant A as 공격자
    participant S as NGINX HTTP/3 세션
    participant M as QPACK 인코더 스트림(단방향)
    A->>S: HTTP/3 세션 수립
    S->>M: 인코더 스트림 생성 (짧은 수명)
    M-->>S: 세션 포인터가 스트림 메모리 참조
    M->>M: 스트림 종료 → 메모리 free()
    Note over S: 세션 포인터는 해제된 주소를 그대로 보유
    A->>S: QPACK 인코더 스트림 재개방 유도
    S->>M: 해제된 메모리 재참조 (Use-After-Free)
    Note over S: 워커 프로세스 크래시 → 재시작

결과는 워커 프로세스 크래시와 재시작이다. ASLR이 꺼져 있거나 우회 가능한 환경이라면 메모리 손상을 코드 실행으로 끌고 갈 여지가 생긴다. 다만 이 취약점은 HTTP/3가 켜져 있을 때만 의미가 있다. NGINX에서 HTTP/3는 기본 비활성이라, listen 지시자에 quic을 명시하지 않았다면 해당되지 않는다.

CVE-2026-42055 — HTTP/2 프록시 경로의 Heap 오버플로우

NGINX가 업스트림으로 HTTP/2나 gRPC를 프록시할 때, 과도하게 큰 헤더가 heap 버퍼 오버플로우를 일으킨다. 다만 발동 조건이 셋이나 겹쳐야 한다.

다음 세 가지가 동시에 맞을 때만 트리거된다.

1. proxy_http_version 2 또는 grpc_pass로 HTTP/2·gRPC를 업스트림 프록시
2. ignore_invalid_headers off 설정
3. large_client_header_buffers 크기가 2MB 초과

이 조합이 맞으면 공격자가 큰 헤더를 보내 업스트림 요청을 만들 때 워커 프로세스의 heap에서 오버플로우가 발생한다. 영향은 HTTP/3 건과 동일하게 워커 재시작(DoS)이 1차이고 ASLR 조건이 무력화된 경우 코드 실행 가능성이 따라온다.

눈여겨볼 부분은 영향 버전이다. 1.13.10 ~ 1.31.1로 범위가 매우 넓다. 오래된 NGINX를 쓰고 있어도 위 설정 조합만 아니면 트리거되지 않지만 반대로 해당 설정을 쓰는 환경이라면 수년치 버전이 전부 사정권이다.

9.2인데 왜 패닉 수준은 아닌가

CVSS v4.0 9.2는 분명 Critical이지만 점수를 액면 그대로 받아들이면 위험도를 과대평가하게 된다. 세 가지를 같이 봐야 한다.

• 1차 영향은 RCE가 아니라 DoS다. 두 취약점 모두 즉각적인 결과는 워커 프로세스 크래시와 재시작이다. NGINX는 워커가 죽어도 마스터가 재기동하므로 서비스가 완전히 멈추지는 않는다.
• RCE는 ASLR 조건부다. 코드 실행은 ASLR이 비활성화됐거나 공격자가 ASLR을 우회할 수 있을 때만 성립한다. 현대 리눅스 배포판은 ASLR이 기본 활성이라 실전 난이도가 높다. CVSS v3.1 점수가 9점대가 아니라 8.1로 낮게 나온 것도 공격 복잡도(AC
  )가 반영된 결과다.
• 실제 악용 정황이 없다. 공개된 exploit이나 IOC가 없고, EPSS 점수도 1% 미만이라 악용 확률은 낮게 평가된다.

정리하면 "터지면 치명적이지만, 터뜨리기 위한 조건이 까다롭다"는 전형적인 메모리 손상 취약점이다. 그렇다고 방치할 이유는 없다. 조건이 까다로울 뿐 원격·비인증이라는 점은 변하지 않는다.

내 서버가 취약한지 확인하기

버전과 설정 두 가지를 본다. 먼저 NGINX 버전이 영향 범위에 드는지 확인한다.

nginx -v
# nginx version: nginx/1.31.1 → 영향받음

다음으로 HTTP/3(QUIC)와 HTTP/2 업스트림 프록시 설정을 점검한다. 설정 파일에서 관련 지시자를 한 번에 훑는다.

# HTTP/3 QUIC 리스너 사용 여부 (CVE-2026-42530)
grep -rE "listen.*quic|http3" /etc/nginx/

# HTTP/2 업스트림 프록시 + 위험 설정 조합 (CVE-2026-42055)
grep -rE "proxy_http_version\s+2|grpc_pass|ignore_invalid_headers|large_client_header_buffers" /etc/nginx/

quic 리스너가 없고 HTTP/2 프록시 조건 조합도 쓰지 않는다면, 영향 버전이라도 실제 트리거 경로는 닫혀 있다. 그래도 근본 해결은 패치다.

대응 방법

가장 확실한 조치는 1.31.2 이상으로 올리는 것이다. 한 번의 업그레이드로 두 Critical을 동시에 해결한다.

sudo apt update
sudo apt install --only-upgrade nginx
nginx -v   # 1.31.2 이상 확인

sudo dnf upgrade nginx
nginx -v   # 1.31.2 이상 확인

brew upgrade nginx
nginx -v   # 1.31.2 이상 확인

즉시 패치가 어렵다면 임시 완화책으로 트리거 경로를 닫는다. 영구 해결책은 아니므로 패치 전까지의 가교로만 쓴다.

• CVE-2026-42530: listen 지시자에서 quic 파라미터를 제거하고 http3 on;을 끈 뒤 설정을 리로드한다.
• CVE-2026-42055: 세 발동 조건 중 하나를 정상값으로 되돌린다. 특히 large_client_header_buffers 크기를 2MB 이하로 낮추는 것이 가장 간단하다.

# 설정 문법 검증 후 무중단 리로드
sudo nginx -t && sudo nginx -s reload

정리

NGINX 1.31.2는 성격이 다른 Critical 두 건을 한 번에 막았다. 핵심을 표로 정리하면 다음과 같다.

CVSS 9.2라는 숫자에 끌려가기보다 내 환경이 트리거 조건에 해당하는지부터 확인하는 게 먼저다. HTTP/3나 HTTP/2 업스트림 프록시를 쓰는 노출 서버라면 우선순위를 높여 패치하고, 아니라면 정기 업데이트 주기에 맞춰 1.31.2로 올려두면 된다.

참고자료

• F5 K000161616 — CVE-2026-42530 (NGINX ngx_http_v3_module)
• F5 K000161584 — CVE-2026-42055 (ngx_http_proxy_v2_module, ngx_http_grpc_module)
• NVD — CVE-2026-42530
• nginx 공식 보안 권고
• The Hacker News — F5 Patches Two Critical NGINX Open Source Flaws
• SOC Prime — CVE-2026-42530 분석