[2026-05-20] NGINX 치명적 결함 발견

 

 

 

오늘의 뉴스클리핑의 이슈는 바로 NGINX 치명적 결함 발견 입니다 - !

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

NGINX 치명적 결함 발견

 

최근 발견된 NGINX의 심각한 힙 버퍼 오버플로우 취약점인 CVE-2026-42945(일명 NGINX Rift)는 무려 18년 동안 코드베이스에 잠복해 있던 것으로 확인되었다. 이 취약점은 NGINX Open Source 및 NGINX Plus의 ngx_http_rewrite_module에서 발생하며, 공격자는 별도의 인증 절차 없이 특수하게 조작된 HTTP 요청을 보내 서버에 서비스 거부(DoS) 상태를 유발할 수 있다. 특히 시스템의 주소 공간 레이아웃 임의화(ASLR) 기능이 비활성화된 환경이라면 원격 코드 실행(RCE)을 통해 서버 제어권까지 장악할 수 있어 매우 치명적이다. 해당 취약점은 F5와 연구팀 뎁스퍼스트(depthfirst)에 의해 공개된 후 NGINX Open Source 1.30.1 및 NGINX Plus R32 P6 이상 버전에서 3종의 추가 메모리 관련 취약점과 함께 즉각 패치되었으며, 즉각적인 업데이트가 어려운 경우에는 리라이트(Rewrite) 설정의 캡처 방식을 변경하는 임시 조치를 취해야 한다.

 

NGINX
1) 웹 서버 소프트웨어로, 웹사이트 콘텐츠를 사용자에게 전달하는 역할
2) 단순 웹 서버 외에도 리버스 프록시(서버 앞단에서 요청을 대신 받아 전달), 로드 밸런서(트래픽 분산), API 게이트웨이 등으로 폭넓게 활용
3) 현재 전 세계 웹 서버 중 가장 높은 점유율을 차지

ngx_http_rewrite_module 
1) NGINX에 기본 내장된 모듈로, HTTP 요청의 URL을 변환하거나 리다이렉트하는 기능을 담당
2) rewrite, if, set 같은 디렉티브(설정 지시어)를 제공하며, 예를 들어 http://로 들어온 요청을 https://로 자동 전환하거나, 구 URL을 새 URL로 연결하는 데 사용됨

3) API 라우팅이나 레거시 시스템 마이그레이션에서도 흔히 쓰이는 만큼, 거의 모든 NGINX 서버에 활성화되어 있음

 

 

 

 

 

 

 

 

 

 

취약점 분석

NGINX의 스크립트 엔진은 rewrite·set 디렉티브를 컴파일한 뒤, 길이를 계산하고 복사하는 방식으로 실행합니다.

 

rewrite 치환 문자열에 물음표(?)가 포함되면, ngx_http_script_start_args_code 함수가 메인 엔진의 e->is_args를 1로 설정합니다. 핵심 문제는 이 플래그가 이후 리셋되지 않는다는 점입니다.

 

뒤이어 set 디렉티브가 캡처 그룹을 참조하면 ngx_http_script_complex_value_code 함수가 호출됩니다. 이 함수는 길이 계산 시 ngx_memzero로 초기화된 별도의 서브 엔진(le)을 사용합니다. 따라서 le.is_args = 0 상태에서는 URI 이스케이프 없이 원시 캡처 길이만 반환합니다. 반면 복사 패스에서는 메인 엔진의 e->is_args = 1이 그대로 유지되어, ngx_escape_uri가 +, %, & 등의 문자를 각각 3바이트로 확장합니다.

 

결과적으로 raw_size만큼 할당된 버퍼에 raw_size + 2*N 바이트가 기록되면서 힙 오버플로우가 발생합니다.

 

⚠️ WARN 트리거 조건은 rewrite 치환에 ?가 포함되고, 이후 set·if·rewrite에서 unnamed PCRE 캡처를 참조하는 구성입니다. 이 패턴은 API 라우팅이나 레거시 마이그레이션에서 흔히 사용되므로, 설정 파일 전수 점검이 필요합니다.

 

