# NGINX Rift - 새로운 NGINX 익스플로잇 > Clean Markdown view of GeekNews topic #29537. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=29537](https://news.hada.io/topic?id=29537) - GeekNews Markdown: [https://news.hada.io/topic/29537.md](https://news.hada.io/topic/29537.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-05-15T14:34:39+09:00 - Updated: 2026-05-15T14:34:39+09:00 - Original source: [github.com/DepthFirstDisclosures](https://github.com/DepthFirstDisclosures/Nginx-Rift) - Points: 1 - Comments: 1 ## Topic Body - **NGINX Rift**는 NGINX `ngx_http_rewrite_module`의 치명적 힙 버퍼 오버플로인 **CVE-2026-42945**에 대한 원격 코드 실행 PoC임 - 이 취약점은 `rewrite`와 `set` 지시어를 사용하는 서버에서 **인증 없는 원격 코드 실행**을 가능하게 함 - 문제는 2008년에 도입된 버그로, NGINX 스크립트 엔진의 **길이 계산 패스**와 **복사 패스**가 `is_args` 플래그를 다르게 처리하면서 발생함 - `rewrite` 치환 문자열에 `?`가 있으면 메인 엔진에는 `is_args`가 설정되지만, 길이 계산은 새로 0으로 초기화된 서브 엔진에서 실행되어 원본 캡처 길이만 반환함 - 복사 단계에서는 `is_args = 1` 상태로 `ngx_escape_uri`와 `NGX_ESCAPE_ARGS`가 호출되어 이스케이프 가능한 각 바이트가 3바이트로 확장되고, 과소 할당된 힙 버퍼를 공격자 제어 URI 데이터로 넘치게 만듦 - 익스플로잇은 요청 간 **힙 풍수(heap feng shui)** 를 사용해 인접한 `ngx_pool_t`의 `cleanup` 포인터를 오염시키며, URI 바이트에 null 바이트를 넣을 수 없어 POST 본문을 통해 스프레이함 - 오염된 포인터는 가짜 `ngx_pool_cleanup_s`로 리다이렉트되고, 풀 파괴 시 `system()`을 호출하도록 구성됨 - CVE-2026-42945와 함께 CVE-2026-42946, CVE-2026-40701, CVE-2026-42934 등 3개의 메모리 손상 이슈도 [depthfirst](https://depthfirst.com)의 보안 분석 시스템이 NGINX 소스 온보딩 한 번으로 자율 발견함 - 영향을 받는 버전은 **NGINX Open Source 0.6.27–1.30.0** 및 **NGINX Plus R32–R36**이며, 수정 버전은 Open Source 1.31.0/1.30.1, Plus R36 P4/R35 P2/R32 P6로 제시됨 - 전체 벤더 권고는 에 있으며, 기술 상세는 [technical write-up](https://depthfirst.com/research/nginx-rift-achieving-nginx-rce-via-an-18-year-old-vulnerability)에서 다룸 - PoC는 Ubuntu 24.04.3 LTS에서 테스트되었고, `./setup.sh`, `docker compose -f env/docker-compose.yml up`, `python3 poc.py --shell` 순서로 취약 NGINX 컨테이너를 띄우고 셸을 실행하는 흐름을 제공함 ## Comments ### Comment 57545 - Author: neo - Created: 2026-05-15T14:34:40+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48138268) - 보안 담당자로서, 공개된 익스플로잇이 **ASLR 우회**를 하지 않는다는 이유로 이 문제가 훨씬 덜 무섭다고 단정하거나 암시하는 반응이 너무 많아 피곤함 원문은 이 공격으로 ASLR을 안정적으로 우회할 방법이 있다고 주장하고, 증거가 없어도 기본 가정으로 믿을 만하다고 봄 ASLR은 익스플로잇을 어렵게 만드는 **심층 방어** 기법일 뿐이고, 대부분의 경우 시간과 실력이 있으면 ASLR 우회가 붙게 됨 LLM 에이전트 때문에 그 시간과 실력의 장벽도 몇 주마다 낮아지고 있어, 완전히 무기화된 익스플로잇이 나오는 건 시간문제이며 공개될 수도, 비공개로 남을 수도 있음 “ASLR을 켰으면 위험하지 않다”는 말은 명백히 틀렸고, 그런 말을 믿는 사람에게 매우 해롭다 완화 기법이 익스플로잇을 어렵게 만들 수 있으니 보안 취약점을 신경 쓰지 않아도 된다는 잘못된 믿음은 이미 과거에 많은 피해를 냈음 현대적 완화 기법이 있다는 건 다행이지만 최대한 빨리 패치해야 하며, 벤더라면 연구자가 ASLR 우회를 제시하지 않았다고 취약점 보고를 무효로 취급하지 말고 근본 원인을 고쳐야 함 - 원격에서 접근 가능한 취약점은 가볍게 보면 안 됨 다만 현재로서는 전제 조건이 좀 특이해 보임 10년 동안 여러 구성으로 nginx를 써 왔지만 `rewrite`와 `set`을 함께 쓴 적은 한 번도 없음 - “AI가 사이버를 해결할 것”이라고 말하는 사람들과, “ASLR 켰으면 괜찮다”고 말하는 사람들은 **1:1로 겹친다**고 봐도 안전함 그리고 꼭 “cyber”라고 말함 - 이 관점에는 동의하지 않거나, 적어도 다르게 표현하고 싶음 ASLR은 맞춰야 하는 추가 비밀번호와 비슷하고, 일정한 **엔트로피**를 가지며 보통 안정적임 취약점에 정보 누출 부분이 없다면 ASLR은 그 취약점을 완전히 완화하거나, 아니면 두 번째 취약점이 필요함 그건 다른 논의임 ASLR은 개별 취약점은 완전히 완화할 수 있지만, 익스플로잇 체인까지 막을 수는 없음 그래도 빠른 패치를 설득하려면 정보 누출을 만드는 두 번째 취약점 가능성을 근거로 드는 편이 낫다고 봄 익스플로잇 체인은 모든 종류의 취약점에서 위험함 - 인터넷에서 잘못된 정보가 퍼지는 걸 막기는 어렵고, 대부분은 자신이 틀렸다는 것도 모름 정말 해로운 건 확신에 찬 **무작위 인터넷 댓글**을 그대로 믿는 것임 그런 걸 꿰뚫어 보는 능력을 키우면 보안뿐 아니라 다른 곳에서도 도움이 됨 - 공개 인터넷에 노출된 소프트웨어의 **원격 코드 실행** 보고서를 읽으면 보통 몇 분 안에 업그레이드함 그래서 이런 보고서를 읽는 것이고, 진지하게 받아들여야 함 그러지 않으면 조만간 기계가 뚫림 최근에는 공개되는 원격 코드 실행 익스플로잇 중 사전 공지가 없는 경우가 많아 보이고, 적어도 소프트웨어를 업그레이드할 몇 분은 줬으면 함 원격 익스플로잇 가능한 sendmail 버그들이 쏟아지던 1980년대 말~1990년대 초처럼 공개에 안전장치가 없던 시절 같음 이런 보고서를 읽지 않거나 너무 늦게 읽으면 수백만 대가 침해될 수 있음 현재 nginx는 공개 웹 서버 시장의 약 39~43%를 차지하므로 꽤 심각함 - 이번 건은 꽤 나쁘지만 전제 조건이 있음 대체 문자열에 물음표가 들어간 `rewrite` 지시문이 필요하고, 그 뒤에 정규식 캡처 그룹을 참조하는 `set` 지시문이 와야 함 예: `set $var $1` 또한 개념 증명은 **ASLR 비활성화**를 가정함 - 예시: [https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...]() - 기본으로 ASLR을 끄는 배포판이 있나? 수동으로 끈다고 해도 nginx가 그럴 만한 후보로 떠오르지는 않음 - 요즘 `rewrite`는 거의 안 쓰지 않나? PHP와 Apache의 예전 시절에 쓰던 것 같음 - 공식 **F5** 페이지는 여기 있음: [https://my.f5.com/manage/s/article/K000161019]() 다른 곳에서도 적혔듯 ASLR이 보호해 줌 영향받는 플랫폼의 수정판을 기다리는 동안 완화책으로 “`rewrite` 정의에서 이름 없는 캡처 대신 이름 있는 캡처를 쓰라”고 안내함 “이 예시에서 취약점을 완화하려면 `$1`과 `$2`를 적절한 이름 있는 캡처인 `$user_id`, `$section`으로 바꾸라”는 내용임 F5는 1.31.0과 1.30.1을 패치했음 OpenResty는 1.27과 1.29용 패치가 있음: [https://github.com/openresty/openresty/commit/ee60fb9cf645c9...]() Nginx 기반 Lua 애플리케이션 서버인 OpenResty의 진행 상황은 여기서 볼 수 있음: [https://github.com/openresty/openresty/issues/1119]() - 개념 증명은 **ASLR을 비활성화**함: [https://github.com/DepthFirstDisclosures/Nginx-Rift/blob/mai...]() - 워커 프로세스는 마스터에서 `fork`되므로 같은 **메모리 배치**를 받음 워커를 상대로는 무제한으로 크래시를 낼 수 있음 이를 이용해 읽기 오라클을 만들 방법이 있을 가능성이 큼 적어도 안정적인 서비스 거부는 가능함 Depth First의 전체 분석: [https://depthfirst.com/research/nginx-rift-achieving-nginx-r...]() - Apache와 Nginx의 좋은 대안 중 **메모리 안전 언어**로 작성됐고 보안 구멍이 많지 않은 것이 있을까? Java로 작성된 Jetty와 Go로 작성된 Caddy를 잠깐 봤지만, Jetty의 셸 주입 같은 다른 유형의 취약점 이력이 있어서 더 나을지 확신이 안 듦 - 메모리 안전성은 좋지만 모든 위협을 막지는 못함 요즘 인프라 운영자는 **능동적 방어**인 MAC, 즉 SELinux와 AppArmor에 익숙해져야 함 예전에는 마찰이 컸지만 지금은 사용을 쉽게 해 주는 도구가 더 많음 [https://presentations.nordisch.org/apparmor/]() [https://github.com/nobody43/apparmor-profiles/blob/master/ng...]() [https://github.com/nobody43/apparmor-suggest]() 참고로 두 저장소 모두 직접 만든 것임 - Apache와 nginx 규모로 쓰이는 소프트웨어라면 어떤 것이든 **취약점 이력**이 있을 수밖에 없음 둘 다 그렇게 오래 시장 점유율을 유지했다는 사실은 오히려 좋은 신호임 - Caddy는 사용하기 정말 편했음 다만 제대로 된 플러그인 시스템 대신 원하는 플러그인 조합에 따라 수천 개의 바이너리가 생기는 모델은 좀 별로임 그래도 소스에서 빌드한다면 꽤 깔끔하고 단순함 - Apache와 아마 Nginx도 기능과 구성 요소가 엄청 많음 대체 HTTP 서버들은 대부분 범위를 많이 줄이므로, 어떤 기능이 필요한지 먼저 정해야 함 메모리 안전 언어로 된 HTTP 서버 논의는 많이 보지 못했음 C 기반의 큰 세 서버인 Apache, Nginx, lighttpd는 모두 꽤 탄탄하고, 단지 언어 때문에 새 프로젝트로 갈아타려는 사람이 많지는 않은 듯함 또 대부분의 메모리 안전 언어를 선택하면 그 언어의 때로는 방대한 런타임이나 가상 머신, 부속 요소까지 같이 받아들이게 됨 Java 웹 서버라면 무작위 Java 프로젝트가 흔히 그렇듯 log4j를 쓸 가능성이 있음 - 로드 밸런서 용도라면 **HAProxy**가 아주 잘하고 있음 - “익스플로잇은 요청 간 힙 풍수(cross-request heap feng shui)를 사용한다”라니, 이런 식으로 **feng shui**가 쓰인 건 처음 봄 - Debian 12에는 이게 패치됐나? 그래도 어디에서도 `rewrite`나 `set`을 쓰지 않으면 영향받지 않는다고 보면 되나? - [https://security-tracker.debian.org/tracker/CVE-2026-42945]() - Ubuntu는 오늘 아침 기준으로 패치됐음 Debian은 아직 **trixie**를 패치한 것 같지 않음 - nginx를 쓰면서 최소한 `set`조차 안 쓰는 경우는 매우 드물 것 같음 대부분의 nginx 사용 사례는 TLS를 종료하고 요청을 node/php/go 등으로 넘기는 것임 그래서 `proxy_set_header X-Host $host;` 같은 줄에서 공격자가 제어하는 데이터가 들어간 `set`이 하나쯤은 있을 거라고 봤음 정정: 이름 있는 캡처는 영향을 받지 않는 듯함 어디엔가 `$1`이 없다면 괜찮을 것 같음 - 더 나은 링크: [https://depthfirst.com/research/nginx-rift-achieving-nginx-r...]() ([https://news.ycombinator.com/item?id=48126029]()) [https://depthfirst.com/nginx-rift]() ([https://news.ycombinator.com/item?id=48123365]())