보안이슈#4. Nginx 메모리 취약점

최근 국내 정보보안 전문 매체 보안뉴스와 The Hacker News 는 전 세계 웹 서버 시장의 핵심 소프트웨어인 NGINX에서 복수의 취약점이 공개됐다고 보도했다.

이 취약점은 단순한 보안 패치 권고 이상의 의미를 가진다. 전 세계 웹 서버 시장의 핵심 소프트웨어인 NGINX에서 무려 18년간 발견되지 않은 취약점이 공개된 직후, 실제 공격에 악용되기 시작했기 때문이다.

 

F5 내부 연구팀 depthfirst가 발견한 두 취약점은 NGINX Plus와 NGINX Open Source 모두에 영향을 미치며, 조건에 따라 원격 코드 실행(RCE)까지 이어질 수 있다.

특히 CVE-2026-42945는 공개 시점 기준 CVSS 9.2점(Critical)으로 평가됐고, 취약한 코드가 2008년에 처음 도입된 것으로 확인됐다.

 

 

언급된 두 취약점의 기술적 원리와 이번 사례가 가지는 보안적 시사점을 살펴본다.

 

 

CVE-2026-42945 — NGINX Rift: 힙 버퍼 오버플로우와 RCE  

이 취약점은 URL 재작성을 담당하는 ngx_http_rewrite_module에서 발생하는 힙 버퍼 오버플로우(Heap Buffer Overflow)다.

영향받는 버전은 NGINX 0.6.27부터 1.30.0까지로, 공격자는 인증 없이 조작된 HTTP 요청 하나만으로 워커 프로세스를 충돌시키거나 원격 코드를 실행(RCE)할 수 있다.

 

힙 버퍼 오버플로우는 동적으로 할당된 힙 메모리 영역에서 버퍼 경계를 초과해 데이터를 쓰는 취약점이다.

인접한 힙 청크의 메타데이터가 오염되면 메모리 관리 구조 자체를 조작할 수 있어, 조건이 갖춰질 경우 공격자가 임의 코드 실행 권한을 얻게 된다.

 

ASLR(주소 공간 배치 난수화)이 비활성화된 환경에서는 공격자가 메모리 주소를 예측할 수 있어 RCE 성공 가능성이 높아진다.

기본 설정된 서버라면 ASLR이 활성화돼 있지만, 특정 레거시 환경이나 컨테이너 설정에서는 비활성화 상태일 수 있다.

단, DoS(워커 프로세스 충돌)는 이러한 조건 없이도 충분히 실현 가능하다.

 

CVE-2026-42945 공격 흐름 — DoS는 조건 없이 가능, RCE는 ASLR 비활성화 환경에서 성립

 

 

 

힙 버퍼 오버플로우가 RCE로 이어지는 과정을 메모리 관점에서 살펴보면 아래와 같다.

 

힙 버퍼 오버플로우 — 인접 청크 메타데이터를 오염시켜 포인터 조작으로 이어진다

 

CVE-2026-42946 — SCGI · uwsgi 모듈의 메모리 취약점

두 번째 취약점은 NGINX가 백엔드 애플리케이션 서버와 통신할 때 사용하는 SCGI 및 uwsgi 모듈에서 발생하는 경계 밖 메모리 접근(Out-of-Bounds) 문제다. 

SSL과 Charset 모듈에서도 유사한 패턴이 추가로 확인됐으며, 프로세스 비정상 종료 또는 메모리 정보 유출로 이어질 수 있다.

 

CVE-2026-42946 영향 범위 — 4개 모듈에서 발생하는 메모리 취약점과 결과

 

실제 공격 현황 (Exploit)

공개 시점으로부터 수일 만에 VulnCheck는 자사 허니팟 네트워크에서 CVE-2026-42945를 무기화한 공격 시도를 탐지했다.

현재까지 확인된 공격 특징은 다음과 같다.

 

1. 공격 출발지 — 중국 IP 단일 클러스터
현재까지 탐지된 공격 활동은 단일 중국 IP 주소에서 발생하고 있다.
공격의 최종 목적은 아직 완전히 파악되지 않은 상태다.

2. AI 기반 취약점 탐색 자동화
VulnCheck VP Caitlin Condon에 따르면, 공격자는 AI 취약점 탐색 도구인 Vulnhuntr의 커스터마이즈된 구현체를 활용해 취약한 NGINX 설치 환경을 자동으로 스캔하는 것으로 분석됐다.

3. PHP 웹셸 드롭 시도
취약한 서버를 탐지한 후 PHP 웹셸을 삽입하려는 시도가 확인됐다.
웹셸은 공격자가 서버에 지속적인 원격 접근권을 확보하는 데 사용된다.

 

패치 정보 및 권장 버전

 

영향 제품 : NGINX Plus / Open Source

제품	취약 버전	패치 버전	권고 사항
NGINX Open Source	1.30.0 이하	1.30.1 이상	즉시 업데이트
NGINX Plus	R32 P5 이하	R32 P6 이상	즉시 업데이트

✅ 패치 적용 명령 (Linux 예시)

• 버전 확인: nginx -v
• 패키지 업데이트: sudo dnf update nginx (RHEL/Rocky) 또는 sudo apt upgrade nginx (Debian/Ubuntu)
• 업데이트 후 재시작: sudo systemctl restart nginx

 

시사점

1️⃣ 공개 → 무기화 사이클의 단축 

CVE-2026-42945는 공개 후 수일 만에 실제 공격에 활용됐다.

AI 기반 자동화 도구(Vulnhuntr 등)의 등장으로 취약점 공개와 익스플로잇 사이의 간격이 급격히 줄고 있다.

패치 출시 즉시 적용하는 체계가 없다면 위험에 무방비로 노출된다.

 

2️⃣ 검증된 코드라고 해서 안전한 코드가 아니다.

NGINX는 세계에서 가장 많이 감사된 오픈소스 소프트웨어 중 하나다.

그럼에도 힙 버퍼 오버플로우가 2008년부터 2026년까지 존재했다는 사실은 코드 심층 분석과 퍼징(fuzzing) 기반 취약점 탐색의 필요성을 다시 상기시킨다.

 

3️⃣ ASLR 같은 완화 기법의 실효성

RCE 조건이 ASLR 비활성화를 요구한다는 점은 시스템 수준 방어 기법이 실제로 작동하고 있음을 보여준다.

Defense in Depth(심층 방어) 전략이 실제로 유효하다는 것을 증명한다.

 

4️⃣ 공급망 전체 점검의 필요성

내가 직접 설치한 NGINX뿐 아니라, 사용 중인 솔루션이나 컨테이너 이미지 안에 포함된 NGINX 버전까지 확인이 필요하다. 

docker inspect나 SBOM(소프트웨어 자재 명세서) 기반 점검 도구 활용을 권장한다.

 

https://www.boannews.com/media/view.asp?idx=143669

18년 숨어있던 NGINX 치명적 결함 발견 “인증 없이 서버 장악 가능”

 

https://thehackernews.com/2026/05/nginx-cve-2026-42945-exploited-in-wild.html

NGINX CVE-2026-42945 Exploited in the Wild, Causing Worker Crashes and Possible RCE