Next.js 이미지 최적화 API의 libheif 힙 버퍼 오버플로우

NOW Briefing

Brief 1 2026년 8월 25일, Next.js 이미지 최적화 API에서 조작된 AVIF를 처리할 때 인증 없이 서버 코드가 실행될 수 있는 취약점이 공개됐습니다. 원인은 Next.js 자체가 아닌 이미지 디코딩 라이브러리 libheif의 힙 버퍼 오버플로우입니다. Next.js와 libheif 보안 권고가 같은 날 공개됐습니다.

Brief 2 공격자가 만든 AVIF를 이미지 최적화 경로에서 디코딩하면 인증 없이 원격 코드 실행(RCE)으로 이어질 수 있습니다. libheif는 sharp와 ImageMagick 등 다른 이미지 처리 경로에서도 사용되므로 Next.js 외의 사용 환경도 함께 확인해야 합니다.

Brief 3 Next.js는 15.5.24 또는 16.3.3으로 올리고, libheif를 직접 사용하는 시스템은 v1.23.2 이상으로 갱신해야 합니다. 업그레이드 전에는 이미지 설정에서 AVIF 출력 포맷을 제거해 관련 경로를 우선 차단합니다.

‍

Next.js 이미지 최적화 API의 libheif 힙 버퍼 오버플로우

‍

■ 개요

‍

Next.js는 React 기반 웹 프레임워크입니다. 이미지 최적화 API는 원본 이미지를 서버에서 리사이즈하고 포맷을 바꿔 제공합니다. Node.js 이미지 처리 라이브러리 sharp는 HEIF·AVIF 파일을 처리할 때 libheif를 사용하므로, libheif의 힙 버퍼 오버플로우가 Next.js 이미지 최적화 경로에도 영향을 줄 수 있습니다. 제3자 기술 스택 조사에서 국내 온라인몰 일부의 Next.js 사용 사례가 확인돼, 국내 배포 환경에서도 사용 여부와 AVIF 설정을 확인할 필요가 있습니다.

영향 버전은 Next.js 10.0.0~15.5.23 및 16.0.0~16.3.2, libheif v1.23.1 이하입니다. Next.js 권고는 AVIF 최적화에서 인증 없이 원격 코드 실행이 가능하다고 설명하며 최고 심각도(Critical), CVSS v4.0 9.5로 평가했습니다. 공식 문서의 images.formats 기본값은 WebP이므로 AVIF를 직접 추가한 배포를 우선 확인합니다. 다만 권고문은 AVIF 최적화 시 영향이 있다고만 설명하므로, 기본 설정에서 공격자가 제공한 AVIF 원본까지 처리되는지는 추가 확인이 필요합니다. libheif 권고는 별도 API 옵션이나 특이한 호출 패턴이 필요하지 않다고 설명합니다.

연구진은 여러 애플리케이션에서 코드 실행을 재현했다고 밝혔고, Cloudflare는 8월 26일 AVIF용 WAF(웹 방화벽) 규칙을 차단 동작으로 배포했습니다. Next.js 수정은 libheif 패치가 반영될 때까지 AVIF 최적화를 끄는 조치이므로, Next.js 버전과 libheif 버전을 따로 확인해야 합니다.

‍

■ 요약

‍

