🔒 Aisle Security Analysis

We found 3 potential security issue(s) in this PR:

1. 🟡 Potential image decompression bomb / CPU & memory exhaustion via HEIC→JPEG normalization (no pixel limits, conversion before size check)

Description

The new HEIC support normalizes image/heic/image/heif inputs by converting them to JPEG, but does not enforce any pixel/dimension limits before decoding/encoding. This creates a DoS vector:

• Input size is limited by limits.maxBytes, but a small HEIC can declare extremely large dimensions and trigger huge allocations during decode/encode ("decompression bomb").
• The code checks normalizedBuffer.byteLength > maxBytes after conversion; the expensive part (decode/encode) happens first and can OOM or consume CPU.
• The conversion uses native backends (sharp/libvips or /usr/bin/sips), which will perform full image decoding and can be CPU-intensive; repeated requests can exhaust CPU/process resources.

Vulnerable code (conversion performed without preflight dimension/pixel checks):

const normalizedBuffer = await convertHeicToJpeg(params.buffer);
if (normalizedBuffer.byteLength > params.limits.maxBytes) {
  throw new Error(`Image too large after HEIC conversion: ...`);
}

Related backend code shows sharp(buffer) is instantiated without limitInputPixels or other pixel caps:

return (buffer) => sharp(buffer, { failOnError: false });

Recommendation

Add pixel/dimension limits and fail fast before conversion.

Suggested approach:

1. Extend InputImageLimits with a maxPixels (and optionally maxWidth/maxHeight) similar to PDFs.
2. Before calling convertHeicToJpeg, read metadata and reject large images.
3. Configure sharp to enforce pixel limits during decode.
4. Consider concurrency limiting (queue) for expensive conversions.

Example (sharp backend):

​// image-ops.ts
const MAX_IMAGE_PIXELS = 20_000_000; // example

async function loadSharp(): Promise<(buffer: Buffer) => ReturnType<Sharp>> {
  const mod = (await import("sharp")) as unknown as { default?: Sharp };
  const sharp = mod.default ?? (mod as unknown as Sharp);
  return (buffer) => sharp(buffer, {
    failOnError: true,
    limitInputPixels: MAX_IMAGE_PIXELS,
  });
}

Example (call site preflight):

const meta = await getImageMetadata(params.buffer);
if (!meta || meta.width * meta.height > params.limits.maxPixels) {
  throw new Error("Image dimensions exceed pixel limit");
}
const normalizedBuffer = await convertHeicToJpeg(params.buffer);

For the /usr/bin/sips path, run sips -g pixelWidth -g pixelHeight first (already implemented as sipsMetadataFromBuffer) and reject over-limit images before converting.

2. 🟡 MIME allowlist bypass via fallback to user-/server-claimed Content-Type when sniffing fails

Description

normalizeInputImage() attempts to determine an image's MIME type using detectMime() (magic-number sniffing via file-type), but falls back to the caller-provided mimeType when sniffing returns undefined.

This creates a content-type spoofing path:

• Inputs:
  • Base64 sources: source.mediaType is user-controlled and defaults to "image/png".
  • URL sources: result.mimeType is derived from the remote server's Content-Type header.
• Failure mode: detectMime() returns undefined for content it cannot recognize (e.g., plain text or arbitrary bytes).
• Bypass: The code then uses the claimed MIME (params.mimeType) and only checks it against allowedMimes, allowing non-image data to be accepted as an allowed image type.

Concrete example (base64 spoofing):

• Send source.type="base64", omit mediaType (defaults to image/png), and set data to base64 of a non-image payload like "hello world".
• detectMime({buffer}) returns undefined (text has no magic signature), so sourceMime becomes "image/png" and passes the allowlist.

Security impact depends on downstream handling, but this breaks the intended guarantee that input_image actually contains an image. It can also unexpectedly route non-image payloads into image-processing paths (e.g., HEIC conversion) based solely on a spoofed MIME.

Recommendation

Do not trust the claimed/header MIME when magic-number detection fails for input_image.

Recommended: require successful sniffing and (optionally) enforce consistency with the claimed type.

Example fix:

const detected = normalizeMimeType(
  await detectMime({ buffer: params.buffer, headerMime: params.mimeType })
);
if (!detected) {
  throw new Error("Unsupported/unknown image format");
}
if (!params.limits.allowedMimes.has(detected)) {
  throw new Error(`Unsupported image MIME type: ${detected}`);
}
​// Optional: if a caller-supplied mimeType exists and is non-generic, require match
const claimed = normalizeMimeType(params.mimeType);
if (claimed && claimed !== detected) {
  throw new Error(`MIME mismatch: claimed ${claimed} but detected ${detected}`);
}

Additionally:

• For URL sources, consider passing the URL/path to detectMime({ filePath }) to improve accuracy.
• If you need a compatibility escape hatch, only allow fallback for a narrow set of known-safe cases, and/or validate by actually decoding the image with a safe library before acceptance.

3. 🔵 MIME allowlist bypass via HEIC/HEIF normalization returning JPEG without re-checking allowedMimes

Description

