🔒 Aisle Security Analysis

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

1. 🟡 MIME type spoofing allows non-image content to bypass image MIME allowlist in normalizeInputImage

Description

normalizeInputImage now skips MIME sniffing for all non-HEIC declared MIME types and trusts the caller-controlled params.mimeType.

This enables content-type confusion / validation bypass:

• Input: params.mimeType comes from attacker-controlled sources:
  • base64 images: source.mediaType (data URI / request JSON fields)
  • URL images: HTTP Content-Type from an attacker-controlled origin
• Change/regression: for any declared MIME not in HEIC_INPUT_IMAGE_MIMES, the code no longer calls detectMime() on the actual bytes.
• Impact: an attacker can declare an allowed image MIME (e.g., image/png) while sending bytes that are actually a different (potentially disallowed) file type (e.g., PDF/ZIP/HTML). The allowlist check is then performed against the declared MIME, not the actual content.
  • Previously, detectMime({buffer}) (via file-type) would often identify many non-image payloads (e.g., application/pdf) causing rejection.

Vulnerable behavior introduced in this change:

• sourceMime becomes declaredMime for non-HEIC inputs without verifying the buffer.

Recommendation

Do not rely on a declared MIME type for security decisions.

Mitigations (choose one depending on desired strictness/perf):

1. Restore sniffing for all images and validate that the detected type is an allowed image MIME:

const declaredMime = normalizeMimeType(params.mimeType) ?? "application/octet-stream";
const detected = normalizeMimeType(await detectMime({ buffer: params.buffer, headerMime: params.mimeType }));

​// If we can detect a concrete type, prefer it.
const sourceMime = detected ?? declaredMime;

​// Optional hardening: if declared claims image/* but detected is a non-image, reject.
if (declaredMime.startsWith("image/") && detected && !detected.startsWith("image/")) {
  throw new Error(`Invalid image content: detected ${detected} for declared ${declaredMime}`);
}

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

2. At minimum, if declaredMime is an allowed image type, ensure the buffer looks like an image (magic bytes) and reject if detectMime() identifies a non-image (e.g., application/pdf, application/zip).

Also consider logging/auditing mismatches (declaredMime vs detected) to catch abuse.

Analyzed PR: #38146 at commit 3552736

_{Last updated on: 2026-03-06T17:02:22Z}

Greptile Summary

This PR is a targeted follow-up to the HEIC input_image feature (#38122), fixing two regressions it introduced:

1. MIME sniffing scope: All images were being passed through detectMime(), unintentionally changing behavior for non-HEIC inputs. The fix gates detectMime behind a HEIC_INPUT_IMAGE_MIMES check in normalizeInputImage() (lines 238-242 of src/media/input-files.ts), ensuring only declared HEIC/HEIF inputs trigger MIME sniffing. Non-HEIC images now use their declared MIME directly, preserving backward compatibility.

2. Budget accounting: maxTotalImageBytes was counting pre-conversion HEIC base64 size. The fix in resolveImagesForRequest() (lines 300-312 of src/gateway/openai-http.ts) now:

   • Checks pre-extraction bytes early to avoid expensive conversion when already over budget
   • Always counts post-extraction bytes (post-JPEG normalization) against the total
   • This ensures HEIC→JPEG-inflated payloads are correctly charged against the configured limit

Test coverage is comprehensive and hermetic:

• input-files.fetch-guard.test.ts (line 102-125): Verifies non-HEIC images skip detectMime via mock assertions
• openai-http.image-budget.test.ts (line 21-40): Confirms normalized payloads are counted post-extraction
• openai-http.image-budget.test.ts (line 42-67): Verifies unchanged payloads aren't double-counted

CHANGELOG entry (line 141) accurately documents the follow-up changes.

Confidence Score: 5/5

• This PR is safe to merge—it tightens two well-scoped regressions with clear tests and no behavioral changes outside the stated scope.
• All three code changes (MIME scoping, budget accounting, test hermeticity) are logically correct and verified by comprehensive tests. The budget accounting correctly counts post-extraction bytes for all source types, and the early-rejection fast-path for base64 is safe because HEIC→JPEG conversion typically produces larger (not smaller) payloads. The MIME sniffing is properly scoped to declared HEIC/HEIF inputs only, verified by explicit test assertions. No security surface changes, no API contract changes, and non-HEIC behavior is explicitly locked by a new test.
• No files require special attention.

_{Last reviewed commit: 3552736}