phacility/phabricator · error · Exception

Unable to get image information with getimagesize(): %s

Error message

Unable to get image information with getimagesize(): %s

What it means

getImage() writes the file bytes to a TempFile and calls getimagesize() on it as a cheap pre-flight before decoding; getimagesize() returned false, meaning PHP could not recognize the data as any known image format. The trapped PHP warnings are appended. This fires before any GD work, so it is a data/format problem, not a memory or GD problem.

Source

Thrown at src/applications/files/transform/PhabricatorFileImageTransform.php:320

    // In particular, this defuses a resource exhaustion attack where the
    // attacker uploads a 40,000 x 40,000 pixel PNGs of solid white. These
    // kinds of files compress extremely well, but require a huge amount
    // of memory and CPU to process.

    $tmp = new TempFile();
    Filesystem::writeFile($tmp, $data);
    $tmp_path = (string)$tmp;

    $trap = new PhutilErrorTrap();
    $info = @getimagesize($tmp_path);
    $errors = $trap->getErrorsAsString();
    $trap->destroy();

    unset($tmp);

    if ($info === false) {
      throw new Exception(
        pht(
          'Unable to get image information with getimagesize(): %s',
          $errors));
    }

    list($width, $height) = $info;
    if (($width <= 0) || ($height <= 0)) {
      throw new Exception(
        pht(
          'Unable to determine image width and height with getimagesize().'));
    }

    $max_pixels = (4096 * 4096);
    $img_pixels = ($width * $height);

    if ($img_pixels > $max_pixels) {
      throw new Exception(
        pht(

View on GitHub (pinned to 5720a38cfe)

Solutions

  1. Inspect the actual bytes (file ./data or xxd | head) and re-upload a valid, supported raster image (GIF/JPEG/PNG/WebP per your PHP build).
  2. Pre-validate uploads with getimagesize() (or Phabricator's file type detection) before accepting them as images eligible for transforms.
  3. Skip transforms for formats you do not support (e.g. serve SVGs as-is instead of rasterizing).

Example fix

// before
$thumb = $file->applyTransform($xform); // throws on non-image data

// after
$info = @getimagesize($file->getURI());
if ($info === false) {
  return null; // not transformable; handle original only
}
$thumb = $file->applyTransform($xform);
Defensive patterns

Strategy: validation

Validate before calling

$info = @getimagesize($tmp_path);
if ($info === false) {
  // not a recognizable image: reject upload or skip transform
  return null;
}

Try / catch

try {
  $transformed = $file->applyTransform($xform);
} catch (Exception $ex) {
  $transformed = $file; // unreadable image data
}

Prevention

When it happens

Trigger: Transforming a file whose bytes are not a recognizable image: corrupted/truncated upload, a renamed non-image (e.g. .png that is actually HTML or a PDF), or an unsupported-by-PHP format (SVG, HEIC, AVIF depending on PHP version) that was labeled with an image/* MIME type.

Common situations: Clients that trust filename extensions when setting MIME type; drag-drop of SVGs into avatars/file storage where transforms are requested; interrupted uploads leaving truncated files; formats newer than the installed PHP.

Related errors


AI-assisted analysis of phacility/phabricator@5720a38cfe (2026-08-21). Data as JSON: /api/errors/b8a18f7bfcddaa23. Report an issue: GitHub.