fix(providers): allow HTTP for self-hosted vLLM endpoints

[waleedlatif1]

Summary

• Follow-up to fix(providers): pin vLLM provider endpoint to validated IP #5077 (SSRF validate+pin for the vLLM endpoint), which merged before this refinement could be added.
• Pass { allowHttp: true } to validateUrlWithDNS for the user-supplied vLLM endpoint so self-hosted vLLM served over plain http:// on a public host is accepted. Without this it's rejected with "must use https:// protocol".
• This only relaxes the protocol check. The private/reserved-IP blocklist (literal host + DNS-resolved IP) and the blocked-port list still apply, so the SSRF protection from fix(providers): pin vLLM provider endpoint to validated IP #5077 is fully intact — http://169.254.169.254, http://10.0.0.5, etc. remain blocked.
• Both reviewers on fix(providers): pin vLLM provider endpoint to validated IP #5077 flagged this (Greptile P2, Cursor Bugbot Medium); the base PR merged before it landed.

Type of Change

• Bug fix (security follow-up)

Testing

• apps/sim/providers/vllm/index.test.ts asserts the endpoint is validated with { allowHttp: true }; 15/15 pass.
• tsc --noEmit, biome check, bun run check:api-validation clean.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[waleedlatif1]

@greptile

[waleedlatif1]

@cursor review

[cursor]

PR Summary

Medium Risk
Touches attacker-controlled URL validation in a security-sensitive path; scope is a narrow protocol relaxation with existing SSRF controls unchanged.

Overview
Follow-up to SSRF validate-and-pin for user-supplied vLLM endpoints: validateUrlWithDNS now receives { allowHttp: true } so http:// self-hosted endpoints are not rejected for requiring HTTPS.

This only relaxes the protocol check; DNS pinning, private/reserved IP blocking, and blocked ports are unchanged. Operator-configured VLLM_BASE_URL is still not validated.

The vLLM provider test now expects the third argument on validateUrlWithDNS.

^{Reviewed by Cursor Bugbot for commit c20b538. Configure here.}

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit c20b538. Configure here.}

[greptile-apps]

Greptile Summary

This PR follows up on #5077 by passing { allowHttp: true } to validateUrlWithDNS for user-supplied vLLM endpoints, allowing self-hosted vLLM served over plain HTTP to be accepted without breaking the existing SSRF protection.

• index.ts: The single-line change adds { allowHttp: true } to the validateUrlWithDNS call. The private/reserved-IP blocklist, blocked-port check, and DNS-pinning via createPinnedFetch are all unchanged — only the protocol requirement is relaxed.
• index.test.ts: The existing "validates and pins" test is updated to assert the option is forwarded; all four SSRF-guard test cases (no-endpoint bypass, valid endpoint pinning, SSRF rejection, missing-IP rejection) continue to pass.

Confidence Score: 5/5

Safe to merge — the two-line production change only widens the accepted protocol from HTTPS-only to HTTP-or-HTTPS for user-supplied vLLM endpoints; all SSRF guards remain active.

The change is surgically small: one additional option forwarded to a well-tested validation function. The underlying validateUrlWithDNS already accepts the allowHttp flag and its behaviour is verified in its own suite. The vLLM provider's test suite confirms the option is passed through and that all four SSRF-protection paths (no endpoint, valid endpoint with pinning, blocked IP, unresolvable IP) continue to behave correctly. There are no new code paths that could silently bypass the blocklist.

No files require special attention.

Important Files Changed

