Langflow webhook SSRF: what Sume will and won't call back
Sume job webhooks go only to public HTTPS URLs; localhost and private-network targets are rejected. What that means for a Langflow flow receiving them.
A Sume job webhook can only point at a public HTTPS URL. The docs say localhost, private-network and non-HTTPS URLs are rejected, so a Langflow instance on localhost or a private address can't receive them directly. Put the flow behind a public HTTPS endpoint, or poll the job instead.
Langflow v1.12.4 (published 2026-09-29) lists "fix: reject mixed blocked DNS answers with IP allowlists (#15334)" among its bug fixes; the release note gives no more detail, so this post does not describe the fix. Sume facts are from Webhooks, read 2026-10-01.
Where can a Sume webhook point?
Submit with mode: "webhook" and a webhook_url. The URL must be public HTTPS. Anything on localhost, a private network, or plain http is refused at submit. For a Format run, the errors page adds that a delivery is also refused if the URL is redirected or fails re-validation when Sume sends it.
| Target | Accepted? |
|---|---|
https://flows.example.com/hook (public) | Yes |
http://flows.example.com/hook | No, not HTTPS |
https://localhost:7860/... | No, localhost |
| A private-network address | No |
How should the receiving flow check a delivery?
Each delivery carries x-sume-webhook-timestamp and x-sume-webhook-signature: sume-v1=<hex_signature>. The signed string is the timestamp, a dot, and the raw body. During secret rotation the header can hold several sume-v1= entries, and any match is valid. Reject timestamps outside your replay window; the docs suggest five minutes. Verify against the raw bytes, before any JSON parsing a flow component might do. See also verifying signatures in Go.
What if the flow can't be public?
Webhook is one of four communication modes, and the docs say to keep a polling fallback in place alongside it. A flow on a private network can submit with async and poll jobs_status or GET /v1/jobs/:id from inside, with no inbound connection at all. Sources: Jobs and results.
Does a Langflow upgrade change any of this?
Not on the Sume side. Sume's rule is applied before it sends anything, whatever receives the call. What a Langflow release changes is how Langflow itself treats outbound addresses; read its release notes for that. To use Sume tools from Langflow, see Langflow as an MCP client with Sume.
Sources
Related posts
More in Integrations
- Make OpenAI Sora modules deprecated: use HTTP with Sume
Make's notes list the OpenAI Sora and Video modules as deprecated by Sept 24. Replace them with an HTTP module that submits a Sume video job and a webhook.
- Make webhook 300 requests per 10 seconds: Sume bulk callbacks
Make returns 429 above 300 webhook requests per 10 seconds. Sume treats a non-2xx callback as a failed attempt and retries up to 10 times, 30 seconds apart.
- Make webhook logs kept 3 days: recover a Sume result later
Make keeps webhook logs for 3 days (30 on Enterprise). A Sume result does not depend on them: store the job id, read job events, and redeliver the callback.
- Make webhook queue MCP tools: stuck items and Sume redelivery
When a webhook queue item looks stuck, check Make's queue and Sume's delivery status separately. Sume can re-POST a job's terminal event with Redeliver.
Written by Sume