Next.js 8월 보안 릴리스: 이미지 최적화와 Windows 서버를 함께 점검할 때

Next.js를 직접 운영한다면 15.5 계열은 15.5.24, 16.3 계열은 16.3.3 이상으로 올리는 일이 먼저입니다. 2026년 8월 25일 공개된 보안 릴리스는 AVIF 이미지 최적화 경로와 Windows 서버에서 각각 인증 없이 원격 코드가 실행될 수 있는 문제를 다룹니다.[1] Linux 서버라고 안심할 수는 없습니다. Windows 관련 문제에서는 벗어나지만 AVIF 처리 경로는 별도로 확인해야 합니다.

확인된 사실: Next.js 팀은 2026년 8월 25일 두 취약점의 패치 버전을 공개했습니다. 아래 운영 순서와 우선순위는 그 발표를 국내 웹서비스 환경에 맞춰 정리한 POEMORA의 해석입니다.

8월 25일 발표에서 바뀐 것

Next.js 팀은 처음에는 8월 26일에 보안 릴리스를 낼 예정이었지만, 상위 의존성에서 추가 치명적 취약점이 확인되자 일정을 하루 앞당겼습니다. 최종 릴리스는 Next.js 16.3.3과 15.5.24입니다.[1]

첫 번째 문제는 Next.js 이미지 최적화가 사용하는 sharp 아래의 libheif와 관련됩니다. 공격자가 통제하는 AVIF 파일을 서버가 최적화할 때 원격 코드 실행으로 이어질 수 있습니다. GitHub 보안 권고는 Next.js 10.0.0 이상 15.5.24 미만과 16.3.3 미만을 영향 범위로 제시하며, 수정판은 상위 수정이 반영될 때까지 AVIF 최적화를 끕니다.[2]

두 번째 문제는 Windows 파일시스템에서 Pages Router와 App Router를 함께 쓰고 Cache Components를 사용하지 않는 애플리케이션에 해당합니다. 영향 범위는 13.4 이상 15.5.24 미만, 그리고 16.0 이상 16.3.3 미만입니다. 공식 권고에는 알려진 우회책이 없으므로 해당 서버는 즉시 업그레이드해야 한다고 적혀 있습니다.[3]

우리 서비스가 영향받는지 15분 안에 가르는 법

먼저 저장소의 선언 버전만 보지 말고 운영 컨테이너나 서버에 설치된 Next.js 버전을 확인합니다. lockfile과 실제 배포물이 다를 수 있기 때문입니다.

1. 운영 환경에서 next/package.json의 버전을 읽습니다.
2. next.config에서 images.formats, remotePatterns, 커스텀 loader 사용 여부를 확인합니다.
3. 이용자가 이미지를 올리거나 외부 이미지 URL을 입력할 수 있는 화면을 찾습니다.
4. 실제 서버가 Windows인지 확인합니다. Windows라면 Pages Router와 App Router의 혼용 여부도 봅니다.
5. CDN이 앞에 있어도 원본 서버의 /_next/image 요청이 살아 있는지 로그에서 확인합니다.

여기서 '우리는 AVIF 업로드 버튼이 없다'는 답만으로는 부족합니다. 상품 수집기, 프로필 이미지 URL, 콘텐츠 편집기처럼 외부 주소를 받아 Next.js 최적화 경로로 넘기는 기능도 공격자가 입력을 통제하는 경로가 될 수 있습니다. 반대로 모든 이미지를 빌드 때 생성하고 외부 입력을 받지 않는 서비스라면 노출 조건이 달라집니다. 이 구분은 공식 영향 설명을 실제 데이터 흐름에 대입한 해석입니다.

패치는 버전 변경보다 배포 확인이 더 길다

업데이트 명령은 짧습니다.[1]

npm install next@15.5.24
# 또는
npm install next@16.3.3

