엔진엑스에서 18년 묵은 치명적 RCE 취약점 발견

• 엔진엑스에서 18년 동안 숨어 있던 치명적 취약점이 공개됨

  • 대상은 엔진엑스 플러스와 엔진엑스 오픈소스
  • 취약점 이름은 엔진엑스 리프트, 식별자는 CVE-2026-42945
  • 리라이트 모듈인 ngx_http_rewrite_module에서 발생하는 힙 버퍼 오버플로우 문제임

• 핵심은 “인증 없이 HTTP 요청만으로 공격 가능할 수 있다”는 점임

  • 공격자는 특수하게 조작한 HTTP 요청을 보내 원격코드실행(RCE)이나 서비스 거부(DoS)를 노릴 수 있음
  • 주소 공간 레이아웃 임의화(ASLR)가 꺼진 환경에서는 서버 권한 탈취와 시스템 장악 가능성도 제기됨
  • 말 그대로 인터넷에 노출된 프록시나 웹 서버라면 그냥 지나치기 어려운 급의 이슈임

• 취약점은 특정 리라이트 설정과 정규식 캡처 기능이 결합될 때 터짐

  • F5와 최초 발견 연구팀 depthfirst에 따르면 문제가 되는 조건은 리라이트 설정 안의 캡처 처리와 관련됨
  • 즉, 엔진엑스를 쓴다고 전부 같은 위험은 아니지만, 취약 버전과 특정 설정이 겹치면 공격면이 생김

• 패치는 이미 나왔고, 같이 묶인 취약점도 3개 더 있음

  • 엔진엑스 오픈소스 1.30.1 이상에서 수정됨
  • 엔진엑스 플러스는 R32 P6 이상에서 수정됨
  • SCGI와 uwsgi 모듈의 과도한 메모리 할당 또는 메모리 읽기 문제도 함께 패치됨
  • SSL과 Charset 모듈에서도 메모리 정보 노출, 프로세스 재시작을 유발할 수 있는 결함이 발견됨

• 바로 패치가 어렵다면 임시 완화책이라도 적용해야 함

  • 리라이트 설정 안의 명명되지 않은 캡처(unnamed capture)를 명명된 캡처(named capture)로 바꾸는 방식이 권고됨
  • 그래도 임시 대응은 어디까지나 임시 대응이고, 최종적으로는 버전 업데이트가 맞음
  • 각국 보안 당국도 엔진엑스 기반 웹 서버와 인프라 전반의 버전 점검을 권고 중임

---

기술 맥락

• 이번 이슈가 큰 이유는 엔진엑스가 단순 웹 서버가 아니라 서비스 앞단의 기본 부품처럼 쓰이기 때문이에요. 로드밸런서 뒤 프록시, API 게이트웨이, 정적 파일 서버, 내부 어드민 라우팅까지 여기저기 들어가 있거든요.

• 취약점이 리라이트 모듈에서 나왔다는 점도 꽤 현실적인 문제예요. rewrite 규칙은 한번 만들어두면 몇 년씩 건드리지 않는 경우가 많고, 정규식 캡처도 레거시 라우팅을 맞추려고 자연스럽게 늘어나요.

• 패치가 우선이지만, 운영 환경에서는 바로 올리기 어려운 서버가 꼭 있어요. 그래서 named capture로 바꾸는 완화책이 언급된 건데, 이건 공격 조건을 줄이는 조치에 가깝고 취약한 바이너리를 안전하게 만드는 건 아니에요.

• 실무적으로는 버전 확인, rewrite 설정 점검, ASLR 같은 기본 보호 옵션 확인을 한 번에 묶어서 보는 게 좋아요. 메모리 취약점은 보호 기법 하나가 꺼져 있을 때 실제 침해 가능성이 확 올라가거든요.