Ubuntu nginx USN-8955-2 패치 가이드: 20.04·18.04 ESM 버전 확인부터 업데이트까지

내 서버는 USN-8955-2 대상일까?

Ubuntu 20.04·18.04·16.04·14.04의 Ubuntu 제공 nginx 패키지를 쓰는 서버가 이번 공지의 대상이다. USN-8955-2의 공지 날짜는 2026년 11월 5일이며, 시·분은 확인되지 않았다. 패키지 공개 시각도 여기서는 단정하지 않는다.[1]

선행 공지 USN-8955-1은 2026년 10월 26일에 나왔고, 26.10·26.04·24.04·22.04의 수정을 안내했다. 이번 공지는 그에 대응하는 수정을 구 LTS에 제공하면서 CVE-2026-42533 수정도 추가한다. 새 CVE가 이번에 처음 등장했다는 뜻은 아니다.[1][2][3]

lsb_release -a
cat /etc/os-release

배포판을 먼저 확인해야 nginx의 앞자리 버전이 같아도 서로 다른 수정판을 비교하는 실수를 피할 수 있다. 예를 들어 20.04와 22.04는 모두 1.18.0으로 시작하지만, 이번 점검에서 찾아야 할 Ubuntu 패키지 전체 버전은 다르다.[1][2]

어느 버전까지 올려야 할까?

서버의 Ubuntu 릴리스에 맞는 공지 표의 수정 버전 또는 같은 배포판·공식 업데이트 계열에서 그보다 새로운 버전인지 확인하면 된다.[1][2]

공지에는 nginx, nginx-core, nginx-extras, nginx-full, nginx-light가 나열돼 있다. 14.04에는 nginx-naxsi도 포함된다. 이 이름들은 모두 설치하라는 목록이 아니다. 실제 서버에 설치된 패키지를 골라 해당 릴리스의 수정 버전과 비교해야 한다.[1]

22.04·24.04에서 CVE-2026-42533 하나가 수정됐다는 사실과 USN-8955-1에 나열된 취약점이 모두 수정됐다는 사실은 다르다. 위 표의 개별 취약점 수정 버전과 공지 전체 수정 버전을 구분하자. 이미 자기 배포판의 8955-1 수정판 이상을 적용했다면 이번 8955-2 때문에 별도의 패키지를 다시 찾을 필요는 없다.[1][2][3]

어떤 설정에서 문제가 생길 수 있을까?

정규식과 캡처 변수를 쓰는 map, alias와 rewrite 조합, AIO와 SSI 같은 특정 설정이 문제의 조건이다. nginx를 설치했다는 이유만으로 모든 서버에서 같은 문제가 발생한다고 볼 수는 없다.[3][4][5][6]

CVE-2026-42533은 요청에서 얻은 값을 다른 값으로 바꾸는 map 처리와 관련된다. 정규식으로 골라낸 일부 문자열을 담는 캡처 변수와 map의 결과 변수를 특정 순서로 참조하거나, 특정 조건에서 캐시되지 않는 변수를 조합할 때 메모리 처리가 잘못될 수 있다. 단순히 설정에 map이라는 단어가 있다는 것만으로 영향 여부가 확정되지는 않는다.[3]

공식 설명은 조작된 HTTP 요청으로 nginx 작업 프로세스가 중단될 수 있다고 안내한다. 코드 실행 가능성도 있지만, CVE 설명에는 ASLR이라는 메모리 보호 기능이 꺼져 있거나 공격자가 이를 우회하는 조건이 명시돼 있다. 외부 요청을 처리하는 경로의 문제이며 관리 기능이 노출됐다는 설명은 아니다.[3]

CVE-2026-15176은 alias와 rewrite를 함께 쓰면서 요청 파일명 변수를 참조하는 등의 설정이 관련된다. CVE-2026-93479는 map의 캡처 변수를 root나 접근 로그 형식에서 참조하는 경우 등이 관련된다. CVE-2026-97205는 AIO가 켜진 특정 환경에서 SSI의 include virtual을 처리하다 이미 해제한 메모리를 다시 사용하는 문제다. 각 조건은 다르지만 서비스 중단이나 코드 실행 가능성을 점검해야 한다는 공통점이 있다.[4][5][6]

설정 점검은 패치 적용 순서를 정할 때 참고하되, 패치를 대신할 수는 없다. 변수 참조 순서까지 읽어야 하는 문제를 단어 검색 하나로 판정하거나, 설정 일부를 바꿨다는 이유로 수정판 적용을 생략하지 말자. 특히 공식 패키지 밖의 모듈을 함께 쓰는 서버라면 변경 전후 점검 범위도 별도로 잡아야 한다.

nginx -v만 보면 패치 여부를 알 수 있을까?

아니다. +esm 같은 Ubuntu 패키지 수정 번호까지 확인하려면 dpkg와 apt의 전체 버전을 봐야 한다. nginx -v 출력만으로 ESM 수정판 적용을 판정하지 말자.

dpkg -l 'nginx*' | grep -E '^ii'
apt-cache policy nginx
nginx -v

먼저 첫 명령에서 실제 설치된 패키지 이름을 적는다. 다음으로 apt-cache policy에 그 이름을 넣어 Installed와 Candidate를 비교한다. Installed는 설치 버전, Candidate는 현재 저장소에서 설치 후보로 잡힌 버전이다. 아래 nginx-core는 예시이므로, 설치 목록이 다른 서버에서는 이름을 바꿔 확인한다.

