🔒 Aisle Security Analysis

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

1. 🟠 fal image provider allows API key exfiltration / SSRF via unvalidated configurable baseUrl

Description

The fal image generation provider constructs request URLs from cfg.models.providers.fal.baseUrl and sends the fal API key in the Authorization header without validating the scheme/host or applying SSRF protections.

Impact if an attacker can influence req.cfg (e.g., by modifying runtime config / models.json, or via any config-write surface):

• Credential exfiltration: requests (including Authorization: Key ...) can be redirected to an attacker-controlled origin by setting models.providers.fal.baseUrl.
• SSRF: baseUrl can be set to internal/private network targets (e.g., http://127.0.0.1:..., http://169.254.169.254/...) and the server will make authenticated requests there.
• Redirect handling: because this uses raw fetch(), redirects are handled by the runtime fetch implementation; headers like Authorization may be forwarded depending on implementation, increasing exfil risk.

Vulnerable code:

const direct = cfg?.models?.providers?.fal?.baseUrl?.trim();
return (direct || DEFAULT_FAL_BASE_URL).replace(/\/+$/u, "");
...
await fetch(`${resolveFalBaseUrl(req.cfg)}/${model}`, {
  headers: { Authorization: `Key ${auth.apiKey}` },
});

Notes on configuration flow (threat model context):

• req.cfg is propagated from the runtime config passed to generateImage() (see src/image-generation/runtime.ts) and is typically sourced from loadConfig() in tool/agent flows (e.g., src/agents/tools/image-generate-tool.ts).
• Config write RPCs (e.g., config.patch/config.apply) exist and are admin-scoped, but the provider should still fail closed because the base URL controls where secrets are sent.

Recommendation

Fail closed on unsafe baseUrl overrides and apply SSRF/redirect protections before sending credentials.

Suggested approach:

1. Parse and validate the base URL:
   • require https:
   • block userinfo (username:password@​host)
   • restrict host to known fal API domains (or require an explicit allowCustomHost flag)
2. Use the existing SSRF/redirect-safe fetch wrapper (fetchWithSsrFGuard) so that:
   • private/internal networks are blocked by default
   • cross-origin redirects drop unsafe headers like Authorization

Example patch sketch:

import { fetchWithSsrFGuard } from "../../infra/net/fetch-guard.js";

function resolveFalBaseUrlSafe(cfg: OpenClawConfig | undefined): string {
  const raw = (cfg?.models?.providers?.fal?.baseUrl ?? DEFAULT_FAL_BASE_URL).trim();
  const u = new URL(raw);
  if (u.protocol !== "https:") throw new Error("fal baseUrl must be https");
  if (u.username || u.password) throw new Error("fal baseUrl must not include userinfo");

  ​// Option A: strict allowlist
  const host = u.hostname.toLowerCase();
  if (host !== "fal.run" && !host.endsWith(".fal.run")) {
    throw new Error("fal baseUrl host is not allowed");
  }
  return u.toString().replace(/\/+$/u, "");
}

​// Then replace raw fetch with guarded fetch
const { response, release } = await fetchWithSsrFGuard({
  url: `${resolveFalBaseUrlSafe(req.cfg)}/${model}`,
  init: {
    method: "POST",
    headers: { Authorization: `Key ${auth.apiKey}`, "Content-Type": "application/json" },
    body: JSON.stringify(requestBody),
  },
  timeoutMs: 60_000,
  ​// Optionally: policy: { hostnameAllowlist: ["fal.run", "*.fal.run"] }
});
try {
  ​// handle response
} finally {
  await release();
}

If custom endpoints/proxies are required, gate them behind an explicit config flag (e.g., models.providers.fal.allowCustomHost: true) and still enforce HTTPS + SSRF policy.

2. 🟡 SSRF via unvalidated image URL download in fal image provider

Description

The new fal image-generation provider downloads image bytes from a URL returned by the upstream API without any validation or SSRF protection.

• payload.images[].url is treated as trusted and passed directly to fetch().
• No allowlist of fal media hosts, no scheme restriction, and no private-network blocking is applied.
• Node/undici fetch() follows redirects by default (redirect: "follow"), so even if a trusted host is returned, an attacker-controlled/open redirect could pivot the request to internal hosts (e.g., 169.254.169.254, localhost).

Vulnerable code:

const downloaded = await fetchImageBuffer(url);

async function fetchImageBuffer(url: string) {
  const response = await fetch(url);
  ...
}

Recommendation

Route all remote URL fetching through the existing SSRF-guarded utilities in this repo (they already implement private-network blocking + safe redirect handling with pinned DNS):

• Prefer fetchRemoteMedia() from src/media/fetch.ts (supports SSRF guard + redirect limit + size limits).
• Enforce https: and an allowlist for fal media domains (e.g. *.fal.media, and any other documented CDN hostnames).
• Keep redirects limited and re-validated on each hop (the guard already does this).

Example fix (sketch):

import { fetchRemoteMedia } from "../../media/fetch.js";

const FAL_MEDIA_POLICY = {
  ​// Only allow fal media/CDN hosts; do NOT allow private network.
  hostnameAllowlist: ["*.fal.media"],
};

async function fetchImageBuffer(url: string) {
  const parsed = new URL(url);
  if (parsed.protocol !== "https:") {
    throw new Error("fal image URL must be https");
  }

  const result = await fetchRemoteMedia({
    url,
    maxBytes: 15 * 1024 * 1024,      // pick an appropriate cap
    maxRedirects: 3,
    readIdleTimeoutMs: 10_000,
    ssrfPolicy: FAL_MEDIA_POLICY,
  });

  return {
    buffer: result.buffer,
    mimeType: result.contentType ?? "image/png",
  };
}

If fal provides signed URLs or an SDK method to fetch assets safely, prefer that over arbitrary URL fetching.

3. 🟡 fal image provider allows unbounded image dimensions/count leading to resource & cost exhaustion

Description

The fal image-generation provider forwards caller-controlled sizing and image-count parameters to the upstream API without enforcing the provider’s own advertised limits (supportedSizes, supportedResolutions) or applying defensive caps.

Impact:

• Cost/DoS amplification: callers can request extremely large width/height (via size like 99999x99999) and/or very large count, potentially triggering expensive upstream work.
• Local memory pressure: the provider also downloads generated images into memory via fetchImageBuffer() with no max-bytes limit, compounding DoS risk if large images (or many images) are returned.

Vulnerable code (size parsing accepts up to 5 digits per dimension and returns it unbounded):

const match = /^(\d{2,5})x(\d{2,5})$/iu.exec(trimmed);
...
return { width, height };

Related sink (unbounded forwarding of size/count):

• image_size: imageSize (from req.size / req.resolution)
• num_images: req.count ?? 1

Call chain / existing validation:

• src/agents/tools/image-generate-tool.ts enforces count to 1-4 for the image_generate tool, but does not validate size beyond being a string.
• src/image-generation/runtime.ts forwards size, count, and resolution directly to providers with no additional validation.
• Therefore, untrusted tool callers can abuse size, and any plugin code calling generateImage() can abuse both size and count unless it adds its own validation.

Recommendation

Enforce strict provider-side limits before sending requests upstream, and cap downloads.

1. Restrict size to supported values (or apply hard caps):

const SUPPORTED_SIZES = new Set(["1024x1024","1024x1536","1536x1024","1024x1792","1792x1024"]);

function resolveSafeFalImageSize(size?: string, resolution?: "1K"|"2K"|"4K") {
  const trimmed = size?.trim();
  if (trimmed && SUPPORTED_SIZES.has(trimmed)) {
    const [w,h] = trimmed.split("x").map((v) => Number.parseInt(v, 10));
    return { width: w, height: h };
  }
  ​// fall back to resolution mapping / default
  return mapResolutionToSize(resolution) ?? DEFAULT_OUTPUT_SIZE;
}

2. Clamp count (even if the tool currently limits it) to defend other call sites:

const MAX_COUNT = 4;
const count = Math.min(Math.max(1, req.count ?? 1), MAX_COUNT);

3. Cap image downloads from returned URLs by using existing limited-fetch helpers (e.g. fetchRemoteMedia/readResponseWithLimit) with a reasonable maximum (e.g. MAX_IMAGE_BYTES):

import { fetchRemoteMedia, MAX_IMAGE_BYTES } from "../../media/fetch.js";
​// or a shared helper that enforces maxBytes

This ensures attacker-controlled or unexpected upstream responses cannot exhaust memory.

Analyzed PR: #49454 at commit c546c18

_{Last updated on: 2026-03-18T05:26:26Z}

Greptile Summary

This PR adds a bundled fal provider to image_generate, wiring FAL_KEY auth and defaulting onboarding to fal/fal-ai/flux/dev for both text-to-image and single-image edit (FLUX image-to-image) flows. The implementation follows the same shape as the existing Google and OpenAI image providers and the extension entry/onboard pattern matches other bundled providers.

Key findings:

• fileExtensionForMimeType does not strip MIME type parameters (; charset=…) before extracting the extension, which can produce malformed filenames like image-1.png; charset=utf-8 if the fal CDN ever includes such parameters.
• The downloaded.mimeType || entry.content_type fallback on line 183 is dead code — fetchImageBuffer always returns a non-empty mimeType, so entry.content_type is never consulted. This is misleading.
• Multi-image responses are downloaded sequentially inside a for…of loop rather than with Promise.all, which serialises independent HTTP fetches unnecessarily when count > 1.

Confidence Score: 3/5

• Safe to merge after addressing the MIME type parameter stripping bug in fileExtensionForMimeType; the other two findings are style/performance improvements.
• The core provider logic is correct and well-tested. One logic issue (malformed filenames from unstripped MIME type parameters) can cause incorrect file extensions in production if the CDN ever includes content-type parameters. The dead fallback code and sequential downloads are lower-severity concerns. The PR is otherwise well-structured and consistent with existing providers.
• src/image-generation/providers/fal.ts — fileExtensionForMimeType and the image download loop need attention.

This is a comment left during a code review.
Path: src/image-generation/providers/fal.ts
Line: 83-93

Comment:
**MIME type parameters not stripped from file extension**

`fileExtensionForMimeType` takes the raw `Content-Type` header value from `fetchImageBuffer`, which can include parameters separated by `;` (e.g. `image/png; charset=UTF-8`). The current slicing logic will produce a file name like `image-1.png; charset=utf-8` because it only looks for the `/` separator and doesn't account for `;`-delimited parameters.

While CDNs rarely add such parameters to image responses, the fal CDN is not guaranteed to omit them forever. Splitting on `;` before slicing would make this robust:

```suggestion
function fileExtensionForMimeType(mimeType: string | undefined): string {
  const normalized = mimeType?.toLowerCase().trim().split(";")[0]?.trim();
  if (!normalized) {
    return "png";
  }
  if (normalized.includes("jpeg")) {
    return "jpg";
  }
  const slashIndex = normalized.indexOf("/");
  return slashIndex >= 0 ? normalized.slice(slashIndex + 1) || "png" : "png";
}
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/image-generation/providers/fal.ts
Line: 178-184

Comment:
**Dead fallback to `entry.content_type`**

`fetchImageBuffer` always returns a non-empty `mimeType` — it defaults to `"image/png"` when the `Content-Type` header is absent. This means `downloaded.mimeType` is always truthy and `entry.content_type` is never reached. The fallback creates a misleading impression that there is a safety net here.

```suggestion
          fileName: `image-${imageIndex}.${fileExtensionForMimeType(downloaded.mimeType)}`,
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/image-generation/providers/fal.ts
Line: 171-185

Comment:
**Sequential image downloads for multi-image requests**

When `count > 1` and fal returns multiple image URLs, each URL is downloaded sequentially with a separate `await fetchImageBuffer(url)` inside the `for...of` loop. For a request that returns, say, 4 images, this serialises 4 independent HTTP fetches. Using `Promise.all` over the filtered URLs would download them in parallel and noticeably reduce latency for multi-image responses:

```typescript
const urls = (payload.images ?? [])
  .map((entry) => entry.url?.trim())
  .filter((url): url is string => Boolean(url));

const downloaded = await Promise.all(urls.map((url) => fetchImageBuffer(url)));

const images: GeneratedImageAsset[] = downloaded.map((dl, i) => ({
  buffer: dl.buffer,
  mimeType: dl.mimeType,
  fileName: `image-${i + 1}.${fileExtensionForMimeType(dl.mimeType)}`,
}));
```

How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: "Image generation: ad..."}