Filename	Overview
apps/sim/providers/vllm/index.ts	Adds { allowHttp: true } to the validateUrlWithDNS call for user-supplied endpoints; only the protocol check is relaxed, the private-IP blocklist and DNS-pinning remain fully intact.
apps/sim/providers/vllm/index.test.ts	Updates the SSRF-protection test to assert that validateUrlWithDNS is called with { allowHttp: true }; all existing SSRF rejection and IP-pinning assertions are preserved.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant Client
    participant vllmProvider
    participant validateUrlWithDNS
    participant createPinnedFetch
    participant OpenAI SDK

    Client->>vllmProvider: "executeRequest(azureEndpoint="http://host")"
    vllmProvider->>validateUrlWithDNS: "validateUrlWithDNS(url, "vLLM endpoint", { allowHttp: true })"
    Note over validateUrlWithDNS: Accepts http:// or https://<br/>Still blocks private/reserved IPs<br/>Returns resolvedIP
    validateUrlWithDNS-->>vllmProvider: "{ isValid: true, resolvedIP: "X.X.X.X" }"
    vllmProvider->>createPinnedFetch: createPinnedFetch("X.X.X.X")
    createPinnedFetch-->>vllmProvider: pinnedFetch (undici, IP-locked)
    vllmProvider->>OpenAI SDK: new OpenAI({ baseURL, fetch: pinnedFetch })
    OpenAI SDK->>vllmProvider: chat.completions.create(payload)
    vllmProvider-->>Client: ProviderResponse

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant Client
    participant vllmProvider
    participant validateUrlWithDNS
    participant createPinnedFetch
    participant OpenAI SDK

    Client->>vllmProvider: "executeRequest(azureEndpoint="http://host")"
    vllmProvider->>validateUrlWithDNS: "validateUrlWithDNS(url, "vLLM endpoint", { allowHttp: true })"
    Note over validateUrlWithDNS: Accepts http:// or https://<br/>Still blocks private/reserved IPs<br/>Returns resolvedIP
    validateUrlWithDNS-->>vllmProvider: "{ isValid: true, resolvedIP: "X.X.X.X" }"
    vllmProvider->>createPinnedFetch: createPinnedFetch("X.X.X.X")
    createPinnedFetch-->>vllmProvider: pinnedFetch (undici, IP-locked)
    vllmProvider->>OpenAI SDK: new OpenAI({ baseURL, fetch: pinnedFetch })
    OpenAI SDK->>vllmProvider: chat.completions.create(payload)
    vllmProvider-->>Client: ProviderResponse

Loading

_{Reviews (1): Last reviewed commit: "fix(providers): allow HTTP for self-host..." | Re-trigger Greptile}

[greptile-apps]

Greptile Summary

This PR is a targeted follow-up to the SSRF hardening in #5077: it passes { allowHttp: true } to validateUrlWithDNS so that user-supplied vLLM endpoints served over plain HTTP are accepted. The private/reserved-IP blocklist, blocked-port check, and DNS-pinning via createPinnedFetch are completely untouched.

• index.ts: The only change is adding { allowHttp: true } to the validateUrlWithDNS call and updating the surrounding comment to explain the trade-off.
• index.test.ts: The corresponding mock assertion is updated to expect the new third argument; the existing rejection tests (e.g. http://169.254.169.254) confirm private IPs remain blocked under the relaxed protocol check.

Confidence Score: 5/5

Safe to merge — the change is a two-line delta that relaxes only the protocol check on user-supplied endpoints while leaving every other SSRF guard intact.

The diff is minimal and surgical: { allowHttp: true } is the only runtime change. Reading validateUrlWithDNS and validateExternalUrl confirms that the flag exclusively broadens the accepted protocol set from https: to http:|https: — the private-IP blocklist, blocked-port list, and DNS-pinning path are untouched. The test suite directly asserts the new option is forwarded and confirms that previously-blocked IPs (e.g. 169.254.169.254) remain rejected under the new flag.

No files require special attention.

Important Files Changed

Filename	Overview
apps/sim/providers/vllm/index.ts	Passes { allowHttp: true } to validateUrlWithDNS for user-supplied endpoints; all other SSRF guards (private-IP blocklist, port blocklist, DNS pinning) remain unchanged.
apps/sim/providers/vllm/index.test.ts	Updates the mock assertion to expect { allowHttp: true } as the third argument; all 4 SSRF-related tests and 11 functional tests are consistent and correct.

_{Reviews (1): Last reviewed commit: "fix(providers): allow HTTP for self-host..." | Re-trigger Greptile}