Crafted JPEGs Could Trigger PHP Memory Bugs for Exploitation

PHP, one of the most widely used web programming languages, is rarely viewed as a direct attack surface at its core level. Security focus typically shifts toward frameworks and third-party libraries.

However, new research shows that PHP’s built-in functionality specifically the ext/standard extension can expose critical risks when handling untrusted input such as image files.

These flaws demonstrate how even trusted core functions can become exploitable under specific conditions.

At the heart of PHP lies the Zend Engine, which compiles and executes PHP scripts. It includes components like the Zend VM (execution engine), compiler, memory manager, and OPcache for performance optimization.

During this process, built-in functions such as those for handling images interact directly with system memory via C code. This makes them particularly sensitive to memory handling bugs.

The ext/standard extension plays a crucial role here. It provides hundreds of core functions, including file handling and image metadata parsing.

Because these functions process user-controlled input (like uploaded images), vulnerabilities in this layer can have a wide impact.

Researchers in PT Swarm analyzed that C code behind PHP’s standard extension uncovered two memory safety issues affecting native image-processing functions: a heap memory disclosure in getimagesize() and a heap buffer overflow in iptcembed().

The first vulnerability, tracked as CVE-2025-14177 (CVSS 6.3), affects the getimagesize() function when parsing JPEG APP segments such as EXIF metadata.

When a PHP script runs, it follows a pipeline: tokenization, parsing into an abstract syntax tree, compilation into opcodes, and finally execution.

The issue arises from improper handling of chunked reads. When PHP reads large JPEG metadata in multiple chunks, it incorrectly writes each chunk to the same memory location instead of appending sequentially. As a result:

• The beginning of the buffer gets overwritten.
• The tail of the buffer remains uninitialized.
• Sensitive heap data may be leaked back to the user.

For example, a crafted JPEG file with a large APP1 (EXIF) segment can trigger multi-chunk reads. If an attacker understands the default chunk size (commonly 8192 bytes), they can structure the file to leak leftover memory fragments from the server process.

Researchers demonstrated this by embedding identifiable markers in memory and retrieving them via the vulnerable function confirming real data leakage.

Crafted JPEGs Trigger PHP Memory

The second issue affects the iptcembed() function, which inserts IPTC metadata into JPEG images. Unlike the first bug, this one can lead to a heap buffer overflow a more severe class of vulnerability.

The root cause lies in how PHP allocates memory. The function uses fstat() to determine file size and allocates a buffer accordingly. However, it continues reading input until EOF without verifying buffer limits.

This becomes dangerous when handling non-standard files like pipes (FIFO), where the file size is reported as zero. In such cases:

• PHP allocates a very small buffer.
• The input stream continues delivering data.
• Memory writes exceed buffer boundaries, causing overflow.

In a simple demonstration, researchers used a FIFO pipe to stream a crafted JPEG with a large payload. The result was a confirmed heap buffer overflow detected by AddressSanitizer, proving reliable exploitation.

PHP developers have addressed both issues with targeted fixes:

• For getimagesize(), the buffer pointer now advances correctly after each chunk read, preventing overwrites and uninitialized memory leaks.
• For iptcembed(), strict bounds checking was introduced to stop writes beyond allocated memory, safely terminating processing when limits are reached.

The function iptcembed (php-src/ext/standard/iptc.c) repacks a JPEG: it reads the input stream, parses markers (APP, SOS, and so on), and concurrently copies bytes into a new buffer (spoolbuf).

These vulnerabilities highlight a key lesson: even mature and widely trusted runtime components can harbor subtle but dangerous flaws especially when written in low-level languages like C.

For developers and security teams, the takeaway is clear. Functions that process files particularly images should never be blindly trusted. Validating inputs, limiting file sizes, and keeping PHP updated are essential steps to reduce exposure.

As attackers continue to explore unconventional entry points like image metadata, these findings reinforce the importance of scrutinizing every layer of the application stack even the ones long considered safe.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.