항목	내용
식별자	CVE 미할당 (2026-08-31 기준) • Next.js·libheif 모두 GitHub 보안 권고로만 공개됨
심각도	• Next.js 권고: CVSS v4.0 9.5 • libheif 권고: CVSS v3.1 9.8
취약점 유형	힙 버퍼 오버플로우, 버퍼 범위를 벗어난 쓰기
영향/위험	• 조작된 AVIF·HEIC 파일 디코딩 시 힙 할당 경계 밖으로 약 16KB 덮어쓰기 발생 • 이미지 최적화 API를 통한 미인증 원격 코드 실행 가능 • ISOBMFF 컨테이너 구조와 HEVC 비트스트림 내용으로 덮어쓰기 범위와 값을 조절 가능 • 연구진이 여러 애플리케이션에서 코드 실행을 재현했다고 밝힘
취약 버전	• libheif v1.23.1 이하 • Next.js 10.0.0 ~ 15.5.23 • Next.js 16.0.0 ~ 16.3.2
벤더 대응 현황	• libheif v1.23.2에서 수정 완료 • Next.js 15.5.24 / 16.3.3 배포, AVIF 최적화 비활성화 방식 • Cloudflare 2026-08-26 긴급 WAF 규칙 배포(기본 동작 차단)

‍

■ 오버플로우 발생 경로

‍

libheif의 libheif/image/pixelimage.cc에는 다른 이미지에서 채널을 옮겨오는 transfer_channel_from_image_as()가 있습니다. 이 함수는 대상 이미지에 같은 채널의 플레인이 있는지 확인하지 않고 추가합니다. 채널 조회 함수는 첫 번째 일치 항목만 반환하므로, 두 번째 Alpha 플레인은 크기·비트 수 조회에서는 빠지지만 저장소를 직접 순회하는 코드에서는 처리됩니다.

크기 조정 함수 scale_nearest_neighbor()는 이 상태에서 첫 번째 Alpha 플레인의 8비트 정보로 출력 버퍼를 할당합니다. 이후 10·12비트 플레인을 처리하는 분기에서 같은 버퍼를 uint16_t*로 해석해 샘플당 2바이트씩 씁니다. 벤더 권고의 ASan 결과에서는 16,399바이트 영역 끝에서 2바이트 쓰기 오류가 보고됐고, 할당 크기를 약 16KB 넘겼습니다. 파생 항목 iden의 크기 검사가 항상 Error::Ok를 반환해 선언된 이미지 크기와 실제 픽셀 크기를 다르게 만들 수 있었던 점도 공격 조건에 포함됩니다.

v1.23.2 패치 커밋은 transfer_channel_from_image_as()의 반환형을 void에서 Error로 바꾸고, 같은 채널이 이미 있으면 오류를 반환하게 했습니다. 호출부도 이 오류를 전달하도록 수정했고, iden 항목과 파생 이미지의 채널 크기 검증도 강화했습니다.

아래는 libheif/image/pixelimage.cc의 transfer_channel_from_image_as()를 수정한 커밋 원문입니다.

