CVE-2016-4543

JPEG photos often include extra information called “metadata.” PHP has code that reads this metadata for certain image features, and in older versions it can be tricked by a malformed photo so PHP crashes while reading it. In practice, that can mean your site slows down or stops working when someone uploads or triggers processing of a crafted image.

This matters if your business runs software that uses PHP and processes JPEG images in a way that triggers EXIF/metadata parsing (for example, image upload features or image tools that read EXIF fields). It is primarily a remote risk when an attacker can send a crafted JPEG to something your server will parse. If JPEG EXIF processing is not reachable from the internet (and there’s no user-uploaded/externally supplied JPEG that PHP will parse), this is much less relevant.

This is an availability-impact issue in PHP and it’s consistent with what attackers try first when they want to disrupt services. There is no confirmed KEV listing and no public exploit code on record, but predicted likelihood is rising, so you should treat this as an important update rather than a distant maintenance item.

1. Confirm exposure

   • Determine the exact PHP version running in each environment (production, staging, any worker containers).
   • Also confirm whether your application stack uses PHP’s EXIF/JPEG handling (commonly triggered when your code or libraries read EXIF metadata from JPEGs, or when server-side image processing is enabled).

2. Determine whether you’re reachable

   • Look for endpoints and features that accept user-controlled JPEG content, including:
     • Photo upload forms (profile pictures, product images)
     • Batch imports
     • Any “preview” or “analyze” feature that reads EXIF metadata
     • Image URLs that are fetched and processed server-side

3. Apply the fixed versions

   • Upgrade PHP so it is at least one of:
     • 5.5.35 or newer
     • 5.6.21 or newer
     • 7.0.6 or newer
   • If you maintain multiple PHP branches, upgrade each one used by the application.

4. If you can’t upgrade immediately (workaround)

   • Reduce exposure while you schedule the upgrade:
     • Restrict access to upload/process endpoints (authentication, rate limits, and abuse controls)
     • Enforce upload/content-type checks and strict file size limits
     • Avoid processing EXIF/metadata for uploads if your app allows turning that off

5. Verify after upgrade

   • Re-test the specific flows that handle JPEGs (upload, preview, background processing).
   • Check application and server logs for errors related to image/EXIF parsing during normal usage.

6. What to monitor

   • Watch for repeated crashes or fatal errors around times of uploads or image processing.
   • Review logs for unusual requests to image upload/processing endpoints.

Severity is reported as very high by scoring, but the findings emphasize an availability weakness. The underlying issue is a failure to validate EXIF Image File Directory (IFD) sizes inside exif_process_IFD_in_JPEG (ext/exif/exif.c) in affected PHP versions, which can lead to a denial of service via out-of-bounds read when processing crafted JPEG metadata. There is no entry in CISA KEV for this CVE, and no public exploit code was found in the provided findings. Exploit maturity is therefore not confirmed; however, the issue is associated with increasing attention/pressure and a rising predicted likelihood, so patching remains the right response. EPSS is not used as a deciding factor here beyond “not yet confirmed exploitation,” and the primary practical concern for many small businesses is service disruption caused by malformed JPEG uploads/inputs.