GHSA-x8r2-mggj-j6wr

NOTE: This was found during WordPress 7.1 target assessment coordinated by human, Alex Thomas (Wordfence Vulnerability Researcher) with Wordfence Argus, our agentic adversarial testing framework (AI). I verified the arbitrary file read and code execution impacts with the threat model being WordPress on Debian with the latest libheif 1.23.2 and with our developed proof-of-concept I was able to read /etc/passwd and execute arbitrary PHP code on the target. Successful exploitation is not universal and requirements are listed under "Current exploitation limitations include" below. I believe universal exploitation is plausible but difficult, based on my testing. Due to the complex nature of the this finding, the following report is AI-generated with some minor human edits.

libheif 1.23.2 contains a heap buffer overflow in its built-in ISO/IEC 23001-17 uncompressed-image ( unci ) decoder. In the mixed-interleave YCbCr path, the decoder permits paired Cb and Cr components to have different bit depths. It allocates each destination plane according to that plane's own component depth, but processes both chroma destinations using the first chroma entry's byte width and column offset.

The attached overflow.heif uses 16-bit Cb and 8-bit Cr. The Cr plane is allocated for one byte per sample but receives two-byte writes, causing a repeated heap out-of-bounds write. The bytes being written come from the crafted image's component data and are attacker-controlled.

The write was reproduced with AddressSanitizer against the official libheif 1.23.2 release. An equal-depth negative control decodes normally. The same input also causes a native glibc corruption abort through Fedora's materially different libheif 1.21.2 build.

I (Alex Thomas) independently demonstrated that this primitive can support attacker-selected file disclosure and command execution through one exact WordPress server-side image-processing deployment. Those exploitation results are build- and deployment-specific and do not imply universal RCE across libheif consumers.

The attached reproducer declares:

unc_decoder_legacybase::buildChannelListEntry() obtains the paired chroma plane but records only the current entry's component width:

unc_decoder_mixed_interleave::processTile() then reuses the current entry's width and column offset for both destinations:

The faulting path is:

For Y8/Cb16/Cr8 , entry.bytes_per_component_sample is two while the paired Cr destination was allocated for one byte per sample. The second chroma write therefore overruns the Cr heap allocation.

The issue is internal to libheif's unci decoder. It does not require libde265, AOM, dav1d, ImageMagick, WordPress, or another external codec or application. It does require libheif to be built with WITH_UNCOMPRESSED_CODEC=ON .

The primary validation used:

The additional external codec options describe the exact build but are not required by the vulnerable unci path.

Relationship to GHSA-2jg2-4ch7-h545

We believe this issue is distinct from GHSA-2jg2-4ch7-h545 . That advisory concerns derived iden / auxl constructions that create duplicate or incorrectly sized pixel planes, followed by consumers trusting the image's logical geometry. This report concerns a direct unci mixed-interleave decode where Cb and Cr have equal plane geometry but different bytes per sample. The faulty sink is the paired chroma write in unc_decoder_mixed_interleave.cc .

The 1.23.2 changes associated with GHSA-2jg2-4ch7-h545 do not modify unc_decoder_mixed_interleave.cc or unc_decoder_legacybase.cc . The attached reproducer continues to fault on official libheif 1.23.2, which contains the changes associated with that advisory.

submission-artifacts.zip

The attached submission-artifacts.zip contains:

overflow.heif — ready-to-decode Y8/Cb16/Cr8 positive reproducer;

control.heif — equal-depth Y8/Cb8/Cr8 negative control;

poc.py — auditable generator for both files;

upstream-seed.heif — unmodified libheif 1.23.2 test asset;

asan-output.txt — complete positive-case ASAN trace;

control-output.txt — successful negative-control output;

version-output.txt — runtime version confirmation;

fedora-1.21.2-output.txt — additional cross-build crash evidence;

VALIDATION.md and DEPLOYMENT-IMPACT-VALIDATION.md — provenance, commands, deployment evidence, and limitations; and

SHA256SUMS — integrity hashes.

Build the official 1.23.2 release with AddressSanitizer and WITH_UNCOMPRESSED_CODEC=ON , using the build configuration listed above.

The captured complete trace is asan-output.txt .

The captured output is control-output.txt .

The two inputs can be regenerated from the included unmodified upstream seed:

The regenerated files were compared byte-for-byte with the attached artifacts.

For the additional 1.21.2 check, the positive and negative files were decoded in separate processes through Fedora's public libheif C API. The control completed successfully. overflow.heif aborted with double free or corruption (!prev) and status 134. Official 1.21.2 source contains the same paired-width defect under the earlier class names. See fedora-1.21.2-output.txt .

At minimum, decoding the crafted file performs an attacker-controlled heap out-of-bounds write. Under ASAN this terminates the process. Without ASAN it corrupts adjacent heap data, and the number of corrupting writes scales with the chroma-plane dimensions.

I (Alex Thomas) manually reproduced concrete post-corruption impact through a clean WordPress 7.1 Media Library deployment with no plugins. An ordinary Author uploaded target-specific HEIF files through a server-side pipeline of PHP Imagick, ImageMagick, and official libheif 1.23.2. On that exact x86-64 Debian/glibc profile:

std::filesystem::copy_file copied /etc/passwd to an attacker-selected public upload destination; and

controlled C++ object dispatch invoked a harmless command that created /var/www/html/p.php containing ; requesting it returned HTTP 200 and rendered the PHP 8.2.33 information page.

A narrower self-copy route copied the still-open HEIF from /dev/fd/12 to a PHP-executable path, with harmless PHP carried in a valid trailing free box. Exact self-copy succeeded in 29 of 30 independent attempts against the warmed Apache prefork pool.

These deployment payloads used runtime DSO bases obtained from the authorized lab target. We separately recovered a live libheif q0 pointer and the exact libheif load bias from a WordPress-generated JPEG without using target process mappings. That disclosure does not directly resolve libstdc++, libc, or MagickCore. The current GOT-reading continuation is allocator-sensitive and failed before producing a derivative, so a complete remote ASLR bypass has not been demonstrated.

Current exploitation limitations include:

exact architecture, ABI, library builds, object layouts, and glibc heap behavior;

correct runtime DSO bases and build-relative offsets, or a complete self-calibration/address-independent replacement;

compatible allocator placement and worker/process continuity;

a reachable application upload path; clean WordPress Core normally requires upload_files , generally Author or higher;

source readability and destination writability by the image worker;

PHP execution in the selected destination for the PHP proof;

a current 15-byte, NUL-free source-path limitation for the file-copy proof; and

identification of the live input descriptor for the self-copy variant; FD 12 is not a cross-deployment constant.

The evidence supports an attacker-controlled heap write and demonstrates file-disclosure/code-execution potential on one exact deployment. It does not establish a portable, fully self-calibrating, or universal RCE exploit.

This candidate was found during an authorized, AI-assisted deep security review. The source path, current-release reproduction, differential control, deployment impact, and report claims were independently validated. I (Alex Thomas) personally reviewed the finding, manually reproduced the deployment results, and assumes responsibility for this submission.

This report and its artifacts are confidential. We will preserve the embargo and coordinate disclosure with the fixed release and GitHub advisory. Please credit Alex Thomas, Wordfence and Wordfence Argus (our agentic adversarial framework).