취약한 설정 예시와 패치 전후의 핵심 로직은 다음과 같습니다.

 

# [트리거 설정 예시]
location ~ ^/api/(.*)$ {
    rewrite ^/api/(.*)$ /internal?migrated=true;
    set $original_endpoint $1;
}

 

/* [패치 전] src/http/ngx_http_script.c ngx_http_script_complex_value_code() */
ngx_memzero(&le, sizeof(ngx_http_script_engine_t));
/* le.is_args = 0, 길이 계산 시 이스케이프 미적용 */

 

/* [패치 후] 서브 엔진 le에 메인 엔진의 is_args·quote 상태 전파 */
le.is_args = e->is_args;
le.quote   = e->quote;
/* 길이 계산 시에도 동일한 이스케이프가 적용되어 버퍼 크기 불일치를 해소 */

 

 

 

 

 

 

 

공격 과정

공격은 특정 조건을 갖춘 취약한 서버 설정을 파악하는 것에서 시작된다. NGINX 서버의 설정 파일 내 ngx_http_rewrite_module 구성에서 명명되지 않은 PCRE 정규표현식 캡처를 사용하고 치환 문자열에 물음표가 포함되어 있으며 직후에 rewrite, if, set 지시어가 연속으로 사용된 패턴이 존재할 때 취약점이 활성화된다. 공격자는 이러한 환경을 대상으로 사전 인증이나 권한 획득 과정 없이 악의적으로 조작된 URI 데이터가 포함된 HTTP 요청을 전송한다. 이후 NGINX가 수신된 URI를 처리하기 위해 메모리를 할당할 때 대상 버퍼 크기를 계산하는 이스케이프 기준과 실제 메모리에 데이터를 기록할 때 적용하는 이스케이프 기준 간에 상태 불일치가 발생하게 된다. 이로 인해 NGINX는 실제로 할당된 힙 버퍼의 경계를 초과하여 공격자가 전송한 URI 데이터를 기록하는 힙 버퍼 오버플로우를 일으킨다. 그 결과 버퍼 오버플로우로 인해 할당 범위를 벗어난 메모리가 손상되면 NGINX 워커 프로세스가 비정상 종료와 재시작 루프를 반복하며 합법적인 트래픽 처리가 불가능해지는 서비스 거부(DoS) 상태가 발생한다. 더 나아가 운영체제의 메모리 방어 기법인 ASLR이 비활성화되어 있거나 공격자가 특정 메모리 레이아웃 조건을 충족하는 경우, 힙 메모리의 오버플로우 데이터를 정교하게 조작하여 메모리 상에서 임의의 악성 명령어를 실행하고 서버의 권한을 획득하는 원격 코드 실행(RCE)으로 이어지게 된다.

힙 버퍼 오버플로우 (Heap Buffer Overflow)
1) 프로그램이 힙 영역(프로그램 실행 중 동적으로 할당하는 메모리 공간)에 미리 확보해 둔 크기보다 더 많은 데이터를 써 넣는 오류
2) 책상 위에 A4 한 장 크기의 공간만 준비했는데 A3 용지를 억지로 올려놓는 것처럼, 초과된 데이터가 인접한 메모리 영역을 덮어씀
3) 공격자는 이를 이용해 프로그램을 강제 종료(DoS)시키거나, 조건이 맞으면 임의의 코드를 실행(RCE)할 수 있음

ASLR (Address Space Layout Randomization, 주소 공간 레이아웃 임의화)
1) 운영체제가 프로그램을 실행할 때마다 코드·힙·스택 등 주요 메모리 영역의 주소를 무작위로 배치하는 보안 기술2) 공격자가 버퍼 오버플로우를 일으켜도 다음 코드가 어디에 있는지를 예측할 수 없게 만들어 익스플로잇을 어렵게함
3) 현대 리눅스 배포판은 ASLR을 기본 활성화

