Critical PHP Vulnerabilities Expose Servers to Remote Attacks

Key Takeaways

• Two critical memory-safety vulnerabilities have been discovered in PHP’s image-processing functions.
• These flaws could enable attackers to leak sensitive heap memory or trigger denial-of-service attacks using specially crafted JPEG files.
• Affected PHP versions include 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.
• Patches are available, and immediate updates are strongly recommended for all affected systems.

A cybersecurity researcher has uncovered two critical memory-safety vulnerabilities within PHP’s image-processing capabilities. These flaws, if exploited, could allow malicious actors to extract confidential data from server memory or initiate denial-of-service (DoS) attacks through the manipulation of JPEG image files.

The vulnerabilities were identified by Nikita Sveshnikov, a researcher at Positive Technologies, within PHP’s ext/standard extension. Specifically, the widely utilized getimagesize and iptcembed functions, which handle JPEG metadata and IPTC data respectively, were found to be susceptible.

PHP Memory Safety Vulnerabilities

The first vulnerability, identified as <a href="https://nvd.nist.gov/vuln/detail/CVE-2025-14177 and assigned a CVSS score of 6.3, presents an information disclosure risk. This flaw manifests when PHP’s getimagesize function processes JPEG APP segments in a multi-chunk reading configuration.

Affected PHP Versions and Root Cause

This particular vulnerability impacts PHP 8.1.* versions prior to 8.1.34, 8.2.* versions prior to 8.2.30, 8.3.* versions prior to 8.3.29, 8.4.* versions prior to 8.4.16, and 8.5.* versions prior to 8.5.1.

The core issue lies within the php_read_stream_all_chunks function, which incorrectly concatenates data chunks when reading JPEG application segments. During the processing of APP segments containing metadata like EXIF or IPTC, the function allocates uninitialized heap memory. Critically, it fails to increment the buffer pointer after each read operation. This oversight leads to subsequent data chunks overwriting the beginning of the buffer, leaving the trailing bytes uninitialized and exposing fragments of process memory.

Exploitation Scenario

Attackers can leverage this flaw by crafting malicious JPEG files containing large APP1 segments designed to be read across multiple chunks, especially when the default chunk size of 8,192 bytes is known. When applications process these tampered images via mechanisms like php://filter or other multi-chunk reading methods, uninitialized heap data—potentially containing sensitive information—is copied into the $info['APPn'] array returned by getimagesize.

This vulnerability poses a significant risk to systems with public-facing upload endpoints, content management systems that generate image thumbnails, webmail services, and image content delivery networks (CDNs) that perform server-side analysis of user-provided images. Remote attackers can exploit this flaw if they can compel a vulnerable PHP process to invoke getimagesize on attacker-controlled data.

Heap Buffer Overflow in iptcembed

The second vulnerability affects the iptcembed function, which is responsible for embedding binary IPTC data into JPEG images. This is a classic heap buffer overflow, stemming from a “measure once, read forever” flaw. The function allocates an output buffer based on a single fstat result but then proceeds to read data until the end-of-file (EOF) without performing any capacity checks.

Technical Details and TOCTOU

The root cause is 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 zero, causing the function to allocate an undersized buffer. Subsequently, the code copies input data into the spoolbuf buffer without validating available space, leading to out-of-bounds writes if the stream contains more data than the allocated capacity.

Furthermore, this vulnerability introduces a Time-of-Check to Time-of-Use (TOCTOU) race condition. In this scenario, regular files can grow in size after the initial fstat call but before the read operation completes. Attackers can exploit this by feeding substantial amounts of data through specially crafted JPEG structures that force the parser into a “read everything until EOF” mode, ultimately triggering heap corruption.

Both vulnerabilities exploit weaknesses in PHP’s Zend Engine memory management, specifically within functions that handle JPEG marker processing. The getimagesize flaw impacts the php_read_APP function, which processes application-specific segments (APP0-APP15) containing metadata such as EXIF coordinates, IPTC authorship details, and XMP data.

For CVE-2025-14177, the vulnerable code path initiates 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. This results in the final chunk overwriting the beginning of the buffer while leaving the tail section untouched, exposing uninitialized data.

The iptcembed buffer overflow manifests when processing M_APP13 or M_SOS (start of scan) markers. In these cases, the parser switches to php_iptc_read_remaining mode and continues copying data until EOF. The vulnerable php_iptc_get1 function advances the write pointer (poi) for every byte without performing checks against the allocated spoolbuf_end boundary, leading to the overflow.

Proof-of-Concept Demonstrations

Researchers successfully demonstrated both vulnerabilities through practical exploits. For the memory disclosure flaw, they created a minimal JPEG file with a large APP1 segment designed to be read across multiple 8,192-byte chunks. They then performed heap spraying with marker strings to fill memory and subsequently read the file via 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 showcased using a two-terminal setup involving named pipes (FIFO). One terminal executed PHP, reading from the pipe, while the other fed a crafted JPEG structure followed by 8MB of data. Because FIFOs report an st_size of zero, the allocated buffer was insufficient to contain the incoming stream, causing AddressSanitizer to detect the heap buffer overflow.

Patches and Remediation

PHP developers have addressed CVE-2025-14177 by modifying the php_read_stream_all_chunks function. The fix ensures that the buffer pointer is advanced after each read operation (buffer += read_now), guaranteeing the sequential appending of chunks. This correction was accompanied by a regression test, ext/standard/tests/image/gh20584.phpt, to prevent future reoccurrences.

For the IPTC embed vulnerability, developers introduced a spoolbuf_end parameter to the php_iptc_get1 and php_iptc_put1 functions, enabling robust bounds checking. The updated code now safely returns EOF when the buffer is full, preventing out-of-bounds writes.

What You Should Do

• Inventory Systems: Immediately identify all servers and containers running PHP. Prioritize public-facing systems, including upload endpoints, CMS thumbnail generators, webmail services, and image CDNs.
• Update PHP: Apply the latest patched PHP versions as soon as possible. The corrected versions are 8.1.34, 8.2.30, 8.3.29, 8.4.16, and 8.5.1 or later.
• Monitor Logs: Enhance monitoring for unusual activity related to image processing functions, especially around file uploads and image manipulation.
• Input Validation: While patches are critical, ensure robust input validation and sanitization for all user-uploaded content, particularly image files.

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.