HEIF Heist — HEIF·AVIF 디코더를 겨냥한 네이티브 이미지 처리 공격 경로

AI 요약

Hacktron은 HEIF Heist를 공격자가 제어하는 HEIF, HEIC, AVIF 이미지를 디코딩하는 서비스에서 발생할 수 있는 원격 공격 경로의 집합으로 명명합니다. 핵심은 애플리케이션 자체의 언어·프레임워크 취약점이 아니라, 이미지 처리를 담당하는 하위 네이티브 라이브러리에서 메모리 손상이나 정보 노출, 원격 코드 실행(Remote Code Execution, RCE)을 일으킬 수 있다는 점입니다. 이미지 업로드 기능이 존재한다면 애플리케이션이 직접 C/C++ 코드를 사용하지 않더라도 해당 공격 표면에 연결될 수 있습니다.

■ 공격 표면은 애플리케이션 아래에 있습니다

연구 페이지가 지목하는 주요 구성 요소는 C/C++로 작성된 libheif와 libde265입니다. 이 라이브러리들은 보통 서비스 코드에 직접 포함되기보다 ImageMagick, libvips, Sharp 같은 상위 이미지 처리 래퍼, 운영체제 배포판 패키지, 사전 빌드된 컨테이너 베이스 이미지에 간접적으로 들어갑니다. 따라서 개발팀이 애플리케이션 의존성만 점검해도 실제 실행 환경에 어떤 디코더 버전이 포함되어 있는지는 별도로 확인해야 하는 구조입니다.

공격자는 .avif 또는 .heic 파일을 업로드 엔드포인트에 보내 원격 시스템이 사용하는 libheif의 버전 계열을 식별할 수 있다고 설명합니다. 버전 계열을 파악한 뒤에는 그 버전에 맞춘 n-day 또는 0-day 페이로드를 전달해 메모리 손상, 데이터 유출, RCE를 시도할 수 있습니다. 이 과정은 애플리케이션의 업로드 검증을 우회한다기보다, 검증을 통과한 이미지가 하위 디코더에서 처리되는 순간 네이티브 파서의 취약한 경로를 실행시키는 방식으로 제시됩니다.

■ 연구 페이지가 제시한 영향 범위

HEIF Heist 페이지는 잠재적 또는 확인된 영향 사례로 OpenAI의 비공개 저장소 덤프, Slack에서 파일을 유출할 수 있는 RCE, 이미지 업로드를 통한 Meta 핵심 제품군의 RCE, Redacted 사용자의 토큰과 AWS 접근 토큰 유출, Discourse의 인증된 RCE를 열거합니다. 또한 AVIF Image Optimization을 통한 Next.js의 비인증 RCE, GitHub Enterprise의 인증된 RCE인 CVE-2026-19118, 여러 웹 프레임워크와 CMS에서의 RCE, 여러 애플리케이션에서 사용자 파일과 민감 정보가 유출될 가능성도 함께 제시합니다.

FAQ에서는 RCE가 즉시 달성되지 않더라도 공격 원시 요소가 임의 힙 공개(arbitrary heap disclosure)로 이어질 수 있다고 설명합니다. 이 경우 공격자는 프로세스 메모리에 남아 있는 다른 사용자의 데이터나 환경 변수를 읽어낼 수 있으며, 연구팀은 이러한 가능성을 ‘heist’라는 이름과 연결합니다. 즉, 이 공격군의 결과가 항상 코드 실행인 것은 아니며, 메모리 노출만으로도 인증 정보와 사용자 데이터가 영향을 받을 수 있다는 주장입니다.

■ 익스플로잇 난이도와 AI 활용

연구 페이지는 공격이 즉시 실행 가능한 단일 도구 형태의 익스플로잇은 아니라고 밝힙니다. 대상 버전을 먼저 지문 채집하고, 그 버전에 맞는 이미지 페이로드를 제작해야 하며, 일부 RCE 시도는 수천 번의 이미지 업로드 뒤에야 성공했다고 설명합니다. 동시에 Hacktron은 frontier model인 GPT-5.6 Sol을 활용한 에이전트형 접근으로 초기 탐색부터 원격 코드 실행까지 걸리는 익스플로잇 개발 시간이 약 1~3일로 줄었다고 주장합니다. 연구에 참여한 도구와 모델로는 Hacktron Harness, GPT-5.6 Sol, Opus 5가 언급됩니다.

■ 연구의 출발점과 대응 방법

연구는 Hacktron이 Discourse에서 libheif RCE를 발견하고 보고한 뒤, 같은 이미지 처리 스택에 의존하는 애플리케이션이 얼마나 많은지 질문하면서 시작됐다고 설명합니다. ImageTragick, ForcedEntry, libwebp 취약점처럼 이미지 프로세서나 파서 하나의 문제가 폭넓은 제품군으로 확산된 사례를 선행 사례로 들고 있습니다. 운영체제 썸네일 생성이나 웹 업로드 처리처럼 이미지 파서가 여러 위치에서 자동 실행될 수 있기 때문에 영향 범위가 커진다는 설명입니다.

대응으로는 우선 배포판 보안 채널이나 직접 소스 빌드를 통해 libheif를 v1.23.2 이상으로 올리고, 최신 libde265를 적용하라고 권고합니다. 연구 페이지는 HEIF/AVIF 디코더 업데이트가 계속되는 동안 ISO Base Media File Format의 복잡성 때문에 앞으로도 메모리 안전성 문제가 발생할 수 있다고 봅니다. 따라서 해당 형식이 필요하지 않은 운영 환경에서는 신뢰할 수 없는 HEIF/AVIF 디코딩을 비활성화하고, 필요한 경우 이미지 처리 파이프라인을 강화된 임시 샌드박스 안에서 격리하라고 제안합니다. Discourse나 Next.js를 직접 운영한다면 각 프로젝트의 최신 릴리스와 보안 권고도 확인하라고 안내합니다.

■ <출처> 반응

• @besttof — 왜. 모든. 문단이. 애니메이션으로 나타납니까? 전혀 이해되지 않습니다. 보기에도 전혀 좋지 않고 너무 산만해서 내용을 읽을 수가 없습니다.

• @bryce — 관심을 끌어 마케팅하려면 취약점에 이름을 붙여야 한다는 것과 Claude가 웹사이트 전체를 작성했다는 것이 교차하는 지점입니다.

• @roryokane — 다행히 페이지는 prefers-reduced-motion이 reduce로 설정된 것을 감지하면 모든 애니메이션을 비활성화합니다. 저는 운영체제에서 이미 그 설정을 해두어서 애니메이션을 보지 못했습니다.

• @zk — 저도 reduce로 설정된 것 같습니다(모바일에서). 나타나며 애니메이션을 하지는 않지만, 보이지 않던 것이 보이는 상태로 ‘툭’ 나타납니다.

• @legoktm — 그러니까 GitHub, OpenAI, Meta, Discourse 등이 모두 중요한 보안 경로에서 libheif를 사용한다는 말입니까? 그런데 프로젝트 상태(2026년 8월)를 보면 libheif와 libde265는 반복적인 자금 지원이 거의 없는 독립 개발자 한 명에 의해 유지되고 있으며, 2026년에만 37건의 보안 권고를 조사하고 수정하고 공개해야 했습니다. libheif가 제품이나 서비스의 일부라면 Funding과 Commercial support를 읽어보시기 바랍니다.

원문: HEIF Heist (heif-heist.com) / 번역·요약: Trawling