Skip to content
KitploitKITPLOIT
도구블로그
제출
도구블로그
제출

해킹, 침투 테스트 및 사이버 보안 도구를 당신의 보안 무기고에!

Kitploit은 해킹, 사이버 보안 및 침투 테스트 도구 디렉토리입니다. 최신 프로젝트 업데이트를 발견하여 취약점을 찾고, 시스템을 분석하고, 테스트를 자동화하고, 보안을 강화하세요.

··피드·문의·개인정보·© 2026 Kitploit

도구 디렉토리

카테고리

모든 카테고리 보기
Loading categories
CVE-2026-28956-jxl-messages-surface — JPEG XL은 iOS Messages 미리보기 경로에서 자동 디코딩됩니다 — CVE-2026-28956(AppleJPEGXL)에 대한 전달 표면 발견으로, 패치 차이 분석(libjxl 0.10.4->0.10.5)과 공개 PoC에 대한 정직한 신뢰성 검증을 포함합니다. | Kitploit
도구/GitHubGitHub/eddinos2/cve-2026-28956-jxl-messages-surface
iOS SecurityVulnerability AnalysisExploitationMalware AnalysisMobile SecurityPapers & Research
GitHubeddinos2/cve-2026-28956-jxl-messages-surface

CVE-2026-28956-jxl-messages-surface

JPEG XL은 iOS Messages 미리보기 경로에서 자동 디코딩됩니다 — CVE-2026-28956(AppleJPEGXL)에 대한 전달 표면 발견으로, 패치 차이 분석(libjxl 0.10.4->0.10.5)과 공개 PoC에 대한 정직한 신뢰성 검증을 포함합니다.

인기

모두 보기 →

커뮤니티에서 가장 많이 사용되는 도구를 찾아보세요.

모든 도구 탐색

도구 컬렉션을 둘러보세요

모든 도구 보기 →
공유
저장소 보기
1일 전아직 검토되지 않음

iOS Messages 미리보기 경로에서 JPEG XL 자동 디코딩

CVE-2026-28956(AppleJPEGXL)에 대한 전달 표면(delivery-surface) 발견과 패치 디프 분석, 그리고 공개 PoC에 대한 신뢰성 현실 점검.

TL;DR — 기존 통념(그리고 EXR로 측정한 우리의 이전 결과)은 iOS Messages가 JPEG/PNG/HEIC가 아닌 첨부 파일을 디코딩 없이 일반 파일 블롭으로 렌더링한다는 것이었습니다. JPEG XL은 그 가정을 깨뜨립니다: .jxl 첨부 파일은 Messages 미리보기 경로에서 디코더로 전달됩니다. 우리는 MobileSMS 내부의 ImageIO가 사용자 상호작용 없이 수신 시 JXL 콘텐츠 디코딩을 시도하는 것을 관찰했습니다. 이는 AppleJPEGXL을 EXR 계열 포맷과 달리 실제 제로클릭 공격 표면으로 만듭니다.

목차

파일설명
PROBE_RESULT.md전달 표면 프로브: 설정, 발신자 증거, 디코딩 시도를 보여주는 기기 syslog, 판정 등급
DIFF.mdiOS 26.4.2 vs 26.5 패치 디프: CVE-2026-28956이 AppleJPEGXL(libjxl 0.10.4 → 0.10.5)로 귀속됨; ImageIO의 CVE-2026-43661 후보
pocs/poc.jxl공개된 149바이트 트리거(작성자의 분석 문서에서 발췌), 프로브 페이로드로 사용됨
pocs/poc_brand.heic, pocs/poc_mif1.heicftyp 브랜드를 heic / mif1로 변경한 동일 바이트 — 콘텐츠 스니핑 vs 선언된 UTI 테스트에 사용
pocs/jxldec.m최소 CGImageSource 디코딩 하네스(iOS용 크로스 컴파일), 온디바이스 디코딩 테스트에 사용

발견 내용

