무슨 보안 공지인가
Vercel은 2026년 8월 Next.js 보안 릴리스에서 공개된 두 가지 취약점과 관련해, Vercel에 배포된 Next.js 애플리케이션은 보호되고 있으며 사용자가 별도로 조치할 필요가 없다고 밝혔다. 핵심은 “Next.js를 쓰는가”만이 아니라 “어디에서 실행되는가”, “이미지 최적화를 어떤 경로로 처리하는가”, “서버 파일시스템이 Windows인가”를 구분해 확인하는 것이다.
이번 공지는 개인 프로젝트, 연구용 웹앱, 팀 내부 도구, 공개 서비스처럼 Next.js를 운영 중인 사용자에게 모두 관련이 있다. 다만 Vercel에 호스팅된 애플리케이션과 직접 운영하는 자체 서버의 대응 방식은 다르다. Vercel 배포 환경에서는 업그레이드, 설정 변경, 재배포가 필요 없다고 안내됐지만, 자체 호스팅 환경에서는 패치 버전으로 올리는 것이 핵심 대응이다.
공개된 두 취약점
AVIF 이미지 처리 경로 취약점
첫 번째 취약점은 GHSA-2xp9-vwfh-vxw4다. Vercel 설명에 따르면 이 문제는 Next.js 자체 코드만의 문제가 아니라 상위 의존성인 libheif에서 비롯된다. 공격자가 조작된 AVIF 입력을 사용하고, Next.js Image Optimization이 해당 입력을 처리하는 조건에서 인증 없이 원격 코드 실행으로 이어질 수 있는 취약점으로 설명됐다.
Vercel은 이 취약점이 확인된 뒤 자사 관리형 Image Optimization 서비스에 보호 조치를 적용했다. 구체적으로는 관리형 이미지 최적화 서비스에서 AVIF 최적화를 비활성화했고, AVIF 입력은 영향을 받는 처리 경로를 통과하지 않고 그대로 제공된다. 따라서 Vercel의 관리형 이미지 최적화 기능을 사용하는 배포에서는 사용자가 직접 설정을 바꾸거나 재배포할 필요가 없다는 것이 공지의 핵심이다.
Windows 호스팅 서버 취약점
두 번째 취약점은 CVE-2026-75604이며, 함께 언급된 식별자는 GHSA-p293-qw3h-jr36이다. 이 문제는 Windows 파일시스템을 사용하는 Next.js 서버에서 영향을 받을 수 있다. 공지에 따르면 Pages Router를 사용하는 애플리케이션, 그리고 Cache Components 없이 App Router를 사용하는 애플리케이션에서 인증 없는 원격 코드 실행으로 이어질 수 있다.
Vercel의 Next.js 런타임은 Linux를 사용하므로 이 Windows 파일시스템 관련 취약점의 영향을 받지 않는다고 안내됐다. 따라서 같은 Next.js 애플리케이션이라도 Vercel에서 실행 중인지, Windows 서버에서 자체 호스팅 중인지에 따라 위험 판단이 달라진다.
Vercel 배포 사용자가 확인할 점
Vercel에 배포된 Next.js 애플리케이션이라면 공지 기준으로 별도 업그레이드, 설정 변경, 재배포가 필요 없다. 이 말은 “코드를 바꾸지 않아도 Vercel 측 관리형 서비스와 런타임 조건에서 보호된다”는 뜻에 가깝다. 다만 운영자는 배포 위치와 이미지 처리 경로를 확인해 실제로 해당 조건에 들어맞는지 점검해야 한다.
- 배포 위치: 문제가 되는 애플리케이션이 실제로 Vercel에 호스팅되어 있는지 확인한다.
- 이미지 처리: AVIF 이미지를 Next.js Image Optimization 또는 Vercel 관리형 Image Optimization으로 처리하는지 확인한다.
- 별도 인프라: 일부 라우트, 이미지 처리기, 프록시, 백오피스 서버가 Vercel 밖에서 실행되고 있지 않은지 확인한다.
- 운영 문서: 보안 대응 기록에는 “Vercel 배포는 공지 기준 조치 불필요, 자체 호스팅은 별도 패치 필요”처럼 환경을 나눠 남기는 것이 좋다.
자체 호스팅 Next.js라면 대응이 다르다
직접 운영하는 서버, 사내 인프라, 클라우드 VM, 컨테이너, Windows 서버에서 Next.js를 실행하고 있다면 Vercel의 보호 조치가 자동으로 적용된다고 보면 안 된다. 이 경우 Next.js 패치 버전으로 업그레이드해야 한다.
| 사용 중인 Next.js 버전 | 공지된 패치 버전 | 확인할 점 |
|---|---|---|
| Next.js 15.x 또는 그 이전 | next@15.5.24 | 의존성 잠금 파일과 배포 이미지가 실제 패치 버전을 사용하도록 갱신됐는지 확인한다. |
| Next.js 16.x | next@16.3.3 | 업그레이드 후 빌드, 라우팅, 이미지 처리, 캐시 동작을 함께 점검한다. |
패치된 릴리스에서는 AVIF 이미지가 리사이즈되거나 최적화되지 않고 그대로 제공된다. 이는 고정된 libheif 버전이 나오기 전까지의 처리 방식으로 안내됐다. 따라서 보안 패치 후에는 이미지 품질보다도 응답 크기, 로딩 시간, CDN 캐시 동작이 달라지는지 확인하는 것이 중요하다.
Windows 취약점에 대해서는 우회 방법이 없으며, 영향을 받는 서버는 즉시 업그레이드해야 한다고 공지됐다. 특히 Windows 기반으로 Next.js를 직접 실행하면서 Pages Router를 쓰거나, App Router를 쓰되 Cache Components 조건을 충족하지 않는 구성이 있다면 우선순위를 높여야 한다.
프로젝트별로 나눠 볼 기준
개인 프로젝트와 사이드 프로젝트
개인 프로젝트는 관리 부담을 줄이는 것이 중요하다. Vercel에만 배포되어 있고 별도 이미지 처리 서버가 없다면 공지 기준으로 조치가 필요 없는 쪽에 가깝다. 하지만 로컬 서버, 개인 VPS, NAS, Windows 머신에서 같은 코드를 따로 실행하고 있다면 그 환경은 별도로 봐야 한다.
- Vercel 배포 URL과 자체 서버 URL이 함께 운영되는지 확인한다.
- AVIF 이미지를 직접 업로드하거나 외부 사용자가 제출할 수 있는지 확인한다.
- 패키지 파일에서 실제 Next.js 버전이 무엇인지 확인한다.
- 패치 후 AVIF 이미지가 최적화되지 않아도 사용자 경험에 큰 문제가 없는지 살핀다.
학생과 연구자
연구용 웹앱이나 실험용 대시보드는 배포 환경이 섞여 있는 경우가 많다. 예를 들어 공개 데모는 Vercel에 올려두고, 실험 서버는 학교나 연구실 Windows 장비에서 따로 돌릴 수 있다. 이번 공지는 Vercel 배포 보호를 말하지만, 연구실 내부 서버까지 자동으로 보호한다는 뜻은 아니다.
외부 사용자가 이미지를 업로드하거나, 실험 데이터 시각화에 이미지 최적화 기능을 붙여둔 경우에는 입력 경로를 확인해야 한다. 특히 “공개 링크는 Vercel이지만 실제 파일 처리는 다른 서버가 한다”는 구조라면 해당 서버의 Next.js 버전과 운영체제를 별도로 점검해야 한다.
팀과 CI/CD 관리자
팀 환경에서는 “어느 서비스가 Vercel에 있고 어느 서비스가 자체 호스팅인지”를 먼저 나눠야 한다. 모노레포 안에 여러 Next.js 앱이 있고 일부만 Vercel에 배포되어 있다면, Vercel 앱만 보고 전체가 안전하다고 판단하면 안 된다.
- 저장소별 Next.js 버전을 목록화한다.
- 배포 대상이 Vercel, 컨테이너, VM, Windows 서버 중 어디인지 구분한다.
- 이미지 최적화 경로가 Vercel 관리형 서비스인지, 자체 서버 처리인지 확인한다.
- 패치 적용 후 잠금 파일, Docker 이미지, 배포 아티팩트가 모두 갱신됐는지 검증한다.
- Windows 서버에서 Next.js를 운영 중이라면 업그레이드를 지연하지 않는다.
업그레이드 후 확인해야 할 동작
보안 패치는 적용 자체로 끝나지 않는다. 이번 패치에서는 AVIF 이미지가 최적화되지 않고 그대로 제공된다는 변화가 있으므로, 이미지 중심 페이지에서는 성능과 렌더링 확인이 필요하다. 특히 상품 이미지, 연구 이미지, 포트폴리오 이미지, 대용량 업로드 이미지처럼 AVIF 비중이 높은 프로젝트에서는 응답 크기와 로딩 속도가 달라질 수 있다.
- 빌드: 패치 버전 설치 후 기존 빌드가 통과하는지 확인한다.
- 라우팅: Pages Router와 App Router 경로가 모두 정상 응답하는지 확인한다.
- 이미지: AVIF, WebP, PNG, JPEG가 의도한 방식으로 표시되는지 확인한다.
- 캐시: CDN, 브라우저 캐시, 이미지 응답 헤더가 예상과 크게 달라지지 않았는지 확인한다.
- 롤백: 문제가 생겼을 때 이전 배포로 돌아갈 수 있는지 확인하되, 영향을 받는 서버의 보안 패치를 장기간 되돌리는 방식은 피한다.
바로 판단하지 말아야 할 부분
이번 공지는 Vercel 배포와 자체 호스팅의 차이를 명확히 나누지만, 모든 프로젝트의 세부 구성까지 대신 판단해주지는 않는다. 예를 들어 가격 정책, 팀 권한, 특정 계정 유형별 제한, 지역별 적용 조건은 이 공지의 핵심 내용이 아니다. 따라서 비용이나 권한 변화가 있는지 판단하려면 별도의 공식 문서와 현재 계정 설정을 확인해야 한다.
또한 “Vercel에 앱이 있다”는 사실만으로 모든 관련 서버가 보호된다고 단정하면 안 된다. 이미지 업로드는 외부 스토리지와 자체 API가 처리하고, 화면 렌더링만 Vercel에서 하는 구성도 가능하다. 보안 공지는 실제 요청이 어느 런타임과 어느 이미지 처리 경로를 통과하는지를 기준으로 적용해야 한다.
간단한 점검 순서
- 운영 중인 Next.js 앱 목록을 만든다.
- 각 앱의 배포 위치가 Vercel인지 자체 호스팅인지 구분한다.
- 자체 호스팅 앱의 운영체제가 Windows인지 확인한다.
- 각 앱이 Pages Router를 쓰는지, App Router를 쓰는지 확인한다.
- AVIF 이미지를 받거나 처리하는 경로가 있는지 확인한다.
- 자체 호스팅 앱은 Next.js 15.x 이하라면 next@15.5.24, Next.js 16.x라면 next@16.3.3 적용 여부를 확인한다.
- 패치 후 이미지 최적화 동작과 페이지 성능을 테스트한다.
이 공지가 개발자에게 주는 의미
이번 사례는 보안 대응에서 플랫폼 관리형 기능의 범위를 확인하는 일이 중요하다는 점을 보여준다. Vercel에 호스팅된 애플리케이션은 공지 기준으로 보호되지만, 같은 코드베이스를 다른 서버에서 실행하는 순간 대응 책임은 달라진다. 특히 Next.js는 프레임워크, 이미지 최적화, 라우팅, 배포 플랫폼이 서로 맞물려 동작하므로 취약점 공지를 읽을 때도 “내 코드가 해당 기능을 쓰는가”와 “그 기능이 어디서 실행되는가”를 함께 봐야 한다.
개인 사용자와 학생은 자신이 직접 관리하는 서버가 있는지부터 확인하면 된다. 연구자와 개발팀은 데이터 업로드 경로, 이미지 처리 경로, Windows 서버 사용 여부를 우선 점검하는 편이 현실적이다. Vercel 배포만 운영한다면 이번 공지는 별도 작업보다 기록과 확인에 가까운 이슈다. 반대로 자체 호스팅 Next.js가 있다면 패치 버전 적용이 실제 대응의 중심이다.
출처와 검증
출처: Vercel Blog – Vercel applications are protected from Next.js August 2026 security vulnerabilities
검증 기준: Vercel 공지에 명시된 취약점 식별자, Vercel 배포 영향 범위, 자체 호스팅 패치 버전, AVIF 처리 방식, Windows 서버 영향 조건을 기준으로 정리했다.