한 메인테이너가 메모리 버그를 고쳐 커밋을 올리고 넘어갔다. 권고문도, 보안 라벨도, CVE 번호도 없었다. 그 한 줄의 누락 때문에 Vercel은 8월 두 주를 오픈소스 프로젝트 네 곳의 패치를 조율하는 데 썼고, 끝내 자사가 호스팅하는 모든 애플리케이션에서 AVIF 이미지 최적화를 껐다.
핵심 요약
- Vercel은 신고된 RCE의 원인이 자사 코드가 아닌 libheif임을 확인하고 8월 13일 플랫폼 전역에서 AVIF 최적화를 차단했으며, 8월 25일 Next.js 보안 릴리스를 배포했다.
- 취약 경로는 next/image에서 sharp를 거쳐 libvips로 이어지고, libvips가 AVIF 디코딩을 위해 libheif를 호출한다. ImageMagick과 WordPress를 비롯한 웹 상당수가 이 사슬을 공유한다.
- Vercel은 GitHub의 비공개 취약점 제보가 2026년 1월 주당 500건에서 5월 주당 3,000건으로 늘었고, 5월 한 달에만 1,560건의 권고가 검토됐다고 밝혔다.
진짜 실패는 라벨 누락이었다
보안 라벨이 없으면 하류에서는 아무것도 작동하지 않는다. 배포판 패키저는 백포트 신호를 받지 못하고, 의존성 스캐너는 대조할 식별자조차 없다. Debian 12와 13은 영향받는 버전을 계속 배포했고, Debian의 자체 업데이트는 8월 8일에야 나왔다. 수정은 공개된 git 이력에 그대로 남아 diff를 꼼꼼히 읽는 사람이라면 누구나 볼 수 있었지만, 그 패키지를 쓰는 모든 이용자가 위험을 그대로 물려받았다.
오랫동안 이 정도는 감수할 만한 실패였다. 디코더 한 곳의 1년치 업스트림 커밋을 훑어 라벨 없는 메모리 수정을 찾아내는 일은 값비싼 전문성이었다. 이제는 아니다. 연구자 3인이 Slack, Meta, GitHub Enterprise, Ruby on Rails, Next.js, Astro, Gatsby의 노출 범위를 조사하는 데 두 달과 토큰 비용 3,000달러 미만이 들었다.
왜 엉뚱한 프로젝트로 신고가 갔나
Hacktron AI는 8월에 이 문제를 Next.js 이미지 최적화의 RCE로 정리해 Vercel에 알렸다. 조사는 곧바로 책임 소재를 업스트림으로 옮겼다. Image 컴포넌트를 쓰는 Next.js 애플리케이션은 AVIF 파일을 리사이즈하고 최적화할 수 있다. 이 과정에서 sharp가 호출되고, sharp는 libvips를, libvips는 디코딩을 위해 libheif를 부른다.
결국 악의적으로 조작한 AVIF 이미지를 최적화 엔드포인트로 보내면 Next.js 코드는 한 줄도 건드리지 않은 채 취약한 디코더에 닿을 수 있었다. 프레임워크는 통로였지 결함 자체가 아니었다. 동시에 그 시점에 Vercel이 직접 통제할 수 있는 유일한 계층이기도 했다.
공개까지의 타임라인
Vercel의 엔지니어링 기록은 각 단계의 날짜를 남겼다. Hacktron은 8월 11일과 12일에 제보했고, 두 팀은 최신 Next.js 빌드를 상대로 작동하는 개념 증명 코드로 RCE를 재현했다.
8월 13일 Vercel은 플랫폼 차원의 완화 조치를 적용했다. Vercel의 모든 이미지 최적화 요청은 중앙 서비스 한 곳을 거치기 때문에, 그곳에서 AVIF 최적화와 리사이즈를 끄자 호스팅 고객 전체의 경로가 한 번에 끊겼다. 들어오는 AVIF 파일은 더 이상 libheif에 닿지 않았다.
문제는 자체 호스팅 환경이었고, 나머지 타임라인이 존재하는 이유이기도 하다. Vercel은 sharp와 libvips 메인테이너에게 메일을 보냈고, GitHub Security Advisory를 통해 libheif 쪽과 공조에 들어갔다. Hacktron은 익스플로잇 상세 내용을 libheif에 따로 제출했다. 8월 19일 Next.js 팀은 libvips 메인테이너를 만나 수정 방향을 맞췄���. 보안 파트너 통보는 8월 24일에 이뤄졌다.
8월 25일 상황이 마무리됐다. Next.js는 원래 다른 사안을 위해 잡아뒀던 보안 릴리스에 AVIF 완화 조치를 끼워 넣어 하루 앞당겨 배포했고, AVIF 최적화와 리사이즈를 아예 껐다. libheif 메인테이너도 같은 날 RCE를 해결한 v1.23.2를 공개했다. 공조 회의로부터 6일 만이었다.
같은 디코더가 닿는 범위
libheif는 ImageMagick, WordPress, sharp의 의존성이다. 잘 알려지지 않은 결함 하나가 유난히 넓은 폭발 반경을 갖는 이유다. 디코더는 이미 1년 전 업스트림에서 수정됐지만, 커밋에 보안 표시가 없었던 탓에 그 수정은 하나의 사안으로 전파되지 못했다.
영향은 가설에 그치지 않았다. Vercel 제보가 나오기 몇 주 전, 연구자들은 같은 유형의 libheif 오버플로를 SSO 취약점과 엮어 커뮤니티 포럼 이미지 업로드를 통해 OpenAI 내부 모노레포에 도달했다. 제품도, 진입점도, 대응 경로도 전혀 달랐지만 토대가 된 것은 똑같은 라벨 없는 결함이었다.
전망
Vercel은 물량 문제를 직접 짚었다. CVE 프로그램이 2026년에만 3만 5,000건 넘는 식별자를 발급했고, 언어 모델이 취약점 연구를 가속하면서 이런 업스트림 결함이 더 많이 드러날 것으로 본다고 밝혔다. 최근 Next.js 보안 릴리스 주기가 짧아졌으며 이 흐름이 이어질 것이라는 경고도 덧붙였다.
실무자에게 남는 결론은 제목보다 좁다. 플랫폼 고객은 8월 13일에 아무것도 하지 않고도 보호받았다. 자체 이미지 파이프라인을 운영하는 쪽은 실제로 어떤 libheif 빌드를 쓰고 있는지 확인해야 한다. 라벨 없는 수정이 답하기 어렵게 만드는 질문이 바로 이것이다.
자주 묻는 질문
취약점이 Next.js 자체에 있었나
아니다. 결함은 AVIF 디코더인 libheif에 있었고, Next.js가 AVIF 이미지를 최적화할 때 sharp와 libvips를 거쳐 여기에 닿았다. Next.js가 AVIF 최적화를 끈 것은 결함을 품고 있어서가 아니라, 빠르게 손댈 수 있는 계층이었기 때문이다.
Vercel에 배포했다면 조치가 필요한가
필요 없다. Vercel은 8월 13일 중앙 이미지 최적화 서비스에서 AVIF 최적화와 리사이즈를 차단해 호스팅 애플리케이션 전체의 경로를 막았다. 자체 호스팅 환경이라면 8월 25일자 Next.js 보안 릴리스를 적용하거나 libheif v1.23.2 이상 빌드를 써야 한다.
업스트림 수정에 라벨이 없으면 왜 문제가 되나
보안 도구는 식별자를 기준으로 움직인다. 메모리 버그를 조용히 고친 커밋은 권고 데이터베이스에 등록되지 않아 배포판이 백포트하지 않고, CI 스캐너도 영향받는 버전을 잡아내지 못한다. 수정은 공개 코드에 존재하지만 하류 이용자는 모두 취약한 상태로 남는다.