정규 표현식 캡처 (Regular Expression Capture)
1) 정규 표현식에서 괄호 ()로 묶인 부분이 일치한 문자열을 따로 저장해 두는 기능
2) /api/users/123에 정규 표현식 ^/api/users/(.*)$를 적용하면 123이 캡처
3) NGINX에서는 이렇게 캡처된 값을 $1, $2 같은 번호로 참조하는데, 이를 미명명 캡처(unnamed capture) 
4) CVE-2026-42945는 바로 이 $1, $2를 rewrite 디렉티브에서 물음표(?)와 함께 사용할 때 버퍼 크기 계산 오류가 발생하는 구조
5) (?P<name>...)처럼 이름을 붙이는 명명된 캡처(named capture) 방식은 이 취약점의 영향을 받지 않아 임시 완화책으로 권장

 

 

 

 

 

 

시사점

이번 취약점 사태는 전 세계에서 가장 널리 사용되는 핵심 인터넷 인프라 소프트웨어라 하더라도 무려 18년이라는 긴 시간 동안 발견되지 않은 치명적인 결함이 코드베이스 내에 존재할 수 있음을 명확히 증명한다. 이는 오픈소스 생태계 전반에 걸친 지속적이고 철저한 코드 보안 감사의 필요성을 다시 한번 부각시킨다. 또한 웹 서버, 리버스 프록시, 로드 밸런서로서 인터넷과 내부 망의 경계에 위치하는 NGINX의 특성상 인증이 필요 없는 원격 공격이 가능하다는 점은 매우 큰 위협이다. 공격자가 네트워크 내부로 침투하지 않고도 외부에서 자동화된 스캐너만을 이용해 광범위하게 시스템을 공격할 수 있는 대규모 노출 면적을 제공하기 때문이다. 마지막으로 이 취약점이 실제 서버 권한 장악으로 직결되는 과정에서 ASLR의 비활성화 여부가 결정적인 조건으로 작용했다는 점은 애플리케이션 단의 패치뿐만 아니라 운영체제 레벨의 메모리 보호 완화 기술을 기본적으로 적용하고 유지하는 것이 방어에 얼마나 핵심적인 요소인지를 시사한다.

 

 

 

 

 

 

개인 의견

이번 NGINX Rift 취약점 사태는 글로벌 인프라 소프트웨어에 대한 높은 의존성이 가져올 수 있는 연쇄적인 보안 리스크를 단적으로 보여주는 중요한 사례라고 생각합니다. 웹 서버 및 리버스 프록시 계층에서 발생하는 인증 우회 취약점은 단순히 단일 애플리케이션의 문제를 넘어 그와 연결된 전체 백엔드 시스템 인프라에 대한 물리적 제어권을 위협하는 심각한 상황으로 직결된다. 가장 이상적이고 확실한 대응은 벤더사가 제공하는 공식 버전 업데이트를 즉시 적용하는 것이지만, 실제 엔터프라이즈 환경에서는 가용성 유지나 다운타임 최소화 및 시스템 호환성 문제로 인해 즉각적인 패치 적용이 지연되는 경우가 빈번하다. 따라서 최우선적으로 시스템 설정 파일 내 명명되지 않은 캡처 방식을 명명된 캡처 방식으로 수정하는 임시 대응을 시스템 전반에 신속히 배포해야 한다. 이와 동시에 웹 애플리케이션 방화벽(WAF)이나 침입 방지 시스템(IPS)의 탐지 시그니처를 즉각 업데이트하여 비정상적으로 긴 URI나 rewrite 모듈을 타겟으로 하는 특수 문자열 패턴의 유입을 모니터링하고 차단하는 다계층 방어 전략이 필수적으로 병행되어야 한다. 더불어 기업 내부 인프라 설정 파일에 대한 정기적인 보안 구성 검토 프로세스를 시스템화하는 것만이 향후 유사한 사고를 예방하는 근본적인 방안이 될 것이다.

 

 

기사출처 : https://m.boannews.com/html/detail.html?idx=143669

 

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