Malicious JPEG Images Exploit PHP Memory Safety Could Trigger

Two critical memory-safety vulnerabilities in PHP’s image-processing functions could allow attackers to leak sensitive heap memory or to execute denial-of-service attacks via specially crafted JPEG files.

The flaws, discovered in PHP’s ext/standard extension by Positive Technologies researcher Nikita Sveshnikov, affect the widely-used getimagesize and iptcembed functions that process JPEG metadata and IPTC data.

PHP Memory Safety Vulnerabilities

The first vulnerability, tracked as CVE-2025-14177 with a CVSS score of 6.3, enables information disclosure when PHP’s getimagesize function processes JPEG APP segments in multi-chunk reading mode.

Affected versions include PHP 8.1.* before 8.1.34, 8.2.* before 8.2.30, 8.3.* before 8.3.29, 8.4.* before 8.4.16, and 8.5.* before 8.5.1.

The vulnerability stems from a bug in the php_read_stream_all_chunks function that incorrectly concatenates data chunks when reading JPEG application segments. When processing APP segments containing metadata such as EXIF or IPTC data, the function allocates uninitialized heap memory.

However, it fails to increment the buffer pointer after each read. This causes subsequent chunks to overwrite the beginning of the buffer, leaving the tail bytes uninitialized and exposing fragments of process memory.

Attackers can exploit this flaw by crafting JPEG files with large APP1 segments designed to be read across multiple chunks, particularly when the default chunk size of 8,192 bytes is known.

When applications process these malicious images through php://filter or other multi-chunk reading mechanisms, uninitialized heap data containing potentially sensitive information gets copied into the $info[‘APPn’] array returned by getimagesize.

The attack surface is particularly concerning for public-facing upload endpoints, content management systems that generate thumbnails, webmail services, and image CDNs that perform server-side analysis of user-uploaded images.

Remote attackers can leverage the vulnerability if they can cause a vulnerable PHP process to call getimagesize on attacker-controlled data.

Heap Buffer Overflow in iptcembed

The second vulnerability affects the iptcembed function, which embeds binary IPTC data into JPEG images.

This classic heap buffer overflow occurs due to a “measure once, read forever” flaw: the function allocates an output buffer based on a single fstat result. It continues reading data until EOF without capacity checks.

The root cause lies in how iptcembed handles non-standard file types such as FIFOs, pipes, and sockets. For these file types, the st_size field returned by fstat is 0, causing the function to allocate an undersized buffer.

The code then copies input data into the spoolbuf buffer without verifying available space, resulting in out-of-bounds writes when the stream contains more data than is allocated.

This vulnerability also introduces a time-of-check to time-of-use (TOCTOU) race condition in which regular files can grow in size after fstat but before the read operation completes.

Attackers can exploit this by feeding large amounts of data through specially crafted JPEG structures that force the parser into “read everything until EOF” mode, triggering heap corruption.

Both vulnerabilities exploit weaknesses in PHP’s Zend Engine memory management, specifically in functions handling JPEG marker processing.

The getimagesize flaw affects the php_read_APP function, which processes application-specific segments (APP0-APP15) that contain metadata such as EXIF coordinates, IPTC authorship information, and XMP data.

For CVE-2025-14177, the vulnerable code path begins when getimagesize allocates memory using emalloc, which returns uninitialized memory pointers.

If multi-chunk reading occurs, the php_stream_read macro writes to the same destination address without applying offsets for already-read bytes, causing the final chunk to overwrite the buffer’s beginning while leaving the tail section untouched.

The iptcembed buffer overflow manifests when processing M_APP13 or M_SOS (start of scan) markers, where the parser switches to php_iptc_read_remaining mode and copies data until EOF.

The vulnerable php_iptc_get1 function advances the write pointer (poi) for every byte without checking against the allocated spoolbuf_end boundary.

Researchers demonstrated both vulnerabilities through practical exploits. For the memory disclosure flaw, they created a minimal JPEG with a large APP1 segment designed to be read across multiple 8,192-byte chunks, performed heap spraying with marker strings to fill memory, then read the file through php://filter to force multi-chunk processing.

The proof-of-concept successfully leaked the marker string “LEAK-MARKER-123!” from uninitialized heap memory.

The iptcembed overflow was demonstrated using a two-terminal setup with named pipes (FIFO), where one terminal ran PHP reading from the pipe while another fed a crafted JPEG structure followed by 8MB of data.

Since FIFOs report st_size as zero, the allocated buffer was too small to contain the incoming stream, triggering AddressSanitizer to detect the heap buffer overflow.

Patches and Remediation

PHP developers addressed CVE-2025-14177 by modifying php_read_stream_all_chunks to advance the buffer pointer after each read operation (buffer += read_now), ensuring sequential chunk appending.

The fix was accompanied by a regression test ext/standard/tests/image/gh20584.phpt to prevent future occurrences.

For the IPTC embed vulnerability, developers added a spoolbuf_end parameter to the php_iptc_get1 and php_iptc_put1 functions to enforce bounds checking. The updated code now safely returns EOF when the buffer is full, rather than writing out of bounds.

Organizations should immediately inventory all hosts and containers running PHP, prioritizing public-facing upload endpoints, CMS thumbnailers, webmail systems, and image CDNs. Updates should be applied to the latest patched versions: 8.1.34, 8.2.30, 8.3.29, 8.4.16, or 8.5.1 and above.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.