-void HeifPixelImage::transfer_channel_from_image_as(const std::shared_ptr<HeifPixelImage>& source,
+Error HeifPixelImage::transfer_channel_from_image_as(const std::shared_ptr<HeifPixelImage>& source,
    heif_channel src_channel,
    heif_channel dst_channel)
 {
-  // TODO: check that dst_channel does not exist yet
+  // A destination image must never end up with two planes for the same channel:
+  // find_storage_for_channel() and every method built on it (get_bits_per_pixel(),
+  // get_channel_memory(), get_width()/get_height()) only ever look at the first
+  // match, so a second, differently-sized/differently-typed plane for the same
+  // channel would silently be invisible to size queries while still being iterated
+  // (and written to) by code that walks m_storage directly, e.g. scale_nearest_neighbor().
+  if (find_storage_for_channel(dst_channel) != nullptr) {
+    return {heif_error_Invalid_input,
+            heif_suberror_Unspecified,
+            "Destination image already has a plane for this channel"};
+  }

‍

■ PoC

‍

libheif 권고에는 취약한 HEIC 파일을 만드는 gen_poc.py 전체와 ASan 재현 절차가 실려 있습니다. 생성 파일은 iden·auxl 참조를 중첩해 비트 깊이가 다른 Alpha 플레인을 만들고, 이를 디코더로 열면 heap-buffer-overflow가 보고됩니다.

권고문은 여러 애플리케이션에서 원격 코드 실행을 얻었다고 적었지만, 이는 연구진의 통제 환경 재현 결과이며 실제 공격 사례를 뜻하지는 않습니다. 컨테이너 구조와 비트스트림 내용으로 오버플로우 범위와 값을 조절할 수 있어, 영향이 단순한 크래시에 그친다고 단정할 수 없습니다. 변형 파일을 만드는 생성 스크립트가 공개돼 있어 입력을 받는 서버는 패치 전까지 AVIF 처리를 막는 편이 안전합니다.

⚠️ WARN

공개된 PoC는 메모리 손상을 일으킬 수 있으므로 운영 환경이나 사용자 업로드 서버에서 실행하면 안 됩니다.
검증은 격리된 분석 환경의 ASan 빌드에서만 진행해야 합니다.

‍

■ 탐지 및 점검

‍

• npm ls next 또는 lock 파일로 배포 중인 Next.js 버전을 확인하고, 10.0.0~15.5.23 또는 16.0.0~16.3.2이면 영향 대상으로 분류합니다.

• next.config.js의 이미지 출력 포맷 설정 키 images.formats 값에 image/avif가 포함돼 있는지 확인합니다. 기본값은 ['image/webp']이므로 명시적으로 추가한 프로젝트가 우선 점검 대상입니다.

• 이미지 최적화 엔드포인트 /_next/image 접근 로그에서 외부 도메인을 가리키는 url 파라미터 요청과 해당 시점의 5xx 응답·프로세스 재시작을 상관 분석합니다.

• 이미지 처리 컨테이너의 비정상 종료, 세그멘테이션 폴트, 워커 재시작 이력을 확인합니다. 메모리 손상 시도는 실패해도 프로세스 크래시 흔적을 남깁니다.

• Next.js 외에 libheif를 사용하는 서버(썸네일 생성기, ImageMagick 연동 배치, 문서 변환 파이프라인)의 라이브러리 버전이 v1.23.2 미만인지 함께 조사합니다.

✅ CHECK

공개 권고에는 침해 지표(IoC)가 제시되지 않았습니다. 해시나 도메인보다 버전 인벤토리와 이미지 처리 프로세스의 비정상 종료 흔적을 우선 확인해야 합니다.

‍

■ 대응 방안

‍

• Next.js를 npm install next@15.5.24 또는 npm install next@16.3.3으로 업그레이드한 뒤 재배포합니다. 벤더가 제시한 우선 조치입니다.

• 즉시 업그레이드가 어려우면 next.config.js의 images.formats에서 image/avif를 제거해 AVIF 최적화 경로를 우선 차단합니다. 이는 패치 전 임시 대응이며, 패치와 동일한 보호 범위를 보장한다고 단정할 수 없습니다.

• 패치 적용 후에도 sharp에 포함된 libheif 버전이 수정됐는지 따로 확인해야 합니다. Next.js 수정은 AVIF 최적화를 끈 조치이지 libheif 자체를 업데이트한 것이 아닙니다.

• 배포판 패키지나 자체 빌드로 libheif를 사용하는 시스템은 v1.23.2 이상으로 갱신합니다. 이 릴리스에는 이번 건 외에 6건의 보안 수정이 함께 포함돼 있습니다.

• Cloudflare를 사용 중이면 2026-08-26 긴급 릴리스에 포함된 Next.js - Image Optimizer Remote Code Execution via Crafted AVIF 규칙이 관리형 룰셋에서 차단 동작으로 적용됐는지 확인합니다.

💡 TIP

Vercel 호스팅 환경은 Vercel 안내를 인용한 보도 기준으로 별도 조치가 필요하지 않지만, 자체 호스팅 배포는 업데이트해야 합니다.
사용자 업로드 이미지나 원격 이미지 프록시를 허용하는 서비스는 업그레이드 전까지 AVIF 확장자·MIME 타입의 입력을 앞단에서 거르는 것이 효과적입니다.