그다음부터가 운영 작업입니다. 빌드 캐시를 비우고 새 lockfile로 이미지를 다시 만든 뒤, 실행 중인 프로세스가 수정 버전을 읽는지 확인해야 합니다. 모노레포라면 웹 앱마다 Next.js 버전이 다를 수 있으므로 루트 한 곳만 검사하지 않습니다.

배포 뒤에는 정상 JPEG·WebP가 계속 보이는지, 기존 AVIF 요청이 어떻게 처리되는지 살핍니다. 수정판이 AVIF 최적화를 잠시 비활성화하므로 이미지 품질이나 캐시 키, 원본 전달 방식이 달라질 수 있습니다.[1][2] 이 변화는 보안 수정의 일부입니다. 테스트에서 AVIF가 예전과 다르게 응답한다고 곧바로 패치를 되돌리면 안 됩니다.

Windows가 아니어도 남는 점검

Windows 원격 코드 실행 문제는 공식 설명상 Linux와 macOS에 영향을 주지 않습니다.[1] 다만 이 문장을 '이번 릴리스와 무관하다'로 읽으면 AVIF 문제를 놓칩니다. 운영체제 조건과 이미지 처리 조건을 따로 적은 표가 필요한 이유입니다.

• Linux 컨테이너: AVIF 입력 경로와 설치 버전을 확인합니다.
• Windows 서버: AVIF 점검에 더해 두 라우터 혼용과 Cache Components 조건을 확인합니다.
• Vercel 또는 관리형 환경: 플랫폼 공지만 기다리지 말고 프로젝트가 실제로 쓰는 Next.js 버전과 배포 완료 시점을 확인합니다.
• 여러 앱을 운영하는 조직: 서비스별 소유자, 패치 상태, 재검증 결과를 한 목록에서 관리합니다.

POEMORA의 판단은 단순합니다. 취약점 명칭을 내부 공지에 복사하는 것보다 '어떤 입력이 어느 최적화 경로를 지나 어느 서버에서 실행되는가'를 한 장으로 그리는 편이 빠릅니다. 이 흐름을 모르겠다면 웹서비스 구축과 운영 범위를 정리할 때 이미지 수집, 변환, 캐시, 원본 저장소를 함께 문서화해야 합니다.

배포 완료로 처리하기 전 남길 증거

완료 보고에는 버전 번호 하나가 아니라 아래 결과가 있어야 합니다.

• 패치 전후 운영 버전과 배포물 식별값
• AVIF를 포함한 대표 이미지 형식의 HTTP 상태와 MIME 유형
• 이미지 업로드·외부 URL 입력·관리자 수집 경로의 허용 범위
• Windows 해당 여부와 Pages/App Router 혼용 결과
• 실패 시 되돌릴 이전 배포물과, 되돌린 뒤 취약 버전으로 복귀한다는 위험 고지

마지막 항목은 특히 조심해야 합니다. 기능 오류 때문에 이전 이미지로 롤백하면 서비스는 살아나도 보안 패치가 사라질 수 있습니다. 그래서 보안 릴리스의 롤백 기준은 일반 기능 배포보다 좁게 잡고, 가능하면 수정판 안에서 설정이나 콘텐츠 문제를 해결하는 편이 낫습니다.

이번 주에 할 일

오늘은 운영 앱의 실제 Next.js 버전을 수집하고, 15.5 계열과 16.3 계열에서 수정 버전 미만인 배포물을 목록으로 만듭니다. 다음으로 AVIF와 Windows 조건을 별도 열에 표시합니다. 영향이 확인된 앱은 수정판으로 다시 빌드하고, 대표 이미지 요청과 주요 사용자 여정을 통과한 뒤에만 완료로 닫습니다.

공식 발표는 두 취약점을 한 번의 업그레이드로 해결하도록 묶었습니다.[1] 운영팀도 같은 방식으로 버전, 입력 경로, 서버 조건을 한 번에 확인해야 재배포 뒤 빈틈이 남지 않습니다.