normalizeInputImage() enforces limits.allowedMimes against the source detected MIME type (sourceMime), but when the source is HEIC/HEIF it always converts and returns a JPEG payload (mimeType: "image/jpeg") without verifying that JPEG is also allowed.

This creates a policy bypass when operators configure a custom allowlist that permits HEIC/HEIF but forbids JPEG:

• Input check: allowedMimes is only checked for sourceMime (e.g., image/heic).
• Transformation: HEIC/HEIF is converted to JPEG.
• Output: returned InputImageContent.mimeType becomes image/jpeg even if allowedMimes does not include JPEG.

Vulnerable code:

const sourceMime = ...;
if (!params.limits.allowedMimes.has(sourceMime)) {
  throw new Error(`Unsupported image MIME type: ${sourceMime}`);
}
...
if (HEIC_INPUT_IMAGE_MIMES.has(sourceMime)) {
  const normalizedBuffer = await convertHeicToJpeg(params.buffer);
  return {
    type: "image",
    data: normalizedBuffer.toString("base64"),
    mimeType: "image/jpeg",
  };
}

Call path showing this can affect operator-configured policies:

• gateway.http.endpoints.responses.images.allowedMimes -> resolveResponsesLimits() -> extractImageContentFromSource() -> normalizeInputImage() -> image delivered to providers as { data, mimeType }.
  • src/gateway/openresponses-http.ts calls extractImageContentFromSource(imageSource, limits.images).
• Same pattern for OpenAI-compatible endpoint:
  • src/gateway/openai-http.ts calls extractImageContentFromSource(source, limits.images).

Because downstream code uses image.mimeType to construct provider requests and sometimes to infer filenames/extensions, this can violate MIME/type policy expectations and routing logic.

Recommendation

Enforce the allowlist against the final delivered MIME type (post-normalization), or split configuration into separate allowlists for source vs delivered types.

Minimal fix (validate output mime after normalization):

const sourceMime = ...;
if (!params.limits.allowedMimes.has(sourceMime)) {
  throw new Error(`Unsupported image MIME type: ${sourceMime}`);
}

if (HEIC_INPUT_IMAGE_MIMES.has(sourceMime)) {
  const normalizedMime = NORMALIZED_INPUT_IMAGE_MIME; // image/jpeg
  if (!params.limits.allowedMimes.has(normalizedMime)) {
    throw new Error(`Unsupported normalized image MIME type: ${normalizedMime}`);
  }

  const normalizedBuffer = await convertHeicToJpeg(params.buffer);
  ...
  return { type: "image", data: normalizedBuffer.toString("base64"), mimeType: normalizedMime };
}

Also update docs/config help to clarify whether images.allowedMimes applies to:

• the source MIME type,
• the delivered MIME type,
• or both (recommended).

If the intent is "allow HEIC but always normalize to JPEG", consider automatically requiring/adding image/jpeg when image/heic/image/heif is allowed, but document this behavior explicitly to avoid surprising policy broadening.

Analyzed PR: #38122 at commit 9d14504

_{Last updated on: 2026-03-06T16:34:04Z}

Greptile Summary

This PR adds HEIC/HEIF support to the Gateway HTTP input_image pipeline: the default MIME allowlist, Zod schema, docs, and tests are all extended consistently, and a new normalizeInputImage helper converts HEIC/HEIF buffers to JPEG via the existing convertHeicToJpeg primitive before they reach downstream providers.

Key observations:

• Scope creep in MIME detection: normalizeInputImage calls detectMime (magic-byte sniffing via fileTypeFromBuffer) on every image type, not only HEIC/HEIF. Previously the declared mediaType was used as-is; now the sniffed type takes precedence. For non-HEIC images whose declared type disagrees with their actual magic bytes, the behaviour changes — the sniffed type is used for the allowlist check and is returned downstream. Constraining the detectMime call to the HEIC branch only would keep the change within its stated scope.
• Non-hermetic HEIC tests: The new tests in input-files.fetch-guard.test.ts mock ./image-ops.js but leave ./mime.js unmocked, so the real fileTypeFromBuffer is invoked against synthetic test buffers. The tests pass because the fake data isn't recognised by file-type, but adding an explicit detectMime mock would make the unit tests properly isolated.
• Size guards are correctly ordered: pre-conversion byte cap prevents oversized inputs, post-conversion check catches cases where JPEG expansion exceeds the limit.
• Schema, docs, and CHANGELOG are all updated in sync with the runtime changes.

Confidence Score: 3/5

• Mostly safe to merge, but the unintended MIME-sniffing side-effect on non-HEIC images warrants attention before shipping.
• The HEIC conversion logic and size guards are correct, and all touched areas (schema, docs, tests, allowlist) are updated consistently. However, normalizeInputImage silently changes how MIME types are resolved for all image types — not just HEIC — because detectMime is called unconditionally. This is an unannounced behavior change that could cause legitimate non-HEIC images to be rejected or delivered with a different MIME if their declared type doesn't match their magic bytes. The missing detectMime mock in tests means this path isn't exercised in isolation.
• src/media/input-files.ts — specifically the normalizeInputImage function and its unconditional detectMime call for non-HEIC images.

_{Last reviewed commit: 9d14504}