NGINX rewrite 모듈에서 원격 코드 실행 취약점 공개

• 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바이트로 확장함

• 공격 흐름은 단순 크래시가 아니라 실행 흐름 장악까지 이어지는 것으로 설명됨

  • 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 소스를 온보딩하는 클릭 한 번 이후 자율적으로 발견했다”는 표현을 썼는데, 보안 분석 자동화 쪽 메시지도 꽤 강하게 깔려 있음

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

---

기술 맥락

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

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

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

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