---
title: "NGINX rewrite 모듈에서 원격 코드 실행 취약점 공개"
published: 2026-05-14T17:17:48.000Z
canonical: https://jeff.news/article/2672
---
# NGINX rewrite 모듈에서 원격 코드 실행 취약점 공개

NGINX의 ngx_http_rewrite_module에서 힙 버퍼 오버플로 취약점이 공개됐고, rewrite와 set 지시어를 쓰는 서버가 인증 없는 원격 코드 실행 위험에 노출될 수 있다는 내용이다. 영향 범위는 NGINX 오픈소스 0.6.27부터 1.30.0까지, NGINX Plus R32부터 R36까지로 제시됐고, 수정 버전도 함께 공개됐다.

- NGINX의 `ngx_http_rewrite_module`에서 원격 코드 실행(RCE) 취약점 PoC가 공개됨
  - 취약점 번호는 `CVE-2026-42945`로 제시됐고, 핵심은 힙 버퍼 오버플로(heap buffer overflow)임
  - 영향 조건은 `rewrite`와 `set` 지시어를 쓰는 서버로 설명됨
  - 테스트 환경은 Ubuntu 24.04.3 LTS였다고 밝힘

- 버그 자체는 꽤 고전적인데, 터지는 위치가 NGINX라서 무게감이 다름
  - NGINX의 스크립트 엔진은 먼저 필요한 버퍼 크기를 계산하고, 그다음 실제 데이터를 복사하는 2단계 구조를 씀
  - 문제는 `?`가 포함된 rewrite replacement에서 `is_args` 플래그가 메인 엔진에는 설정되지만, 길이 계산용 서브 엔진은 새로 초기화된 상태라 이 값을 못 본다는 점임
  - 그래서 길이 계산 단계는 원본 capture 길이만 보고, 복사 단계는 URI escaping을 적용해 일부 바이트를 3바이트로 확장함

> [!IMPORTANT]
> 한 줄로 줄이면, “작게 잡은 버퍼에 더 커진 데이터를 복사한다”는 문제임. C 기반 네트워크 서버에서 이 패턴은 그냥 위험 신호 그 자체임.

- 공격 흐름은 단순 크래시가 아니라 실행 흐름 장악까지 이어지는 것으로 설명됨
  - undersized heap buffer에 공격자가 제어하는 URI 데이터가 들어가면서 오버플로가 발생함
  - URI에는 null byte를 넣기 어렵기 때문에, POST body를 이용해 힙 배치를 조정하는 방식이 언급됨
  - 최종적으로 인접한 `ngx_pool_t`의 cleanup pointer를 오염시키고, pool destruction 시점에 `system()` 호출로 이어지게 만든다는 설명임

- 영향 버전과 수정 버전도 같이 공개됨
  - NGINX Open Source는 `0.6.27`부터 `1.30.0`까지 영향, 수정 버전은 `1.31.0`과 `1.30.1`로 제시됨
  - NGINX Plus는 `R32`부터 `R36`까지 영향, 수정 버전은 `R36 P4`, `R35 P2`, `R32 P6`로 제시됨
  - 운영 환경에서 NGINX를 패키지 매니저로만 올리는 팀은 배포판 백포트 여부까지 확인해야 함

- 흥미로운 포인트는 이 취약점 하나만 나온 게 아니라는 점임
  - 같은 보안 분석 시스템이 `CVE-2026-42946`, `CVE-2026-40701`, `CVE-2026-42934`까지 총 4개의 메모리 손상 이슈를 자동으로 찾아냈다고 주장함
  - “NGINX 소스를 온보딩하는 클릭 한 번 이후 자율적으로 발견했다”는 표현을 썼는데, 보안 분석 자동화 쪽 메시지도 꽤 강하게 깔려 있음

> [!WARNING]
> NGINX 앞단 설정에 `rewrite`나 `set`이 들어가 있다면 그냥 “언젠가 봐야지” 급이 아님. 공개 PoC가 붙은 RCE라 패치와 노출면 확인을 먼저 해야 하는 케이스임.

- 한국 개발자 입장에서도 꽤 직접적인 이슈임
  - NGINX는 API 게이트웨이, 리버스 프록시, 정적 파일 서빙, Kubernetes ingress 앞단 등에서 너무 흔하게 쓰임
  - 특히 오래된 VM 이미지나 appliance, 사내 표준 베이스 이미지에 묶인 NGINX는 버전이 늦게 올라가는 경우가 많음
  - rewrite 규칙은 레거시 URL 호환 때문에 오래 남아있는 일이 많아서, “우린 단순 프록시라 괜찮겠지” 하고 넘기기 애매함

---

## 기술 맥락

- 이번 이슈의 핵심은 길이 계산과 실제 복사가 같은 세계를 보고 있지 않았다는 점이에요. 네트워크 서버에서는 입력을 복사하기 전에 버퍼 크기를 먼저 잡는데, 이때 escaping이나 인코딩 때문에 데이터 길이가 바뀌면 계산 단계와 복사 단계가 반드시 같은 조건을 공유해야 하거든요.

- NGINX의 rewrite 엔진은 성능이 중요한 C 코드 경로라서 이런 2-pass 구조를 쓰기 쉬워요. 먼저 필요한 크기만 빠르게 계산하고, 그다음 실제 데이터를 채우는 방식인데, 플래그 하나가 서브 엔진에서 빠지면 “계산한 크기”와 “실제 필요한 크기”가 갈라져요.

- 운영팀 관점에서는 취약점 이름보다 설정 조건이 더 중요해요. 이 글에서는 `rewrite`와 `set` 지시어 사용이 조건으로 나오기 때문에, 단순히 NGINX 버전만 볼 게 아니라 배포된 설정 파일에서 해당 지시어가 어디에 쓰이는지 같이 봐야 해요.

- 보안팀 입장에서는 공개 PoC가 있다는 점이 우선순위를 바꿔요. 메모리 손상 취약점은 재현 난도가 높을 때도 많지만, 여기서는 공격 경로와 영향 버전, 수정 버전이 같이 제시됐기 때문에 패치 검증과 노출 서비스 식별을 병렬로 진행하는 게 맞아요.

## 핵심 포인트

- 취약점은 2008년에 들어간 ngx_http_rewrite_module의 힙 버퍼 오버플로로 설명됨
- rewrite 대체 문자열에 물음표가 들어갈 때 길이 계산과 실제 복사 단계의 escaping 동작이 달라지는 게 핵심
- NGINX 오픈소스는 1.31.0 또는 1.30.1, NGINX Plus는 R36 P4, R35 P2, R32 P6에서 수정됐다고 제시됨
- 같은 분석 시스템이 CVE-2026-42945 외에도 메모리 손상 취약점 3개를 추가로 찾았다고 주장함

## 인사이트

NGINX처럼 오래되고 널리 쓰이는 C 기반 인프라에서도 ‘길이 계산과 복사 로직이 완전히 같은 조건을 보느냐’ 같은 고전적인 문제가 여전히 치명타가 될 수 있다는 사례다. 한국 서비스들도 리버스 프록시나 게이트웨이 앞단에서 NGINX를 많이 쓰니, rewrite 설정이 있는 환경은 패치 우선순위를 꽤 높게 잡아야 할 이슈다.