원문 캡처 · csoonline.com
원문 캡처 · csoonline.com

F5가 NGINX 제품군에서 원격 코드 실행과 서비스 거부 공격으로 이어질 수 있는 취약점 3건을 공개하고 정규 유지보수 주기 밖에서 긴급 패치를 배포했다. 취약점은 최신 공통 취약점 점수 시스템(CVSS) 4.0 기준 모두 9.2점이며, F5는 실제 공격에 악용됐다는 증거는 발견하지 못했다고 밝혔다.

대상 제품은 NGINX Plus, NGINX Open Source, NGINX Ingress Controller, NGINX Gateway Fabric, NGINX Instance Manager다. F5는 고객에게 수정된 버전으로 설치하거나 업그레이드하라고 권고했다. 취약점 세 건의 상세 정보는 CVE-2026-15176, CVE-2026-97205, CVE-2026-93479에서 확인할 수 있다.

CVE-2026-15176과 CVE-2026-97205는 F5 NGINX의 ngx_http_core_module 취약점이다. 서버 작업자 프로세스에서 힙 버퍼 오버플로가 발생해 시스템이 충돌하거나 재시작할 수 있고, 공격자가 코드를 실행하거나 서비스 거부(DoS) 공격을 시도할 수 있다. 주소 공간 배치 난수화(ASLR)가 꺼져 있으면 코드 실행 위험이 커지며, 공격자가 ASLR을 우회할 수도 있다고 F5는 설명했다.

CVE-2026-93479는 map 지시문과 관련된 취약점이다. 조작한 HTTP 요청으로 힙 버퍼 오버플로를 일으킬 수 있으며, ASLR이 비활성화됐거나 우회된 경우 코드 실행으로 이어질 수 있다.

F5는 CVE-2026-15176의 위험을 줄이려면 $request_filename 변수와 location 블록의 alias 지시문을 함께 사용하지 말라고 권고했다. CVE-2026-97205는 비동기 파일 입출력(AIO)과 서버 측 포함(SSI)을 비활성화해 완화할 수 있다. CVE-2026-93479의 경우 이름 없는 캡처 대신 이름 있는 캡처를 사용하고, 정규식 일치가 이뤄지는 블록 안에서만 사용하도록 안내했다.

Infotech의 선임 연구 분석가 세바 이우수포비치(Seva Ioussoufovitch)는 취약점이 설정에 따라 영향을 받으므로 기업은 먼저 현재 NGINX 설정을 점검해 패치 우선순위를 정해야 한다고 말했다. 그는 NGINX가 폭넓은 시스템에 쓰이는 만큼 여러 기업에서 서비스 가용성이 저하될 위험이 커질 수 있다고 덧붙였다.

Dickson Research의 프랭크 딕슨(Frank Dickson)은 NGINX가 리버스 프록시, 로드 밸런서, 쿠버네티스 인그레스 역할을 하며 전송 계층 보안(TLS)이 보통 NGINX에서 종료된다고 설명했다. 따라서 해당 시스템에서 코드 실행이 가능해지면 비밀번호와 세션 쿠키, API 토큰, 개인 키가 노출될 수 있다는 지적이다.

F5는 이번 취약점이 실제 공격에 이용된 정황은 없다고 밝혔지만, 과거에도 자사 제품의 취약점이 공격 대상이 됐다. 미국 사이버보안·인프라 보안국(CISA)은 지난 5년 동안 실제 악용된 F5 취약점 8건을 경고했으며, 이 가운데 4건은 랜섬웨어 공격에 이용됐다. 이번 취약점은 F5가 6월 공개한 CVE-2026-42530에 뒤이은 것이다. 앞선 취약점도 NGINX Open Source의 ngx_http_v3_module에서 발견됐으며, 원격 공격자가 서비스 거부를 일으키거나 코드를 실행할 가능성이 있었다.

기업은 NGINX가 설치된 시스템뿐 아니라 다른 제품에 내장된 경우까지 포함해 자산 목록을 확인하고, 현재 설정을 점검해야 한다. 딕슨은 NGINX가 인그레스 컨트롤러와 어플라이언스, 컨테이너 이미지 안에 포함될 수 있고, 많은 팀이 nginx.org가 아니라 리눅스 배포판을 통해 설치한다고 지적했다. 공급업체 웹사이트에 수정 사항이 올라와도 각 서버에 자동으로 패치되는 것은 아니다.

패치가 당장 어렵다면 딕슨은 AIO를 끄거나 SSI 페이지 제공을 중단하고, map에서 이름 있는 캡처를 사용하며, ASLR이 켜져 있는지 확인하고 작업자 프로세스를 비특권 계정으로 실행하라고 권고했다. 또 외부 트래픽을 받는 진입 지점을 중요 시스템과 분리하고, 작업자 프로세스가 반복해서 재시작하는지도 살펴야 한다. 설정에 따라 취약점의 영향이 달라지지만, 조직이 자신의 NGINX 설정을 정확히 파악하지 못할 수 있다는 점이 문제로 지적됐다.