apt-cache policy nginx-core

설치 버전이 표보다 낮은데 후보 버전도 낮다면 업데이트 명령부터 반복하지 말자. 서버 릴리스, 저장소 출처, Pro 상태부터 확인한다. 후보가 표의 수정판이라고 해도 설치 버전이 바뀌기 전에는 적용이 끝난 것이 아니다.

Pro에 연결하지 않은 서버는 무엇부터 확인할까?

현재 저장소에서 표의 +esm 수정판을 받을 수 있는지부터 확인해야 한다. 공지는 20.04·18.04에 Ubuntu Pro, 16.04·14.04에는 Pro와 Legacy Support 조건을 표시한다.[1]

pro status
apt-cache policy nginx

pro status는 연결과 서비스 상태를 살피는 보조 예시다. 명령 실행 자체가 연결이나 패키지 접근 권한을 보장하지는 않는다. Pro에 연결되지 않은 서버에서 일반 저장소 업데이트만으로 위 ESM 수정판이 내려올 것이라고 가정하면 안 된다. 실제 후보 버전과 저장소 출처를 함께 확인하자.

수정판을 받을 경로가 없다면 Pro 연결이나 지원되는 Ubuntu로의 이전을 검토할 수 있다. 이는 운영 선택지이지, 공지가 특정 이전 경로를 강제한다는 뜻은 아니다. 직접 빌드한 nginx나 타사 저장소 패키지는 Ubuntu 공지의 버전 표만으로 수정 여부를 판정할 수 없다. 그 공급 경로의 수정 내역을 별도로 확인해야 한다.

실제 업데이트는 어떤 순서로 진행할까?

공식 안내는 표준 시스템 업데이트로 필요한 변경을 적용하는 것이며, 아래 apt 명령은 그 작업을 위한 운영 예시다. 적용 전에는 설치 목록과 설정을 보관하고 서비스 영향 범위를 검토하자.[1][2]

sudo apt update
sudo apt upgrade

이 예시는 nginx 외의 패키지도 갱신할 수 있다. 실행 전 제시되는 변경 목록을 읽고 서버의 작업 시간과 맞춰 진행한다. nginx만 올려야 한다면 앞서 확인한 설치 패키지를 골라 –only-upgrade에 지정한다. 설치되지 않은 모든 변형을 한꺼번에 나열하지 않는다.

sudo apt install --only-upgrade \
  nginx nginx-core

위 예시는 nginx와 nginx-core가 실제 설치된 서버에만 해당한다. nginx-full이나 다른 변형을 쓰는 서버는 설치 목록에 맞게 바꿔야 한다. 명령이 성공했는지만 보지 말고, 이후 dpkg 결과의 전체 버전이 자기 배포판의 수정 기준에 도달했는지 다시 확인한다.

제3자 모듈이 있다면 특히 변경 후 기능 확인을 생략하지 말자. CVE-2026-42533의 공식 기록에는 과거 수정 과정에서 모듈 호환성과 특정 환경의 문제가 있었던 이력이 있고, CVE-2026-97205에는 업스트림 패치의 ABI 변경 메모가 있다. 이번 Ubuntu 패키지에서 같은 문제가 발생한다는 뜻은 아니지만, 별도 모듈을 쓰는 환경은 검증 범위를 넓힐 근거가 된다.[3][6]

업데이트 뒤 반드시 재시작해야 할까?

USN-8955-2에는 nginx 재시작이 필수라는 문구가 없다. 재시작 필수 여부는 이 공지만으로 확인되지 않는다. 재시작이 필요 없다는 뜻으로 해석해서도 안 된다.[1]

공지에 재시작 지시가 있는지와 서비스에 수정이 반영됐는지는 별도로 확인해야 한다. 다음은 설치 버전, 설정 문법, 서비스 상태를 확인하는 실무 예시다. 필수 재시작 명령을 대신 적은 것이 아니며, 각 확인 결과가 뜻하는 범위도 다르다.

dpkg -l 'nginx*' | grep -E '^ii'
apt-cache policy nginx
sudo nginx -t
systemctl status nginx --no-pager

패키지 버전이 맞는다고 사이트의 정상 응답까지 보장되지는 않는다. 설정 검사 성공도 보안 수정 적용의 증명은 아니다. 관리하는 사이트의 응답과 주요 프록시 경로를 확인하고, 실행 중인 서비스에 변경이 반영됐는지는 실제 패키지 처리 결과와 운영 절차에 따라 확인한다. systemctl 예시는 해당 서비스 관리 방식을 쓰는 환경을 전제로 한다.

작업 기록에는 Ubuntu 릴리스, 설치 패키지 이름, 적용 전후 전체 버전, 수정판을 받은 저장소, 서비스 확인 결과를 남기면 된다. 구 LTS는 Pro·Legacy 접근 조건까지, 22.04 이상은 8955-1 기준 충족 여부까지 구분해 두면 다음 점검에서 같은 공지를 다시 해석하는 일을 줄일 수 있다.

관련 글

• APT CVE-2026-109518 패치 가이드
• Alpine OpenSSH *sshole 패치 점검
• Ubuntu CVE-2026-98432와 proposed 커널 확인

출처