Malicious JPEG files can trigger patched PHP memory safety flaws

PHP developers have patched two JPEG-related memory safety issues that could expose server memory or crash vulnerable applications when they process specially crafted image files.

The issues affect PHP’s standard extension, including the getimagesize and iptcembed functions. Both functions can be used by web applications that inspect image metadata, process uploads, or handle JPEG files on the server.

The most clearly tracked flaw is CVE-2025-14177, an information disclosure bug in getimagesize. A second issue, tracked in PHP’s project as GH-20582, involves a heap buffer overflow in iptcembed.

What the PHP JPEG flaws do

CVE-2025-14177 can cause getimagesize to leak uninitialized heap memory when PHP reads JPEG APP segments in multi-chunk mode. These segments often contain metadata such as EXIF, IPTC, or XMP data.

The bug sits in php_read_stream_all_chunks. When PHP reads a JPEG segment in several chunks, the vulnerable code can overwrite the start of a buffer instead of appending each chunk in order. That leaves part of the buffer filled with uninitialized memory.

If an application returns or stores this data, an attacker-controlled JPEG could expose fragments of process memory. The leaked content depends on what the PHP process handled before the vulnerable operation.

Issue	Affected function	Main impact	Status
CVE-2025-14177	getimagesize	Uninitialized heap memory disclosure	Patched
GH-20582	iptcembed	Heap buffer overflow and possible crash	Patched

Who is most exposed?

The greatest risk falls on applications that process untrusted image uploads. This includes content management systems, webmail platforms, profile photo uploaders, media libraries, thumbnail generators, and image CDNs.

A vulnerable application does not need to display the image publicly for risk to exist. The issue can appear when backend code analyzes the file, extracts metadata, or embeds IPTC data.

Public upload forms deserve the most attention because attackers can send crafted JPEG files directly to the application. Internal tools also need review if they process files from customers, partners, or outside sources.

Which PHP versions are affected?

CVE-2025-14177 affects several supported PHP branches before the patched versions. Administrators should update to the latest safe release available for their branch.

The National Vulnerability Database lists the affected ranges as PHP 8.1 before 8.1.34, PHP 8.2 before 8.2.30, PHP 8.3 before 8.3.29, PHP 8.4 before 8.4.16, and PHP 8.5 before 8.5.1.

PHP’s changelog also confirms fixes for the getimagesize memory disclosure and the iptcembed heap buffer overflow in the standard extension.

PHP branch	First fixed version for CVE-2025-14177
PHP 8.1	8.1.34
PHP 8.2	8.2.30
PHP 8.3	8.3.29
PHP 8.4	8.4.16
PHP 8.5	8.5.1

How the getimagesize memory leak works

JPEG files can contain APP0 through APP15 segments. Applications often read these sections to collect metadata, including camera data, author fields, and other embedded information.

Researchers at Positive Technologies found that PHP could mishandle these segments when reading them in chunks. A crafted file can force the vulnerable path and leave stale heap bytes inside returned metadata.

The official advisory rates CVE-2025-14177 at 6.3 under CVSS 4.0. That reflects an information disclosure issue, not a direct remote code execution flaw.

How the iptcembed overflow happens

The second issue affects iptcembed, a PHP function used to embed binary IPTC data into JPEG files. Researchers reported a heap buffer overflow when the function reads from certain stream types.

The bug appears when PHP allocates a buffer based on a size check, then continues reading data without enforcing the same capacity limit. In the reported test case, AddressSanitizer detected an out-of-bounds write in php_iptc_get1.

This kind of flaw can crash a process and may create broader risk depending on deployment details, memory layout, and how the function gets exposed through application code.

Why image processing bugs matter

Image upload features often look harmless to users, but they run complex parsers on attacker-controlled files. Metadata parsing makes the risk higher because an image can contain much more than pixels.

Attackers often look for upload endpoints because they accept files by design. If the backend processes those files with vulnerable libraries or runtime functions, the upload feature becomes part of the attack surface.

PHP remains widely used across content management systems, e-commerce platforms, forums, and custom business applications. That makes timely patching important even when a vulnerability has a medium severity score.

How administrators should respond

Administrators should inventory PHP versions across servers, containers, CI images, and hosting environments. Public-facing upload systems should receive priority.

Teams should also review custom code and plugins that call getimagesize, iptcembed, or metadata processing functions on user-supplied files. Image validation should not rely only on file extensions or MIME headers.

Where possible, image processing should run in a restricted environment with file size limits, strict timeouts, and minimal permissions. This reduces damage if another parser bug appears later.

• Upgrade PHP to a patched version in every supported branch.
• Prioritize systems that process public image uploads.
• Check containers and development images, not only production servers.
• Limit accepted image size and metadata size.
• Block unusual stream wrappers where the application does not need them.
• Run image processing with least privilege and strong isolation.
• Monitor upload endpoints for repeated malformed JPEG submissions.

What developers should check in application code

Developers should search for direct calls to getimagesize and iptcembed. They should also review libraries that wrap these functions for thumbnails, profile photos, content imports, or metadata extraction.

Applications should reject unexpected file types before deep processing. They should also strip unnecessary metadata when the application does not need it.

Security teams should treat image processing as a high-risk boundary when the file comes from an untrusted source. The safest design assumes that any parser can fail and limits what the process can access.

FAQ