과거 기사 날짜: 2026-10-14(공개 및 보안 릴리스 날짜). 2026-10-27를 통해 출처를 확인하고 정보를 보완했습니다.
이 기사는 이벤트 날짜별로 보관됩니다. 10월 14일 이후에 출시된 버전 및 릴리스 업데이트는 아래에 포함되어 있습니다. 대상: NGINX Open Source / NGINX Plus 웹사이트 및 역방향 프록시 운영 및 유지 관리 담당자, 보안 대응 담당자, 배포 유지 관리 담당자, NGINX를 자체 컴파일하고 타사 모듈을 유지 관리하는 엔지니어.
이 문서에서는 2026년 10월 14일에 공개되어 집중적으로 수정된 5가지 NGINX 핵심 취약점에 중점을 두고 있으며, 2026년 5월부터 9월까지의 대표적인 메모리 안전 및 요청 무결성 취약점도 되돌아봅니다. 내용은 트리거 조건, 코드 수준 원인, 영향 범위, 해결 워크플로, 단기 완화 조치, 공식 패치 구현, 이전 분기로의 백포트 및 프로덕션 검증을 다룹니다. S1와 같은 참조 자료는 소스 부록으로 연결됩니다. 예제 구성은 배포 및 감사 아이디어를 설명하기 위한 목적으로만 사용되며 구현하기 전에 실제 버전, 구성 상속, 종속성 및 비즈니스 용량을 기반으로 검증되어야 합니다.
핵심요약: 우선순위 조치
- 보안 업그레이드의 우선순위를 정하세요. nginx.org 오픈 소스 패키지의 경우 Stable 1.30 브랜치를 최소 1.30.6로 업데이트하고 Mainline 1.31 브랜치를 최소 1.31.7.로 업데이트합니다. 확인 날짜에 1.31.8가 최신입니다. Mainline 출시. 이는 별도의 분기 기준선입니다. 여러 지점의 숫자를 비교하지 마세요. S1S2
- 전체 패키지 버전별로 배포 설치를 확인합니다. Ubuntu 22.04 / 24.04 / 26.04 / 26.10에는 공급업체 백포트가 있습니다. Debian 13(trixie)에는 최소한
1.26.3-3+deb13u10가 필요합니다. 확인 시 Debian 12(bookworm) 패키지1.22.1-9+deb12u10는 여전히 영향을 받은 것으로 표시됩니다. 각 CVE를 확인하세요. Debian 13 권고에서는 Debian 12가 수정되었음을 확인하지 않습니다. S13S14S15 - 다섯 가지 구성 조합(
alias + rewrite + $request_filename,map+ 정규식 + 변수 평가,aio + ssi + include virtual, HTTP/3와proxy_request_buffering on,ssl_session_cache shared:...와 자동 TLS 세션 티켓 키 순환)을 감사합니다. 지시문의 존재만으로는 악용 가능성이 확립되지 않습니다. 요청 경로와 구성 범위를 평가합니다. S1S3S4 - 기존 프로세스와 컨테이너를 모두 교체합니다.
nginx -t를 실행한 다음 서비스를 다시 시작하거나 고가용성 롤링 배포를 수행합니다. 이전 master/worker 프로세스가 종료되었는지 확인하세요.nginx -s reload만으로는 실행 중인 바이너리가 변경되었음을 증명할 수 없습니다. - 실제 엔드포인트 확인: HTTP/1.1, HTTP/2, HTTP/3(활성화된 경우), 프록시된 업로드 및 API 요청 본문, mTLS 인증서 인증, SSI 페이지 및 액세스 로그. 각 엔드포인트에 대한 패키지 출처, 버전, 이미지 다이제스트, 실행 중인 프로세스 및 결과를 기록합니다.
- 즉각적인 업그레이드가 불가능한 경우 해당 트리거 조건을 제거합니다. 불필요한 SSI/AIO 또는 HTTP/3를 비활성화하고, 취약한
alias/rewrite/map변수 참조를 검토하고, 영향을 받은 mTLS에 대해 임시ssl_session_tickets off;를 평가합니다. 서비스. WAF, ASLR, 속도 제한 및 구성 변경은 일부 조건에만 적용되며 공식 패치를 대체할 수 없습니다. S3S4S8S12
1. 취약점 개요 및 위험 판단
NGINX는 2026년 10월 14일에 1.30.6(Stable) 및 1.31.7(Mainline)를 출시하여 5가지 보안 문제를 수정했습니다. 세 가지는 힙 오버플로 또는 use-after-free와 관련이 있으며 F5 CVSS v4.0 점수 9.2/Critical을 받았습니다. 나머지 두 개는 HTTP/3 요청 무결성과 TLS 클라이언트 인증서 인증에 영향을 미칩니다. S1S2S3
등급 시스템을 구별하십시오. nginx.org는 5개 문제를 모두 medium로 나열하고, F5 CVSS v4.0 및 일부 국가 보안 기관은 세 가지 메모리 문제를 Critical로 분류합니다. 이는 다섯 가지 모두 무조건적인 원격 코드 실행을 허용한다는 의미는 아닙니다. 공격자가 제어할 수 없는 구성, 트래픽 도달 가능성 및 조건이 중요합니다. 메모리 손상과 신뢰할 수 있는 RCE는 서로 다른 수준의 증거입니다. S1S3S4
| CVE | 기술적 문제 및 일반적인 트리거 조건 | 핵심 영향 | 평가 및 폐기 |
|---|---|---|---|
| CVE-2026-15176 | alias 경로 매핑 + rewrite 변경 URI + 평가 $request_filename | 힙 버퍼 오버플로, Worker 충돌; 특정 조건에서 잠재적인 RCE | F5 CVSS v4.0 9.2; 문제 해결 우선순위 |
| CVE-2026-93479 | HTTP/Stream 스크립트 평가, 특히 map 정규식 캡처 및 root 디렉터리, 로그 변수 상호 참조 | 예약된 버퍼를 덮어쓰고 힙이 오버플로됩니다. 특정 조건에서 잠재적인 RCE | F5 CVSS v4.0 9.2; 이전 수리 후 회귀 위험이 있습니다. |
| CVE-2026-97205 | SSI 가상 포함 및 AIO/비동기 작업; 미해결 작업 수 오버플로 | Use-After-Free, Worker 충돌, 메모리 손상; 잠재적인 RCE | F5 CVSS v4.0 9.2; 기본이 아닌 구성이 필요합니다 |
| CVE-2026-95101 | HTTP/3 알 수 없는 프레임이 버퍼 전체에 걸쳐 조각화되어 있으며 프록시 요청 본문 버퍼링이 활성화되어 있습니다. | DATA가 아닌 바이트를 업스트림 요청 본문에 잘못 삽입하여 요청 본문 크기 제한을 우회할 수 있음 | 이 취약점은 요청 무결성에 영향을 미칩니다. 자체적으로 RCE(원격 코드 실행)를 제공하지는 않습니다. |
| CVE-2026-97629 | 공유 TLS 세션 캐시, 자동 키 순환 및 Worker 키 미러링 | 세션 티켓 위조; 영향을 받는 mTLS 서비스에 대해 클라이언트 인증서 인증 우회가 발생할 수 있습니다. | 인증서 인증 유형 API가 비즈니스에 미치는 영향에 특별한 주의가 필요합니다. |
위의 CVSS 점수는 v4.0를 사용하여 F5에 의해 제공됩니다. 동일한 취약점이라도 CVSS 3.1, nginx.org 자체 등급 및 배포 심각도 등급에서 서로 다른 심각도를 나타낼 수 있습니다. S1S3S4
1.1 CVE 점수보다 배포 노출을 우선시합니다.
| 배포 양식 | 주요 조사 포인트 | 폐기 우선순위 권장 사항 |
|---|---|---|
맞춤형 rewrite, alias 및 복잡한 map를 포함한 공용 네트워크 역방향 프록시 | CVE-2026-15176, CVE-2026-93479 및 5월부터 7월까지 취약점 재작성/매핑 | P0: 즉시 감사 및 업데이트 |
| API / 클라이언트 인증서를 유일한 입구 인증 또는 주 입구 인증으로 사용하는 관리 플레인 | CVE-2026-97629의 세션 티켓 및 공유 캐시 구성 | P0: 인증 경계 즉시 확인 및 업데이트 |
| 외부 HTTP/3 업로드, 상태 변경 인터페이스, 트랜잭션 클래스 API 제공 | CVE-2026-95101, 특히 요청 본문이 백엔드로 프록시됩니다. | P0/P1: 비즈니스 중요도에 따라 정렬 |
| SSI 동적 페이지 또는 비동기 파일 I/O | CVE-2026-97205 | P1: 결합조건을 확인하고 조속히 수리하십시오. |
| 정적 페이지만 + 단순 HTTP/1.1/2 역방향 프록시 | 구성 및 버전은 여전히 감사가 필요하지만 일부 CVE 조건이 누락될 수 있습니다. | P1: 긴급 보안 업그레이드 기간에 포함됩니다. |
| 폐기된 Kubernetes 커뮤니티 ingress-nginx 사용 | 프로젝트는 보안 유지 관리를 중단하며 위험은 이 5가지 CVE에만 국한되지 않습니다. | 개별 컨트롤러 마이그레이션 계획 수립 |
P0/P1은 공용 네트워크 노출 및 인증 민감도에 대해 이 문서에 제공된 운영 및 유지 관리 폐기 제안입니다. 이는 공식적인 CVSS 분류가 아니며 기업의 내부 자산 및 변경 위험 평가를 대체해서는 안 됩니다.
1.2 영향 경계 및 공격 권한
이 배치의 핵심 취약점은 주로 NGINX 데이터 플레인에 있습니다. 공격 진입점은 클라이언트 연결 및 요청이며 실제 영향은 일반적으로 Worker 프로세스에서 발생합니다. 메모리 손상에 대한 악용 가능 조건이 충족되면 코드 실행 권한은 일반적으로 실행 중인 사용자, 컨테이너 제약 조건, Linux 기능, Worker의 마운트 및 네트워크 권한에 의해 제한됩니다. 잠재적인 RCE는 root 권한이나 호스트 손상을 자동으로 암시하지 않습니다. S4
그러나 프로세스에 권한이 없더라도 프록시 자격 증명, 인증서 개인 키가 포함된 읽기 가능한 파일, 업스트림 서비스 토큰, 임시 파일, 내부 API 및 연결 가능한 네트워크에 계속 액세스할 수 있습니다. mTLS의 경우 인증 우회 자체가 심각한 비즈니스 결과를 초래할 수 있으며 반드시 코드 실행을 동반할 필요는 없습니다.
2. 원인 분석
2.1 NGINX에서 오류가 발생하기 쉬운 세 가지 경계를 이해합니다.
NGINX worker는 요청 상태, 비동기 작업 및 프로토콜 파서를 유지 관리하는 수명이 긴 이벤트 중심 프로세스입니다. 이 취약점은 세 가지 엔지니어링 수준의 제약 조건을 구현합니다.
- 변수 평가 및 메모리 크기는 일관되어야 합니다.
rewrite요청 URI를 변경한 후 경로 매핑은 현재 유효한location와 일관되어야 합니다. 스크립트 해석기가 변수 길이를 계산할 때 쓰기 공간은 실제 출력 및 예약된 영역을 포함해야 합니다. - 비동기 작업은 요청된 메모리의 수명 주기를 연장해야 합니다. 완료되지 않은 파일 읽기 및 쓰기, 캐시 대기 또는 스레드 작업이 있는 경우 해당 요청 메모리 풀을 미리 해제할 수 없습니다.
- 프로토콜 상태와 보안 상태는 혼합되거나 생략될 수 없습니다. HTTP/3 알 수 없는 프레임 건너뛰기 길이는 DATA 요청 본문 길이로 간주될 수 없습니다. TLS 서명 확인에 참여하는 모든 키 슬롯은 세션 티켓 순환 중에 올바르게 초기화되고 동기화되어야 합니다.
다음 콘텐츠는 NGINX 업스트림 수정 커밋 및 공급업체 발표를 기반으로 트리거될 수 있는 오류 메커니즘을 설명합니다. 예제 조각은 분석을 위한 것이며 프로덕션 환경을 복구하는 데 직접 사용할 수 있는 완전한 코드는 아닙니다. S5S6S7S8S9
2.2 CVE-2026-15176: alias와 다시 작성된 URI 간의 경로 매핑이 잘못되었습니다.
NGINX에서는 일치하는 location와 해당 alias가 파일 경로를 결정합니다. rewrite는 현재 요청 URI를 변경할 수 있습니다. 다시 작성한 후에는 원래 location 매핑에서 사용된 가정이 더 이상 유지되지 않을 수 있습니다.
영향을 받은 처리 경로는 ngx_http_map_uri_to_path()에서 alias 상태를 확인할 때 요청이 다시 작성되었는지 여부를 적절하게 확인하지 못했습니다. 구성이 재작성 후 $request_filename를 계속 평가하면 현재 URI 상태를 따르지 않는 가정으로 경로가 구성되어 결국 힙 메모리에 대한 범위를 벗어난 쓰기가 트리거될 수 있습니다. S5
일반적인 조합(구성 감사의 반례로만 사용되며 배포는 권장되지 않음):
# 仅用于识别风险模式：不是修复配置
location /foo/ {
alias /srv/alias-root/;
rewrite ^/foo/.*$ /new-path;
return 200 $request_filename;
}위험은 return에만 국한되지 않습니다. set, if, add_header, log_format 등도 동일한 요청 프로세스에서 $request_filename 평가가 트리거되는 경우 감사가 필요합니다. 예제의 return는 이 상태 경로를 쉽게 볼 수 있도록 할 뿐 모든 프로덕션 구성에서 오버플로가 발생한다고 추론하는 데 사용할 수 없습니다. S5S10
공격 결과: 요청을 구성하면 Worker가 다시 시작되거나 서비스가 중단될 수 있습니다. ASLR가 닫혀 있거나 우회될 수 있는 조건에서는 잠재적인 RCE가 있습니다. 업스트림 패치의 핵심은 단순히 특정 버퍼를 확장하는 것이 아니라 더 이상 유효하지 않은 alias 컨텍스트에서 다시 작성된 URI 경로 매핑을 완료하는 것을 거부하는 것입니다. S5S10
2.3 CVE-2026-93479: 스크립트 평가에서 “예약된 공간”과 실제 변수 길이가 일치하지 않습니다.
NGINX의 HTTP 및 Stream 모듈에는 리터럴 문자열과 변수 값을 결과 문자열에 연결하는 스크립트 평가기가 있습니다. 애플리케이션 예제에는 HTTP 문서 root 경로, 액세스 로그 경로 및 Stream의 변수 표현식이 포함됩니다.
map + 정규 표현식의 특정 구성을 사용하면 map 결과 변수가 평가되기 전에 캡처된 값을 다른 표현식에서 읽을 수 있습니다. 예약된 길이의 스크립트 실행 방법과 결합된 이전 구현에서는 len 예약된 공간을 평가된 길이 누산기에 미리 계산하므로 후속 쓰기 포인터 계산이 더 이상 버퍼 경계와 일치하지 않습니다. 특정 변수 평가 시퀀스에서 후속 문자열 쓰기가 예약된 영역을 덮어쓰게 되어 힙 오버플로가 발생할 수 있습니다. S6
| 참여 요소 | 주목할 가치가 있는 이유 |
|---|---|
map의 정규식 | 캡처 변수 평가는 독립적인 수명 주기 및 캐싱 동작을 가질 수 있습니다. |
$1, $2 등과 같은 익명 캡처. | 다른 정규 표현식이나 표현식으로 쉽게 덮어쓰여 소유권을 추적하기 어렵습니다. |
root의 변수 | 경로 구축 트리거 시 스크립트 실행 및 버퍼 예약 |
log_format/동적 로그 경로 | 동일한 유형의 평가가 나중에 요청에서 트리거될 수 있습니다. |
stream의 스크립트 표현식 | 업스트림 수정 사항은 ngx_stream_script_run()도 수정합니다. HTTP 모듈만 검토할 수는 없습니다. |
중요한 회귀 관계: 이 취약점과 관련된 코드는 CVE-2026-42533를 수정한 이전 변경 사항과 관련이 있습니다. Debian 13의 공식 DSA에는 영향을 받는 코드가 이전 보안 백포트를 통해 trixie 패키지에 도입되었음을 명확히 명시하고 있습니다. 따라서 “7월 map 취약점 패치가 설치되었습니다”라고 해서 10월 CVE-2026-93479가 해결되었다는 의미는 아닙니다. 전체 보안 수정 체인을 확인해야 합니다. S6S14S17
여기서 잠재적인 RCE 위험은 메모리 보호 환경과 관련이 있으며 map 정규식만 익명 공격자가 악용할 수 있다고 주장해서는 안 됩니다. S11
2.4 CVE-2026-97205: AIO 완료되지 않은 작업 카운트 랩어라운드로 인해 Use-After-Free 발생
이 취약점은 단순히 “SSI를 켜면 UAF를 얻게 됩니다”가 아닙니다. 핵심은 기본 요청이 보유한 비동기 작업 참조 횟수에 있습니다.
NGINX 아직 완료되지 않은 비동기 처리를 추적하려면 r->main->blocked를 사용하세요. 이전 구현에서는 8비트 개수였습니다. 일부 경로는 개수를 늘리기 전에 상한 확인을 수행하지 않았습니다. 동일한 기본 요청에 256개의 미해결 작업이 누적되면 개수가 255에서 0으로 바뀔 수 있습니다. 후속 프로세스는 요청 해제를 방해하는 비동기 작업이 없다고 잘못 판단하여 작업에서 여전히 참조하는 요청 메모리 풀을 해제합니다. S7
실패 과정은 다음과 같이 나눌 수 있습니다.
- 연관된 비동기 I/O/스레드 경로가 활성화되면 SSI 페이지는
include virtual를 통해 여러 하위 요청 또는 읽기 작업을 도입합니다. - 특정 주요 요청의 처리되지 않은 작업은 개수 필드에 표시된 상한까지 누적됩니다.
- 8비트 카운트가 순환되어 “보류 중인 작업 없음”으로 잘못 표현되었습니다.
- 요청 메모리 풀은 해제되지만 파일 읽기, 캐시 대기 또는 스레드 작업의 콜백은 여전히 이에 대한 참조를 유지합니다.
- 후속 비동기 완료 콜백은 해제된 메모리에 액세스하므로 UAF, Worker 충돌 또는 잠재적인 메모리 손상이 발생합니다.
공식 수정 사항은 요청 헤더 파일에 NGX_HTTP_MAX_BLOCKED 250를 추가하고 출력 필터, 캐시 읽기 및 업스트림 스레드 경로에 제한 사항을 추가합니다. 임계값에 도달하면 동기화된 경로를 사용한 작업이 동기적으로 완료되고, 안전하게 처리할 수 없는 경우 보류 중인 작업의 추가 추가가 거부됩니다. S7
적용성 판단: SSI, AIO, 가상 포함, 하위 요청 및 관련 비동기 작업이 동일한 요청 체인에서 조합하여 발생할 수 있는지 평가해야 합니다. 이는 일반적으로 기본 일반 정적 프록시 구성이 아닙니다. aio off; 또는 ssi off;는 특정 트리거 요소를 제거할 수 있지만 먼저 비즈니스 기능 종속성을 확인해야 합니다. S4S7S25
2.5 CVE-2026-95101: HTTP/3 알 수 없는 프레임이 DATA 요청 본문의 상태와 혼동됩니다.
HTTP/3 프레임 파서는 DATA 프레임(HTTP 요청 본문 처리로 전달되어야 함)과 건너뛰어야 하는 알 수 없는 프레임을 구별해야 합니다. 네트워크 버퍼를 통해 조각화할 때 알 수 없는 프레임의 길이도 정확하게 보존되어야 합니다.
ngx_http_v3_parse_data()의 이전 구현에서는 알 수 없는 프레임을 건너뛸 때 “건너뛸 남은 바이트 수”를 저장하기 위해 st->length 필드를 사용했지만, 요청 본문 필터는 동일한 필드를 “나머지 DATA 페이로드 길이”로 해석했습니다. 알 수 없는 프레임이 여러 구문 분석 호출에 걸쳐 발생하는 경우 구문 분석이 중단된 후 다음 바이트 배치가 요청 본문의 일부로 잘못될 수 있습니다. S8
두 가지 유형의 위험이 발생합니다.
- 요청 본문 삽입: 클라이언트가 제출한 DATA가 아닌 프레임 페이로드가 업스트림 애플리케이션으로 전송되어 백엔드에서 실제로 수신한 데이터를 변경할 수 있습니다.
- 크기 제한 우회:
client_max_body_size및 기타 제한 사항. 예상되는 검사는 DATA 경로에 집중되어 잘못 변환된 콘텐츠는 해당 검증을 우회할 수 있습니다.
관계자가 설명하는 일반적인 트리거 시나리오는 ngx_http_v3_module가 HTTP/3 요청을 수신하고 proxy_request_buffering on를 전달하는 경우입니다. ngx_http_proxy_module에서는 프록시 요청 본문 버퍼링이 기본적으로 활성화되어 있습니다. 따라서 HTTP/3를 활성화하는 역방향 프록시를 먼저 확인해야 합니다. proxy_request_buffering on;가 명시적으로 작성되지 않았다고 해서 트리거 조건이 없다고 가정하는 것은 적절하지 않습니다. S8S18
이 취약점의 직접적인 결과는 백엔드 요청 무결성 및 보안 경계 변경에 속하며 이는 NGINX 코어에서 직접 완성된 RCE의 동등한 표현이 아닙니다. 궁극적인 비즈니스 영향은 이러한 바이트를 업스트림에서 구문 분석하고 신뢰하는 방법에 따라 달라집니다. S24
2.6 CVE-2026-97629: TLS 티켓 순환이 세 번째 키 슬롯을 놓쳤습니다.
영향을 받는 구성에서 NGINX는 공유 메모리 캐시를 통해 TLS 세션 티켓 키를 자동으로 생성하고 순환할 수 있으므로 여러 Worker가 동일한 티켓 배치를 처리할 수 있습니다.
관련 동기화 로직은 각 Worker에 대해 3개의 키 슬롯을 할당하고 암호 해독 콜백도 이 슬롯을 통과합니다. 그러나 이전 구현에서는 매번 공유 메모리에서 2개의 키 슬롯만 복사하므로 세 번째 슬롯의 키 이름, HMAC 키 및 AES가 생성됩니다. 키가 초기화되지 않은 상태로 남아 있을 수 있습니다. 티켓의 키 식별자가 이 상태와 일치하면 초기화되지 않은 키 자료가 서명 확인 및 암호 해독에 사용될 수 있으므로 TLS 세션을 위조하는 경로가 형성됩니다. S9
고위험 배포 조합은 일반적으로 다음과 같습니다.
# 仅为排查触发条件所示：共享缓存本身不是恶意配置
ssl_session_cache shared:SSL:10m;
# 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制이 취약점으로 인한 가장 심각한 비즈니스 결과는 ssl_verify_client on;의 클라이언트 인증서 인증(mTLS) 및 기타 방법을 사용하는 서비스에서 위조된 복구 세션이 클라이언트 인증서 확인을 우회할 수 있다는 것입니다. 공격의 성공 여부도 통제할 수 없는 조건에 따라 결정됩니다. 일반 서버측 HTTPS 인증서만 사용하고 클라이언트 인증서 인증은 사용하지 않는 사이트를 “공격자가 전체 웹사이트 로그인을 우회할 수 있다”고 오해해서는 안 됩니다. S9S12
이는 TLS 세션 인증 상태 문제이며 서버의 TLS 개인 키가 크랙되었는지 또는 공용 CA root 인증서가 영향을 받았는지 여부와는 아무런 관련이 없습니다. S24
2.7 DoS, RCE, 인증 우회 및 알려진 악용을 이해하는 방법
- DoS: 메모리 오류로 인해 Worker가 충돌하거나 대규모 재부팅이 발생합니다. 전체적인 비가용성의 원인은 트래픽 압박, 프로세스 재시작 능력, 연결 유지 관리 시간 및 고가용성 아키텍처와 관련이 있습니다.
- 잠재적인 RCE: 일부 발표에서는 ASLR가 닫히거나 우회될 때 코드 실행 가능성이 있음을 나타냅니다. 이는 안정적이고 보편적으로 명령을 실행할 수 있는 공개 공격 체인이 공개되었다는 의미는 아니다. S4
- 요청 주입/인증 우회: 보호되는 업무 상태나 요청 내용을 직접 변경할 수 있으며, 쉘을 직접 획득하지 않는다고 해서 무시할 수는 없다.
- 공격 시도를 발견했습니다. 2026년 5월 CVE-2026-42945에서는 실제 악용 활동에 대한 보고가 있었습니다. 이 역사적 사실을 10월의 5개 CVE가 모두 대규모로 성공적으로 악용되었다는 의미로 직접적으로 추론해서는 안 됩니다. S23
3. 복구 버전 및 패치 선택
3.1 NGINX Open Source 공식 패치 기준선
| 업스트림 지점 | 10월 5개 취약점을 다루는 첫 번째 공식 버전 | 2026-10-27 기준 권장 사항 |
|---|---|---|
| Stable 1.30.x | 1.30.6（2026-10-14） | 최소한 1.30.6를 설치하고 후속 보안 버전을 따르십시오. |
| Mainline 1.31.x | 1.31.7（2026-10-14） | 1.31.8（2026-10-21） |
| 이전 NGINX Open Source 지점 | ”오래된 취약점 패치가 적용됐다”는 것만으로는 판단할 수 없습니다. | 먼저 유지 관리되는 분기로 마이그레이션하세요. 그렇지 않은 경우 공급업체는 CVE-by-CVE 기준으로 뒷받침된다는 공식적인 증거를 제공해야 합니다. |
이는 nginx.org 업스트림 소스 코드/공식 브랜치의 버전 결론이며, 배포 공급업체에서 제공하는 백포트 수정 사항이 포함된 보안 패키지를 직접 거부하는 데 사용해서는 안 됩니다. 1.31.6의 값이 1.30.6보다 크더라도 여전히 메인라인 브랜치의 패치 기준보다 낮습니다. S1S2
3.2 5개 CVE의 업스트림 영향 범위
다음 범위는 nginx.org 보안 공지의 원본 텍스트에 따라 나열되며 “현재 실행 중인 분기” 및 “실제 구성 경로”와 함께 이해해야 합니다.
| CVE | 업스트림 태그가 영향을 받는 버전 | 공식적으로 고정 버전으로 라벨이 지정됨 |
|---|---|---|
| CVE-2026-15176 | 0.1.29–1.31.6 | 해당 지점 내 1.30.6+ 또는 1.31.7+ |
| CVE-2026-93479 | 1.30.0–1.30.5，1.31.2–1.31.6 | 위와 동일 |
| CVE-2026-97205 | 0.8.11–1.31.6 | 위와 동일 |
| CVE-2026-95101 | 1.25.0–1.31.6 | 위와 동일 |
| CVE-2026-97629 | 1.23.2–1.31.6 | 위와 동일 |
CVE-2026-93479에는 특정 도입 버전 제한이 있습니다. 모든 이전 NGINX 버전이 이 회귀의 영향을 받는 것은 아닙니다. 해당 범위를 벗어난 이전 버전은 여전히 이전 map 정규식 취약점 CVE-2026-42533의 영향을 받을 수 있습니다. S1
3.3 Ubuntu: 배포 백포트(USN-8955-1)
Canonical USN-8955-1 2026년 10월 26일에 4개의 Ubuntu 빌드에 대한 보안 업데이트 제공: S13
| Ubuntu 버전 | nginx 및 동일한 소스 패키지 고정 버전 | 설명 |
|---|---|---|
| 22.04 LTS | 1.18.0-6ubuntu14.22 | 공급업체 백포트입니다. 업스트림 버전 번호에는 여전히 1.18.0가 표시됩니다. |
| 24.04 LTS | 1.24.0-2ubuntu7.19 | 위와 동일 |
| 26.04 LTS | 1.28.3-2ubuntu1.12 | 위와 동일 |
| 26.10 | 1.30.4-7ubuntu1.1 | 위와 동일 |
이 발표에는 nginx-core, nginx-extras, nginx-full 및 nginx-light와 같은 동종 패키지의 해당 고정 버전이 포함되어 있습니다. nginx -v에만 표시된 업스트림 부분에서 수정 여부에 대한 결론을 내리지 마십시오. Ubuntu 24.04 및 1.24.0-2ubuntu7.19와 같은 패치는 이 공급업체에서 패치했지만 모든 소스의 1.24.0는 본질적으로 안전하지 않습니다.
Ubuntu는 또한 CVE-2026-95101가 Ubuntu 26.04 / 26.10에만 영향을 미치고 CVE-2026-97629가 Ubuntu 24.04 / 26.04에만 영향을 미친다는 것을 공식적으로 명확하게 표시했습니다. /26.10. Ubuntu의 자체 패키징 및 기능 범위는 다음과 같습니다. 이는 다른 배포판으로 직접 승격될 수 없습니다. S13
3.4 Debian: 버전별 차이점은 별도로 확인 필수
Debian 권고 DSA-6575-1(2026-10-21)은 이러한 5개 CVE를 다루고 Debian 13/trixie용 고정 nginx 패키지를 다음과 같이 식별합니다.
1.26.3-3+deb13u10그러나 이 보고서가 검증된 시점 현재 Debian 12 / bookworm에 대한 1.22.1-9+deb12u10는 Debian 보안 추적기에 의해 여전히 취약한 것으로 표시됩니다. 따라서:
- Debian 13 DSA-6575-1에 따라 업데이트하고 수락하세요.
- Debian 12는 현재 Security Tracker 또는 ELTS 공급업체에서 제공하는 보안 수정 사항을 하나씩 확인해야 합니다. 발표에서 수정 사항이 확정되기 전에는
apt upgrade의 성공을 기반으로 5개 항목이 모두 수정되었다고 선언하지 마세요. - Debian 소스 패키지는 nginx.org 버전 번호와 관계없이 패치 세트를 전달할 수 있습니다. 사용자 정의 빌드의 경우 전체 소스 코드 패키지 수정 세트를 확인해야 하며 단일 업스트림 커밋을 복사하여 완료된 것으로 간주할 수는 없습니다.
위의 구분은 DSA 및 CVE 추적 기록을 기반으로 합니다. S14S15S16
3.5 NGINX Plus, njs 및 수신 컨트롤러
| 제품/부품 | 보안 선택 및 검증 핵심 사항 |
|---|---|
| NGINX Plus(상용 버전) | F5에 해당하는 플러스 브랜치의 공지 및 업그레이드 안내를 참고하시기 바랍니다. 검증 당시 최신 CR은 PLS.37.2.0.1이고, LTS의 보안 빌드는 PLS.37.0.7.1입니다. Plus 버전과 포함된 백포트는 Open Source의 1.30/1.31 임계값으로 직접 대체될 수 없습니다. S19 |
| njs / ngx_http_js_module | 2026-10-14는 njs 1.0.2를 릴리스하고 CVE-2026-101019 및 CVE-2026-101025를 수정합니다. njs를 사용하는 경우 NGINX와 모듈의 호환성도 확인해야 합니다. S20 |
| F5 NGINX 수신 컨트롤러/게이트웨이 패브릭 | NGINX 코어는 관련되어 있지만 독립적인 소프트웨어 배포 체인입니다. 해당 컨트롤러, 이미지 및 릴리스 노트를 사용하여 관련 취약점을 수정하세요. Pod에서 NGINX 바이너리만 교체할 수는 없습니다. |
Kubernetes 커뮤니티 kubernetes/ingress-nginx | 이 프로젝트는 2026년 3월에 폐기되며 더 이상 새로운 보안 유지 관리를 제공하지 않습니다. 릴리스 번호를 F5 NGINX 수신 컨트롤러로 착각하는 대신 유지 관리되는 컨트롤러 또는 Gateway API로 마이그레이션하도록 계획해야 합니다. S21 |
3.6 실제로 어떤 패치를 선택해야 할까요?
| 배포 양식 | 권장 사례 | 수리 증명서 |
|---|---|---|
| nginx.org 공식 DEB/RPM 패키지 | 업스트림 브랜치의 고정 버전으로 업그레이드 | nginx -v/-V, 패키지 소스, 공식 보안 발표 |
| Ubuntu/Debian 공식 저장소 | 공급업체 보안 패키지 설치 | 전체 패키지 버전 + 공급업체 USN/DSA + CVE 상태 |
| RHEL/Alma/Rocky/SUSE/기타 배포판 | 특정 배포 보안 게시판 및 패키지 버전에 따라 업그레이드 | 해당 벤더 CSAF/공지문, Ubuntu/Debian 버전은 적용 불가 |
| 공식 또는 커스텀 컨테이너 이미지 | 검증된 수리 이미지를 다시 빌드하거나 가져와서 순차적으로 교체합니다. | 이미지 다이제스트, SBOM 빌드, 포드/컨테이너 이미지 ID 실행 |
| 자체 컴파일된 NGINX, OpenResty, Tengine 또는 타사 모듈로 패치된 버전 | 관리자의 전체 보안 버전 사용을 우선시합니다. 필요한 경우 대상 소스 트리에 대해 검토된 패치 백포트를 수행합니다. | 5가지 취약점 수정, ABI/모듈 호환성, 단위 및 비즈니스 회귀 |
OpenResty와 Tengine는 서로 다른 릴리스 시스템입니다. 이 표에서는 확인 방법만 설명합니다. 이는 해당 버전이 표준 NGINX와 동시에 영향을 받는다는 의미도 아니며 업스트림 코드 패치를 무조건 적용할 수도 없습니다.
4. 정식 수리 과정
4.1 외부 트래픽을 수신하는 실제 인스턴스의 인벤토리
최소한 각 항목을 대조하십시오.
- 도메인 이름, 로드 밸런싱/CDN/에지 프록시 링크, 원본 사이트 노출 방법 및 사용된 네트워크 프로토콜입니다.
- NGINX 제품(Open Source, Plus, Ingress 등), 정식 버전, 패키지 저장소 소스, 이미지 다이제스트.
nginx -V는 건물 모듈과 컴파일 매개변수를 표시합니다. njs, Lua, OpenResty 및 타사 동적 모듈이 있는지 여부.- 실제 실행 중인 master/worker PID, 서비스 유닛/컨테이너/포드, 복제본 및 Worker 노드.
- 실제 효과적인
http/stream,server,location,include구성. - HTTP/3, mTLS, SSI/AIO, 동적 로그 경로, 복잡한
map및 정규식 캡처를 활성화할지 여부입니다.
기본 /etc/nginx/nginx.conf만 확인하지 마세요. 프로덕션 환경에서는 include를 통해 여러 사이트, TLS 및 모듈 구성을 로드하는 경우가 많습니다. NGINX 설치 경로가 여러 개이거나 프록시 레이어가 여러 개 있을 수도 있습니다.
4.2 버전 및 컴파일 정보 확인
# NGINX 版本及构建选项
nginx -v
nginx -V 2>&1
# Linux：查看实际运行的 NGINX 进程
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'
# Debian / Ubuntu：查看完整已安装包版本、来源
apt-cache policy nginx
# 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包
dpkg-query -W 'nginx*' 2>/dev/null
# RPM 系：以实际安装包及仓库公告为准
rpm -qa | grep '^nginx'nginx -V는 명령줄 경로에서 발견된 바이너리의 빌드를 보고합니다. 실행 중인 worker가 이를 로드했음을 증명하지 않습니다. nginx -v는 배포판의 전체 패키지 접미사를 생략할 수 있으므로 패키지 관리자나 공급망 기록도 확인하세요.
4.3 효과적인 구성을 내보내고 첫 번째 정적 스크리닝을 수행합니다.
nginx -T는 구성을 테스트하고 병합된 구성을 덤프합니다. 출력에는 인증 자격 증명, 키 경로, 내부 호스트 이름 등과 같은 민감한 정보가 포함될 수 있습니다. 제어되는 터미널을 root 권한 및 개인 파일 권한으로 저장하고 원본 파일을 공개 작업 주문에 게시하지 않는 것이 좋습니다.
sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log'
sudo grep -nE \
'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \
/root/nginx-effective.conf이는 신뢰할 수 있는 CVE 자동 결정 도구가 아닌 단지 후보 경로 찾기일 뿐입니다.
grep는 변수가 동일한location또는 동일한 요청 평가 체인에 있는지 여부를 확인할 수 없으며 구성 상속 관계를 추론할 수도 없습니다.proxy_request_buffering on, 일부 캐시 및 티켓 구성에는 기본값이 있으며 해당 지침을 작성하지 않는다고 해서 위험이 사라지는 것은 아닙니다.- 역방향 프록시, CDN, 컨테이너 사이드카 또는 컨트롤러에 의해 생성된 구성은 수동으로 검사한 파일과 다를 수 있습니다.
NGINX Plus및 동적 모듈의 특성은 해당 공식 관리 도구를 사용하여 확인해야 할 수도 있습니다.
4.4 신뢰할 수 있는 채널을 통해 수정 사항 배포
Debian/Ubuntu(공식 배포 저장소):
sudo apt-get update
apt-cache policy nginx
# 升级发行版仓库中已经安装的 NGINX 及相关包；
# 先确认 Candidate 属于修复版本，再执行升级。
sudo apt-get install --only-upgrade nginx
# 对实际安装的 nginx-core / nginx-full / nginx-extras 等包
# 确认它们的版本和依赖一同达到厂商修复要求。
dpkg-query -W 'nginx*' 2>/dev/null이 명령 세트는 아직 사용할 수 없는 보안 수정 사항을 생성할 수 없습니다. 특히 Debian 12의 경우 업그레이드된 패키지가 보안 추적 시스템에 의해 여전히 취약한 것으로 간주되는 경우 추가 공급업체 수리, 격리 또는 마이그레이션 조치가 필요합니다. S13S14S15
nginx.org 공식 패키지:
# 先确认仓库来自 nginx.org、目标分支和候选版本
apt-cache policy nginx
# 经变更审批后再执行对应仓库的升级命令
sudo apt-get install --only-upgrade nginx자체 컴파일된 OpenResty, Tengine 또는 NGINX Plus를 사용하는 경우 해당 관리자가 지원하는 수정 버전을 사용하고 nginx.org, 배포판 및 타사 저장소 패키지를 혼합하지 마십시오. 원본 바이너리/이미지, 구성, 서명, 롤백 배포 매니페스트는 보존되어야 합니다.
Containers/Kubernetes: 변경할 수 없는 이미지를 업데이트하고 다이제스트를 기록하며 모든 이전 복제본을 단계적 롤아웃으로 교체합니다. kubectl rollout status는 배포 컨트롤러가 완료되었음을 확인만 합니다. 또한 이미지 다이제스트, 수신 라우팅 및 비정상 복제본을 확인합니다.
4.5 구성을 확인하고 기존 Worker를 교체합니다.
sudo nginx -t
# 按服务实际名称、主机高可用和变更窗口执行重启
sudo systemctl restart nginx
sudo systemctl status nginx --no-pager
# 核查真正存在的 master / worker
ps -eo pid,ppid,user,comm,args | grep '[n]ginx'nginx -s reload를 새 바이너리가 실행 중이라는 증거로 취급하지 마십시오. 일반 구성을 다시 로드하면 이전 master가 실행 파일을 교체하지 않고도 새 작업자를 시작할 수 있습니다. NGINX는 전용 온라인 바이너리 업그레이드 절차를 지원하지만 추가 단계와 확인이 필요합니다. 확립된 절차 없이 고가용성 트래픽 스위치를 사용한 후 서비스를 다시 시작하거나 대체 컨테이너를 출시합니다. S22
systemd 소켓, 컨테이너 항목 스크립트 또는 다중 설치를 통해 NGINX를 관리하는 경우 systemctl restart nginx가 모든 인스턴스를 포함한다고 직접 가정하는 대신 실제 시작 대상과 프로세스 경로를 확인해야 합니다.
4.6 실제 외부 입구에서 비즈니스 회귀를 수용하고 수행합니다.
최소한 다음을 수행하는 것이 좋습니다.
- 일반 HTTPS, 재작성된 경로, 정적 리소스 및
alias매핑 페이지가 정확합니까? - 일반
map배포, 변수 root 경로, 액세스 로그 경로, SNI/인증서 라우팅 및 Stream 프록시가 정확합니까? - 일반 업로드, 청크 업로드, API 요청 및 HTTP/3(활성화된 경우)에 대한 업스트림 볼륨 제한이 여전히 예상대로입니까?
- mTLS: 합법적인 인증서 요청이 성공해야 합니다. 누락, 만료 또는 승인되지 않은 인증서는 여전히 거부되어야 하며 TLS 재개/재연결 시 실수로 권한이 변경되어서는 안 됩니다.
- SSI 페이지 및 비동기 파일 액세스가 정상인지 여부; 오류 로그에는 메모리 참조에 대한 비정상적인 요청이나 반복된 Worker 충돌이 표시되지 않습니다.
- 트래픽 전환 후에는 이전 버전 프로세스와 이전 이미지 복제본이 종료되어야 합니다.
테스트는 자체 환경 또는 승인된 환경에서 수행되어야 합니다. 일반적인 요청 스모크 테스트만으로는 메모리 취약점이 수정되었음을 입증할 수 없습니다. 궁극적으로 공급업체의 수정된 버전, 소스 코드 패치 및 런타임 테스트는 승인을 위해 공동으로 승인되어야 합니다.
5. 즉시 업그레이드가 불가능한 경우 완화 조치
이 섹션은 패치 교체가 아닌 위험 감소 옵션입니다. 모든 임시 구성 변경 사항은 백업하고, nginx -t를 실행하고, 일괄적으로 릴리스하고, 필요한 경우 신속하게 롤백해야 합니다. S3S4
5.1 외부 노출에 따른 트래픽 우선순위 제어
적시에 업그레이드할 수 없는 서비스의 공격 표면을 줄이는 데 우선순위를 둡니다. 관리 표면 및 내부 API 신뢰할 수 있는 소스 액세스 제어, 업스트림 네트워크 격리 또는 단기 오프라인을 추가합니다. 고위험 입구에 연결, 요청 본문 및 속도 제한을 추가합니다. 요청 처리 체인 이전에 항목 관련 NGINX에서 소스 인증이 발생하는지 확인하세요. 대부분의 취약점 자체는 NGINX에 있습니다. 데이터 플레인 내부에서는 기존 WAF 규칙이 사용자 지정 구성 트리거 조건을 정확하게 결정하지 못할 수 있습니다.
5.2 alias / rewrite: 재작성 후 $request_filename 평가를 피하세요.
다음 사항을 확인하고 조정하는 것이 좋습니다.
alias를 사용하여location와 동시에 URI를 변경하는rewrite를 수행하지 마십시오.- URI가 다시 작성되었지만 올바른 위치 일치가 아직 완료되지 않은 경우
$request_filename를 사용하지 마십시오. return,set,if,add_header, 액세스 로그 형식 및 포함 파일에서 간접 변수 참조를 확인하세요.- 업무상 허용되는 경우 일반
root/try_files/독립형location를 사용하세요. 단,alias를root로 변경하세요. 또한 하나씩 확인해야 하는 파일 경로 의미가 변경될 수도 있습니다.
기존 구성을 덮어쓰기 위해 인터넷에서 일반적인 “안전한 재작성 템플릿”을 직접 복사하지 마십시오. location 접두사와 다시 쓰기 대상이 다르면 완전히 다른 의미의 경로 접합이 발생합니다. S5
5.3 map/Regex: 캡처 변수 상태 혼합 감소
$1와 같은 익명 캡처가 시간이 지남에 따라 다양한 정규식 평가 경로에서 재사용되도록 허용하는 대신 명명된 캡처의 우선 순위를 지정하고 전파 범위를 제한하는 것이 좋습니다. 예를 들면:
# 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
default /srv/www/default;
~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}이 조각은 변수 소유권의 감사하기 쉬운 구조만을 보여줍니다. 모든 CVE-2026-93479 트리거 경로를 독립적으로 제거하는 것으로 입증되었다는 의미는 아닙니다. 특히 캡처 변수가 다른 root 또는 log_format에서 미리 참조되는지 여부와 volatile, 동적 경로 및 상호 의존적인 평가 체인이 있는지 검토하세요. F5/CERT는 명명된 캡처를 사용하고 단기적인 완화로 해당 일반 일치 구성으로 사용 범위를 제한할 것을 권장합니다. S3S6
5.4 AIO + SSI: 불필요한 기능 조합 종료
SSI 또는 비동기 파일 I/O가 필요하지 않은 서버/경로의 경우 다음을 사용하세요.
# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;취약성 유발 조건의 관점에서 볼 때 일반적으로 둘 중 하나를 닫는 것만으로도 설명된 특정 체인을 제거하기에 충분합니다. 동시에 마감하는 것은 비즈니스가 이 기능에 의존하지 않는 시나리오에만 적용 가능합니다. include virtual, 하위 요청, 캐시 및 스레드 풀 동작을 확인하세요. 역방향 프록시 로드가 높을 때 AIO를 종료하면 대기 시간과 I/O 성능이 변경될 수 있습니다. S7
5.5 HTTP/3 요청체 주입 : 필요시 일시적으로 입구 폐쇄
HTTP/3와 관련된 quic 리스너를 비활성화하고, HTTP/3를 알리는 Alt-Svc 응답 헤더를 취소하고, 에지 레이어/로드 밸런서가 여전히 QUIC 요청을 복구되지 않은 NGINX에 직접 보내는지 확인합니다.
# 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen
server {
listen 443 ssl; # 保留 HTTPS/TCP 入口
# 对支持新版语法的构建，可在此使用 http2 on;
# 删除原有的 listen 443 quic reuseport;
# 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项）
# 其余证书、server_name、location 等配置保持不变
}위 내용은 변경 차이점에 대한 설명일 뿐, 개별적으로 활성화할 수 있는 전체 서버 구성은 아닙니다. HTTP/2의 설정 구문은 NGINX 버전과 관련이 있습니다. HTTP/2를 유지해야 하는 경우 http2 on;를 사용하거나 해당 버전에 따라 기존의 유효한 구문을 사용하고 nginx -t로 확인해야 합니다. 전체 섹션을 이 섹션으로 바꾸는 대신 배포 전에 기존 서버 구성과 병합해야 합니다. 또한 UDP 443 방화벽, HTTP/3 종료 위치 및 CDN/전면 프록시의 클라이언트 대체 경로를 확인합니다.
또 다른 단기 완화 유형은 영향을 받은 프록시 경로에서 proxy_request_buffering off;를 사용하는 것입니다. 그러나 이렇게 하면 업스트림 요청 본문 스트리밍, 실패 재시도 및 일부 업로드 워크플로의 동작이 변경됩니다. 지시어가 영향을 받은 HTTP/3 프록시 경로에 도달하는지 충분한 테스트와 확인 후에만 사용하십시오. S8S18
5.6 TLS 세션 티켓: 우선순위 보호 mTLS 인증 경계
업그레이드가 불가능하고 인스턴스가 공유 세션 캐시 + 자동 티켓 키 순환에 의존하는 경우 다음을 평가하세요.
# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;이는 TLS 세션 티켓 메커니즘을 꺼서 이 취약점에 설명된 티켓 위조 경로를 제거할 수 있습니다. 그러나 세션 재개 성능에 영향을 미칠 수 있습니다. “취약성을 방지”하기 위해 mTLS 클라이언트 인증서 확인을 끌 수는 없습니다. 이렇게 하면 원래 인증 경계가 직접 삭제되기 때문입니다. S9S12
명시적 ssl_session_ticket_key 파일 및 보안 순환은 전문 TLS 관리 프로세스에서 자동 생성 조건을 우회하는 데 사용될 수도 있지만 키 보관, 전체 노드 배포, 순환 및 이전 티켓 수명 주기는 모두 주의 깊게 감사되어야 합니다. 임시 긴급 상황을 대비하여 일반적인 웹 구성이나 스크립트에 장기간 재사용 가능한 키를 하드코딩하는 것은 권장되지 않습니다. mTLS를 사용하는 중요 서비스에서는 TLS 세션 재개 동작 및 유효한 클라이언트 인증서가 없는 요청 거부를 추가로 모니터링해야 합니다. S12
5.7 운영 체제 및 국경 보호의 역할
# Linux：常见值 2 表示进程地址空间随机化处于完整启用状态
sysctl kernel.randomize_va_spaceASLR, 비 root 작업자, 읽기 전용 컨테이너 파일 시스템, 최소 파일 권한 및 네트워크 격리를 통해 잠재적인 RCE의 영향을 줄일 수 있습니다. ASLR는 힙 오버플로 또는 UAF를 수정하지 않으며 작업자가 충돌하지 않는다고 보장할 수 없습니다. WAF, 속도 제한 및 요청 본문 크기 제한으로 인해 TLS 티켓 키 동기화가 수정되지 않습니다. S4
5.8 일반적인 오해: 이러한 작업은 수리를 완료하기에 충분하지 않습니다.
| 일반적인 작업 | 왜 부족한가요? |
|---|---|
| “nginx -v는 비교적 새로운 것 같습니다” | 그것이 속한 브랜치, 릴리스 버전의 전체 백포트된 패키지 버전 및 온라인 프로세스는 확인되지 않습니다. |
| “인트라넷 중 하나만 업그레이드되었습니다.” | 이전 Worker/이전 컨테이너/이전 CDN 원본 인스턴스는 여전히 요청을 받습니다. |
| ”사이트에서 PHP/동적 태그를 사용하지 않습니다.” | 이 결함은 NGINX 코어 경로 또는 프로토콜 구문 분석에서 발생하며 PHP 실행에 의존하지 않습니다. |
| ”WAF/Cloudflare를 여는 것만으로도 충분합니다.” | WAF는 모든 NGINX 구성 종속 메모리 결함 또는 TLS 재개 결함을 차단하는 것으로 입증될 수 없습니다. |
| ”이미 ASLR를 열었습니다.” | 난이도 완화를 활용하는 것뿐입니다. 요청 주입이 포함된 DoS는 여전히 가능합니다. |
| ”HTTP/3는 공용망에 노출되지 않아 업그레이드가 전혀 필요하지 않습니다.” | 나머지 4개 CVE에는 여전히 독립적인 평가가 필요합니다. 숨겨진 출처에 대한 직접적인 연결이 있을 수 있습니다. |
”7월의 map 취약점이 수정되었습니다” | 10월 CVE-2026-93479에는 후속 스크립트 평가 회귀 문제가 포함됩니다. |
| ”캐싱을 비활성화하면 모든 문제가 해결됩니다.” | 일부 TLS 캐시 또는 AIO 시나리오에만 영향을 미치며 별칭, 스크립트, HTTP/3에는 적용되지 않습니다. |
6. 공식 패치 구현 아이디어 및 검토 포인트
이 섹션은 2026년 10월 업스트림 NGINX 수정 사항을 따릅니다. 조각은 패치 검토에 대한 대표적인 변경 사항을 보여줍니다. 이는 완전하고 독립적으로 컴파일 가능한 수정 사항이 아닙니다. 사용자 정의 빌드의 경우 전체 커밋, 주변 코드 및 테스트를 검토하고 전체 지원 릴리스를 선호합니다. S5S6S7S8S9
6.1 CVE-2026-15176: URI는 alias 경로 매핑 거부 조건을 포함하도록 다시 작성되었습니다.
업스트림 커밋은 src/http/ngx_http_core_module.c에서 ngx_http_map_uri_to_path()를 수정했습니다.
- if (alias && !r->valid_location) {
+ if (alias && (!r->valid_location || r->uri_changed)) {검토 초점: URI가 변경되었지만 alias의 해당 위치 의미 체계가 더 이상 신뢰할 수 없는 경우 파일 시스템 경로를 계속 계산할 수 없습니다. 이는 사전 상태 제약 조건이 향상된 것입니다. 요청 URI에 잘못된 문자가 포함되어 있는지 여부를 간단히 확인하는 것은 아닙니다. S5
6.2 CVE-2026-93479: 출력 데이터 길이와 예약된 길이를 올바르게 구분합니다.
업스트림 커밋은 src/http/ngx_http_script.c 및 src/stream/ngx_stream_script.c를 동시에 업데이트합니다. 핵심 의도는 다음과 같이 요약될 수 있습니다.
- n = len;
+ n = 0;
/* ...计算实际脚本输出长度... */
- value->len = n;
- value->data = ngx_pnalloc(pool, n);
+ value->len = n + len;
+ value->data = ngx_pnalloc(pool, n + len);여기서 pool는 예시 매개변수 이름입니다. 실제 HTTP와 Stream 할당 표현식은 다릅니다. 변경 사항은 스크립트 출력 길이를 먼저 계산한 다음 예약된 길이를 최종 할당에 추가하므로 출력이 예약된 공간을 덮어쓰지 않습니다. S6
감사 및 백포트 시 HTTP/Stream의 해당 평가자도 포함되어야 합니다. map의 구성 구문 파일을 확인하는 것만으로는 결함이 수정되었음을 증명할 수 없습니다.
6.3 CVE-2026-97205: 8비트 비동기 작업 카운트에 대한 안전 임계값 설정
src/http/ngx_http_request.h에 추가된 업스트림:
#define NGX_HTTP_MAX_BLOCKED 250그리고 비동기 파일 읽기, 캐시 대기, 출력 필터링 및 스레드 작업에 유사한 항목을 추가합니다.
if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
/* 使用同步路径，或者拒绝新的异步操作 */
}검토 초점: r->main->blocked를 추가할 모든 실제 코드 경로를 다루어야 합니다. 헤더 파일에 임계값 상수를 쓸 수는 없습니다. 또한 백포트는 동기 폴백, 비동기 콜백 및 오류 반환의 완전한 조정을 확인하여 작업 거부로 인해 교착 상태 또는 참조 누출이 발생하지 않도록 해야 합니다. S7
6.4 CVE-2026-95101: 알 수 없는 프레임에 대해 별도로 skip 상태를 유지합니다.
업스트림은 HTTP/3 파서 상태 구조에 skip 필드를 추가하고 상태 분리를 수행합니다.
if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) {
st->skip = st->length;
st->length = 0;
st->state = sw_skip;
}
/* ... */
rc = ngx_http_v3_parse_skip(b, &st->skip);핵심은 “알 수 없는 HTTP/3 프레임을 비활성화”하는 것이 아니라 여러 읽기에서 건너뛴 바이트 수와 DATA 페이로드 길이가 항상 독립적인 상태로 관리되도록 하는 것입니다. 검토에서는 알 수 없는 프레임 간 버퍼 샤딩 및 client_max_body_size의 최종 일관성에 중점을 두어야 합니다. S8
6.5 CVE-2026-97629: 전체 TLS 키 슬롯 어레이 동기화
업스트림 변경 사항은 src/event/ngx_event_openssl.c에 있습니다.
ngx_memcpy(keys->elts, cache->ticket_keys,
- 2 * sizeof(ngx_ssl_ticket_key_t));
+ keys->nelts * sizeof(ngx_ssl_ticket_key_t));원본 이미지에는 세 개의 키 슬롯이 포함되어 있었지만 처음 두 개만 복사되었습니다. 대신 Worker의 투표 키 세트가 공유 메모리와 일치하는지 확인하기 위해 배열 요소의 실제 수를 기반으로 동기화하십시오. 검토할 때 memcpy 길이 수정을 한 번만 확인하는 것이 아니라 배열 할당, 초기화, 공유 잠금 및 회전 논리가 일치하는지 확인하십시오. S9
6.6 분산된 패치 조각만 적용하는 것이 권장되지 않는 이유는 무엇입니까?
이러한 5가지 수정 사항은 각각 src/http, src/stream, src/http/v3 및 src/event에 걸쳐 있으며 이전 버전에는 보안 백포트와 비공식 확장이 있을 수 있습니다. 백포트는 다음과 같은 검사 매트릭스를 형성해야 합니다.
| 개체 확인 | 확인해야 할 사항 |
|---|---|
| 패치 소스 | 공식 제출, 대상 버전 일치, 완전한 패치 및 서명 확인 |
| 오리지널 패치 세트 | CVE-2026-42533, 배포 백포트 등과 같은 기록 수정과 충돌하지 않습니다. |
| 코드 경로 | HTTP + Stream 스크립트, AIO/thread, HTTP/3, OpenSSL 티켓이 모두 포함됩니다. |
| 컴파일된 호환 가능 | OpenSSL, PCRE, 모듈 ABI, 동적 모듈 및 링크 종속성은 일관됩니다. |
| 기능적 회귀 | alias 재작성, 동적 로그, SSI/AIO, HTTP/3 업로드, mTLS 세션 재개 |
| 런타임 | 모든 Worker/Pod는 새로 검증된 빌드를 실행하며 레거시 이미지는 남지 않습니다. |
자체 릴리스를 유지 관리하는 팀의 경우 각 CVE에 대해 감사 가능한 패치 ID, 패키지 버전, 빌드 로그 및 회귀 보고서를 유지하는 것이 좋습니다. 일반적인 운영 및 유지 관리의 경우 가장 안전한 솔루션은 공급업체의 전체 보안 업데이트를 설치하는 것입니다.
7. 과거 취약점 역추적, 이전 지점 및 기타 제품
2026년 5월부터 9월까지 동시 확인이 필요한 7.1 NGINX 핵심 취약점
오랫동안 업데이트되지 않은 많은 NGINX 인스턴스는 10월에 발생한 새로운 문제의 영향을 받는 것이 아닙니다. 가까운 미래에 대표적인 수리 노드는 다음과 같습니다: S1S2
| CVE | 첫 번째 수정 릴리스 | 감사가 필요한 주요 위험 및 상황 |
|---|---|---|
| CVE-2026-42945 | Stable 1.30.1 / Mainline 1.31.0, 5월 13일 | rewrite 익명 정규식 캡처 및 교체 논리로 인해 힙 오버플로가 발생하고 잠재적인 RCE가 발생합니다. 실제 공격 시도에 대한 공개 보고가 있습니다. |
| CVE-2026-9256 | Stable 1.30.2 / Mainline 1.31.1, 5월 22일 | rewrite에서 정규식 캡처 및 길이 추정이 겹치면 오버플로가 발생합니다. |
| CVE-2026-42055 | Stable 1.30.3 / Mainline 1.31.2, 6월 17일 | HTTP/2 업스트림 또는 gRPC에 대한 특정 구성, 대규모 요청 헤더 조건으로 인해 버퍼 오버플로가 발생함 |
| CVE-2026-42530 | Mainline 1.31.2, 6월 17일 | HTTP/3 사용 후 무료; 공식 마크 영향을 받는 범위 1.31.0–1.31.1 |
| CVE-2026-42533 | Stable 1.30.4 / Mainline 1.31.3, 7월 15일 | map + 정규식 캡처 변수 평가로 인해 힙 오버플로가 발생하고 후속 패치에는 10월 CVE-2026-93479와의 회귀 상관 관계가 있습니다. |
| CVE-2026-60005 | Stable 1.30.4 / Mainline 1.31.3, 7월 15일 | ngx_http_slice_module 특정 변수 및 캐시 업데이트 조건에서 메모리 내용이 유출되었습니다. |
| CVE-2026-56434 | Stable 1.30.4 / Mainline 1.31.3, 7월 15일 | SSI는 UAF와 관련이 있습니다. 10월의 AIO 계산 취약점과 동일한 root 원인이 아닙니다. |
| CVE-2026-90439 | Stable 1.30.5 / Mainline 1.31.6, 9월 15일 | HTTP/3 + 특정 OpenSSL 버전 조합의 제한된 힙 오버플로는 주로 충돌/제한된 메모리 손상으로 나타납니다. |
2026년에 발표된 NGINX Core, HTTP/2, charset, SMTP 등 기타 취약점도 공식 보안 게시판에 따라 조사해야 합니다. 이 표는 현재 NGINX 공용 역방향 프록시 배포와 가장 관련이 있고 메모리 안전 또는 요청 무결성에 영향을 미치는 일반적인 이벤트에 의도적으로 중점을 둡니다. 2026년의 모든 CVE는 아닙니다. 목록. S1
CVE-2026-42945에 특별한 관심을 기울여야 하는 이유
5월에 이 rewrite 취약점에 대한 실제 악용 활동 및 공개 악용 코드 정보를 기록하는 정부 기관의 보안 게시판이 있습니다. 따라서 5월부터 현재까지 오랫동안 패치가 적용되지 않았고, 공용망에 공개된 복잡한 정규식 재작성 사례가 있는 경우에는 복구 완료와 더불어 비정상적인 Worker 크래시, 당시 접속 로그, 의심스러운 변경 사항 등을 추가적으로 검토해야 한다. S23
“공격 시도가 발생했습니다”는 공격자가 모든 대상에 대해 명령을 안정적으로 실행했음을 자동으로 증명하지 않습니다. 사고 대응이 관련된 경우, 권한 상승 또는 지속성에 대한 실제 증거와 별도로 손상 지표 및 프로세스 충돌을 조사해야 합니다.
이전 버전 및 배포 백포트에 대한 7.2 수정
NGINX 지점마다 고유한 지원 주기와 취약점 도입 시간이 다릅니다. 5개의 새로운 패치는 검토 없이 모든 초기 소스 트리에 출시될 수 없습니다.
| 장면 | 추천 전략 |
|---|---|
| 릴리스 버전에서 완전한 보안 패치가 발표되었습니다. | 공급업체 패키지를 사용하고 전체 패키지 버전을 문서화하세요. 호환되지 않는 업스트림 베어 바이너리로 교체하지 마세요. |
| Debian 12 및 이 배치의 모든 CVE에서 아직 다루지 않은 기타 영향을 받는 릴리스 | 위험 작업 지시서를 제출하고 외부 노출을 제한하며 공급업체/ELTS 상태를 확인합니다. 필요한 경우 검증 가능한 유지 관리 릴리스 체인을 마이그레이션하거나 사용합니다. |
| 업스트림 지원이 종료된 역사적 브랜치 | 지원되는 버전으로의 마이그레이션 우선순위를 지정합니다. 단기 백포팅이 필요한 경우 관리자는 종속성과 패치 호환성을 평가하고 전체 테스트를 작성합니다. |
| NGINX 포크(OpenResty, Tengine, 맞춤형 게이트웨이)와 함께 제공됩니다. | 먼저 해당 코드 경로가 포함되어 있는지 확인한 다음 포크 유지 관리자의 보안 설명을 사용하십시오. 업스트림 버전과 직접적으로 동일할 수는 없습니다. |
| 보안 패치로 인해 비즈니스 기능이 변경됨 | 단계적 출시, 버전 간 트래픽 전환, 구성 조정을 채택합니다. 격리하지 않고 수정되지 않은 버전의 공용 네트워크를 복원하는 것은 적절하지 않습니다. |
7.3 njs, Ingress 및 NGINX Core에 대한 별도의 수정
- njs: NGINX 메인 프로그램 외에도 NGINX JavaScript 모듈 자체의 버전도 확인해야 합니다.
njs 1.0.2는 2026년 10월 XML 구문 분석 메모리 고갈 및 엔터티 참조 속성과 관련된 XML 유효성 검사 불일치 문제를 수정합니다.nginx-saml를 사용한 XML 서명 확인과 관련된 배포의 경우 플러그인 시나리오에 대한 공식 njs 지침을 자세히 읽어야 합니다. S20 - F5 NGINX Plus / NGINX 수신 컨트롤러: 또한 컨트롤러와 게이트웨이 패브릭에는 각각 추가 보안 공지, 다양한 패키징 버전 및 고유한 정책 취약성이 있을 수 있습니다. 한 레이어를 업그레이드한다고 해서 다른 레이어가 자동으로 업데이트되는 것은 아닙니다. S19
- Kubernetes 커뮤니티 ingress-nginx: Kubernetes 관계자는 이미 컨트롤러가 2026년 3월에 유지 관리를 중단했으며 해당 창고를 F5 컨트롤러와 혼동할 수 없다고 발표했습니다. 영향을 받는 기업은 새로운 보안 버전을 기다리는 대신 원활한 마이그레이션을 계획하고 Ingress 주석 및 Gateway API 의미 차이를 확인해야 합니다. S21
8. 합격기준 및 사후검사
변경 작업 지시에 대한 승인 조건으로 다음 목록을 사용하는 것이 좋습니다.
| 프로젝트 | 자격기준 | 보관할 수 있는 증거 |
|---|---|---|
| 자산 및 포털 범위 | CDN를 우회할 수 있는 모든 외부 및 직접 연결 인스턴스가 인벤토리에 포함되었습니다. | 도메인 이름, LB, IP, 포드/컨테이너 목록 |
| 패키지 소스 및 수리 범위 | 해당하는 모든 CVE를 포괄하는 것으로 확인된 버전을 사용하세요. | 업스트림 보안 권고, USN/DSA, 패키지 버전, 이미지 다이제스트 |
| 이전 프로세스가 종료됩니다. | 기존 master/worker/컨테이너가 모두 교체되었습니다. | PID/시작 시간, 롤링 배포 상태, 실행 이미지 |
| 구성 감사 | 고위험 조합을 제거하거나 패치로 처리하고 상속관계를 검증했습니다. | nginx -T의 요약 및 감사 기록이 수정되었습니다. |
| TLS/mTLS | 신뢰할 수 있는 인증서가 통과되었습니다. 유효하지 않거나 누락된 인증서는 거부됩니다. 세션 재개는 인증을 우회하지 않습니다. | 부정/긍정 인증 테스트, 통제된 TLS 테스트 결과 |
| HTTP/3 요청 본문 | 경로 고정 활성화; 업스트림 요청 본문 및 조절이 올바르게 작동합니다. | HTTP/3, 프록시 업로드, 볼륨 제한 회귀 테스트 |
| SSI/AIO | 이 기능은 요구 사항을 충족하며 Worker에는 비정상적인 중단이 없습니다. | 비즈니스 회귀, 충돌 및 오류율 모니터링 |
| 운영 및 유지보수 모니터링 | 명백한 예외 없음 5xx, SIGSEGV, 프로세스가 반복적으로 종료됩니다. | 변경 전후의 서비스 표시 및 로그 |
| 롤백 전략 | 롤백이 필요한 경우 먼저 노출을 제한하고 보안 경계를 유지하세요. | 변경 주문, 비상 흐름 및 격리 계획 |
| 후속 라이프 사이클 | 보안 게시판 구독, 컨테이너 업데이트 빈도 및 지점 마이그레이션 계획 결정 | 업그레이드 원장, 책임자 및 다음 감사일자 |
8.1 로그와 실행 상태에서 무엇에 중점을 두어야 합니까?
오랫동안 노출된 서버의 이상 현상 worker process exited on signal 、 SIGSEGV , 요청 실패 급증, 비정상적인 소스 액세스 집계, 예상치 못한 TLS 세션 재개/인증 성공 및 비정상적인 백엔드 요청 본문 동작을 해결합니다. 이러한 지표는 조사 단서로만 사용될 수 있으며 특정 CVE가 악용되었음을 직접적으로 입증하기에는 충분한 증거가 아닙니다. ;해당 로그가 없다고 해서 공격이 없었다는 뜻은 아닙니다.
8.2 권장되는 최종 위험 결론 문구
프로덕션 환경에 대한 승인 보고서는 다음과 같은 정확한 표현을 사용해야 합니다.
NGINX 외부 서비스 진입 및 소프트웨어 패키지 소스가 확인되었습니다. 해당 인스턴스가 모두 업스트림 공식 보안 버전으로 업그레이드되었거나, 릴리즈 벤더에서 확인한 백포트가 완료되었습니다. 기존 Worker 및 기존 컨테이너가 교체되었습니다. 별칭/재작성/맵, AIO/SSI, HTTP/3 요청 본문 및 TLS 세션 티켓/mTLS 관련 구성이 감사를 거쳐 기능, 인증 및 요청 무결성 회귀 테스트를 통과했습니다. 아직 업그레이드가 완료되지 않은 인스턴스에 대해서는 노출지역, 보상조치, 책임자, 완료기한 등을 추가로 등록합니다.
Debian 12 또는 기타 릴리스에 대한 패치가 아직 완료되지 않은 경우 전체 승인 양식을 “완료”로 판단하는 것은 적절하지 않습니다. 해결되지 않은 CVE, 해당 트리거 구성이 있는지 여부, 격리 상태 및 최종 업그레이드 경로를 명확하게 기록해야 합니다.
부록: 인용 출처 및 링크
설명: 텍스트의 [Sx] 번호는 이 섹션과 동일하게 일치합니다. 다음은 업스트림 프로젝트 보안 발표, 코드 커밋, 공급업체 출시 발표 및 국가 보안 기관 정보에 우선순위를 부여합니다. 인용된 취약점의 심각도는 각 발급 기관의 등급 기준에 따라 설명됩니다. 데이터 검증일자는 2026년 10월 27일입니다.
S1 — NGINX Open Source 공식 보안 게시판
영향을 받는 업스트림 버전, 수정 분기, 10월 CVE 5개의 공식 심각도 수준이 포함되어 있으며 2026년까지의 과거 취약점도 다룹니다.
S2 — NGINX 공식 버전 출시 기록
1.30.6 / 2026-10-14의 1.31.7, 2026-10-21의 1.31.8 및 5월부터 9월까지의 중요한 보안 릴리스 이정표를 확인하세요.
S3 - 싱가포르 사이버 보안국: F5 NGINX 세 가지 심각한 취약점
CVSS v4.0 9.2 점수, 필수 구성 조건 및 CVE-2026-15176, CVE-2026-93479 및 CVE-2026-97205에 대한 임시 완화 권장 사항에 대한 설명입니다.
S4 - NHS 잉글랜드: F5 NGINX 고위험 주의보
DoS/잠재적 RCE가 메모리 안전 문제에 미치는 영향과 꺼지거나 우회되는 ASLR와 같은 제약 조건에 대해 설명합니다.
S5 — 공식 소스 커밋: CVE-2026-15176
ngx_http_map_uri_to_path()의 alias, r->uri_changed의 상태 확인에 해당합니다.
S6 — 공식 소스 커밋: CVE-2026-93479
HTTP/Stream 스크립트 길이 및 예약된 버퍼 할당 논리에 해당합니다.
S7 - 공식 소스 커밋: CVE-2026-97205
r->main->blocked 개수 임계값 NGX_HTTP_MAX_BLOCKED 250 및 비동기 경로 대체에 해당합니다.
S8 — 공식 소스 커밋: CVE-2026-95101
HTTP/3 알 수 없는 프레임 남은 길이와 DATA 요청 본문 길이에 해당하는 상태 분리입니다.
S9 — 공식 소스 커밋: CVE-2026-97629
동기화 TLS 세션 티켓 순환 중 모든 키 슬롯에 해당합니다.
S10 — F5: CVE-2026-15176 공급업체 공지
alias, rewrite, $request_filename 등의 트리거 요인과 액세스 로그를 나열합니다.
S11 — F5: CVE-2026-93479 공급업체 공지
목록 맵 정규식 캡처, root 경로 및 로그 변수 평가 조건.
S12 — NGINX 공식 TLS/SSL 모듈 문서
설명 ssl_session_cache, ssl_session_tickets, ssl_session_ticket_key 및 클라이언트 인증서 인증 및 기타 지침.
S13 — 보안 권고: Ubuntu USN-8955-1 (2026-10-26)
Ubuntu 22.04 / 24.04 / 26.04 / 26.10.의 완전한 소프트웨어 패키지 고정 버전 및 배포 범위를 제공합니다.
S14 — 보안 권고: Debian DSA-6575-1 (2026-10-21)
Debian 13 / trixie에 대한 보안 수정 패키지 1.26.3-3+deb13u10를 확인하고 CVE-2026-93479에 대한 백포트 연결을 기록합니다.
S15 — 취약점 추적: Debian Security Tracker: CVE-2026-15176
Debian 12 / bookworm 및 Debian 13 / trixie의 배포 수정 상태를 확인하는 데 사용됩니다. 이 상태는 향후 보안 업데이트에 따라 변경될 수 있습니다.
S16 — 취약점 추적: Debian Security Tracker: CVE-2026-95101
다양한 Debian 지점에서 HTTP/3 취약점의 보안 상태를 보완적으로 확인합니다.
S17 — 보안 권고: Red Hat: CVE-2026-93479
10월 회귀 취약점과 7월 CVE-2026-42533 수정 사항 간의 상관 관계에 대한 보충적인 이해입니다.
S18 — NGINX 공식 역방향 프록시 모듈 문서
- https://nginx.org/en/docs/http/ngx_http_proxy_module.html
- https://nginx.org/en/docs/http/ngx_http_core_module.html
proxy_request_buffering, client_max_body_size, alias, aio 등과 같은 구성의 의미 및 기본값을 쿼리합니다.
S19 — NGINX Plus 공식 출시 노트
List Plus CR/LTS 분기, 버전, 패치 및 업그레이드 호환성 알림을 확인하세요.
S20 — NGINX JavaScript / njs 공식 보안 게시판
2026년 10월 njs 1.0.2 및 관련 XML 유효성 검사, 메모리 소모 문제가 포함되어 있습니다.
S21 — Kubernetes: 커뮤니티 ingress-nginx 공식 은퇴 지침
- https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/
- https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/
프로젝트는 2026년 3월에 새로운 릴리스와 보안 수정 사항을 중단했으며 유지 관리되는 컨트롤러 또는 Gateway API를 마이그레이션하는 것이 좋습니다.
S22 — NGINX 공식 서비스 제어 및 온라인 바이너리 업그레이드 지침
프로세스 전환 승인을 위해 구성 다시 로드, 다시 시작 및 온라인 실행 파일 업그레이드 방법을 구별합니다.
S23 - 정부 보안 공지: 2026년 5월 NGINX 재작성 취약성
CVE-2026-42945에 대한 과거 위험 배경 및 보안 업데이트 제안을 제공합니다. 야생 내 착취와 관련된 판단은 당시 기관의 발표와 추가 사건 증거를 토대로 이루어져야 합니다.
S24 — F5: CVE-2026-95101 및 CVE-2026-97629 공급업체 공지
HTTP/3 요청 본문 삽입 및 자동 TLS 티켓 키 순환의 위험을 각각 다룹니다.
S25 — F5: CVE-2026-97205 공급업체 공지
설명 SSI/AIO 트리거 조건 및 잠재적인 메모리 손상 위험.