세 개의 첨부 파일이 iMessage(파란색 전송, 발신자 chat.db 기준 바이트 무결성)를 통해 iOS 18.6.2를 실행하는 물리적 iPhone으로 전송되었으며, idevicesyslog로 디코딩 표면을 모니터링했습니다:

  1. poc.jxl (UTI public.jpeg-xl)
  2. poc_brand.heic (동일 바이트, 브랜드 heic)
  3. poc_mif1.heic (브랜드 mif1)

기기 로그(MobileSMS):

root@kitploit:~
MobileSMS(ImageIO): createImageAtIndex:2093: *** ERROR: createImageAtIndex[0] - 'JXL ' - failed to create image [-58]
MobileSMS(ImageIO): CGImageSourceCreateImageAtIndex:5081: *** ERROR: ... 'JXL ' ... [-58]

두 가지가 눈에 띕니다:

  • 디코더가 아예 실행되었습니다. 비교를 위해, 동일한 설정의 EXR 첨부 파일은 디코딩 활동이 전혀 발생하지 않습니다 — Messages는 파일 아이콘을 표시하고 디코더를 호출하지 않습니다. JXL은 미리보기에서 디코딩할 가치가 있는 이미지로 취급됩니다.
  • 콘텐츠 스니핑이 선언된 브랜드보다 우선합니다. .heic 브랜드 변형들도 매직 바이트로 'JXL '로 스니핑되어 JXL 디코더로 라우팅되었으므로, .heic 파일명이 파싱을 HEIF 리더로 유도하지 않습니다 — 반대로 일반 .jxl 첨부 파일은 이미 AppleJPEGXL에 도달합니다. 전달을 위한 컨테이너 속임수는 필요 없습니다.

-58 오류는 구형(iOS 18.6.2) 디코더가 잘못된 중복 jxlc 구조를 거부하는 것입니다. 핵심은 파싱이 발생했다는 점입니다.

현실 점검(솔직하게)

표면이 열려 있다고 해서 공개 PoC가 작동하는 제로클릭이라는 뜻은 아닙니다:

  • 149바이트 공개 트리거는 크래시를 일으키지 않습니다 — iOS 26.4.2, iOS 18.6.2, macOS 26.3.1에서 순수 CGImageSource 디코딩으로 테스트 시(MallocScribble 하에서 10/10 실행, 8배 중복 트리거 변형 포함).
  • 의도적으로 제작된 적대적 프레임 파일 배터리(조작된 frame_origin 오프셋, 실제 업스트림 수정이 강화하는 저메모리 렌더 파이프라인 경로를 겨냥 — libjxl PR #4495)도 iOS 26.4.2에서 깨끗하게 디코딩됩니다.
  • 작성자 자신의 분석 문서에서도 근본 원인 분석이 불완전할 수 있으며 크래시 증거가 interpose 라이브러리를 사용한 macOS Safari에서 생성되었다고 언급합니다.

따라서: 전달 0클릭은 입증되었습니다; 신뢰할 수 있는 트리거는 아닙니다. Apple이 패치한 버그는 실재합니다(DIFF.md 참조 — 저메모리 파이프라인 Plane/float 복사가 재작성되고 강화됨), 그러나 이를 iOS에서 결정적 메모리 손상으로 전환하는 것은 공개 아티팩트가 해결하지 못하는 무기화 문제입니다.

그래도 공개하는 이유

우리가 질문한 모든 사람(그리고 우리 자신의 EXR 실험)은 JPEG/PNG/HEIC가 아닌 첨부 파일이 Messages 미리보기에서 디코딩되지 않는다고 가정했습니다. JXL은 디코딩됩니다. 이는 제로클릭 공격 표면의 구체적이고 테스트 가능한 확장이며, AppleJPEGXL 버그는 WebContent만이 아니라 iMessage 전달을 염두에 두고 사냥할 가치가 있음을 의미합니다.

교육 및 방어 연구 목적입니다. 소유한 하드웨어에서만 테스트하십시오.

도구 다운로드