Submit #914946: Matthias-Wandel jhead v3.3 (commit 5007491, 3.08-66-g5007491) heap-buffer-overflow (Get16u)

Identification
Title: jhead Get16u Out-of-Bounds Read when Processing WebP EXIF Directory
Vendor: Matthias-Wandel
Product: jhead
Component: EXIF parsing, WebP EXIF directory processing
Vulnerable function: Get16u
Weakness: Heap buffer out-of-bounds read
CWE: CWE-125
Researcher: FortuneZ (GitHub: lingmaple)
Discovery date: 2026-07-27
Disclosure status: Public; not yet fixed upstream (issue open as of 2026-08-04)
Affected Versions
jhead commit 5007491 (3.08-66-g5007491): reproduced with AddressSanitizer. This is the repository HEAD at the time of the report.
The version is annotated as v3.3 (commit 5007491, 3.08-66-g5007491) in the public report.
As of the submission material date (2026-08-04), no upstream fix commit exists. No fixed release is identified. The status should be updated once the maintainer merges a fix.

Classification
Attack type: Local
Attack complexity: Low
Privileges required: None
User interaction: Required
Exploit availability: Public proof-of-concept
Proven impact: Application crash and loss of availability (out-of-bounds read)
Suggested severity: Medium
CVSS 3.1 score: 5.5
CVSS 3.1 vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H
Technical Description
jhead is affected by a heap buffer out-of-bounds read while parsing the EXIF chunk of a crafted WebP file. In ProcessExifDir (exif.c), the entry count is read with NumDirEntries = Get16u(DirStart) at line 504. This read happens before the directory bounds check at line 510 (if (DirEnd+4 > (OffsetBase+ExifLength))), so the check cannot protect the Get16u(DirStart) access itself.

A malicious sub-IFD link can point DirStart to within 1 byte of the end of the allocated EXIF buffer. Get16u then reads 2 bytes past the allocated region, producing a 1-byte out-of-bounds read. AddressSanitizer reports the heap-buffer-overflow and aborts jhead, causing denial of service when a user or automated image-processing workflow parses the malicious WebP file. No special command-line flags are required to trigger the bug.

The proven impact is an out-of-bounds read and process crash. The submission does not assert demonstrated confidentiality disclosure, code execution, or privilege escalation.

Proof of Concept
PoC archive: issue-98_poc.zip PoC URL: https://github.com/user-attachments/files/30397052/poc.zip

The PoC is a 166-byte malformed WebP file with a crafted EXIF chunk that causes DirStart to point near the buffer boundary.

Command:

# Build with AddressSanitizer
CC=afl-clang-fast CFLAGS="-fsanitize=address" make

# Trigger the crash (no special flags needed)
ASAN_OPTIONS="detect_leaks=0:halt_on_error=1" ./jhead poc.bin
Observed sanitizer result:

==1658266==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000059
READ of size 1 at 0x602000000059 thread T0
#0 in Get16u exif.c:331
#1 in ProcessExifDir exif.c:504
#2 in process_EXIF exif.c:1063
#3 in ReadWebpSections webpfile.c:129
#4 in ReadImgFile imgfile.c:76
#5 in ProcessFile jhead.c:491
#6 in main jhead.c:1150

0x602000000059 is located 1 bytes to the right of 8-byte region [0x602000000050,0x602000000058)
SUMMARY: AddressSanitizer: heap-buffer-overflow exif.c:331 in Get16u
==1658266==ABORTING
Root Cause
ProcessExifDir reads the IFD entry count via Get16u(DirStart) at line 504 before verifying that the directory pointer has enough room within the valid EXIF buffer range. The existing bounds check at line 510 validates the directory entry array as a whole but runs after the out-of-bounds read has already occurred. A crafted sub-IFD link can therefore position DirStart so that the 2-byte read crosses the buffer boundary.

Countermeasure
As of 2026-08-04 the upstream issue is still open and no fix commit is available. Environments that cannot wait for an upstream fix should:

Avoid processing untrusted WebP/EXIF files with the affected jhead build.
Run jhead in a sandboxed, low-privilege environment with resource limits.
Apply process timeouts, crash isolation, and failed-file quarantine for automated pipelines.
Pre-validate or transcode inputs with a trusted image library before invoking jhead.
Suggested fix direction: validate DirStart + 2 <= OffsetBase + ExifLength before calling Get16u(DirStart), and apply a consistent pre-read range check to all pointers derived from IFD links and offsets.

This entry should be updated with the fix commit and fixed release once the maintainer merges a patch.

References
Advisory/report: https://github.com/Matthias-Wandel/jhead/issues/98
PoC: https://github.com/user-attachments/files/30397052/poc.zip

• Quelle: ⚠️ https://github.com/Matthias-Wandel/jhead/issues/98
• Benutzer: fczhang (UID 97720)
• Einreichung: 04.08.2026 15:48 (vor 1 Monat)
• Moderieren: 13.09.2026 06:48 (1 month later)
• Status: Akzeptiert
• VulDB Eintrag: 403214 [Matthias-Wandel jhead bis 3.3 EXIF Parsing exif.c Get16u Information Disclosure]
• Punkte: 20