| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| MaxKB is an open-source AI assistant for enterprise. Prior to 2.8.1, MaxKB v2.8.0 and prior are vulnerable to a server-side request forgery (SSRF) bypass in the OSS file service URL fetch (chat/api/oss/get_url) endpoint. The vulnerability exists due to inconsistent URL parsing between the urlparse validation function and the requests HTTP client, allowing attackers to access internal network services. This vulnerability is fixed in 2.8.1. |
| A Server-Side Request Forgery (SSRF) vulnerability exists in MLflow versions prior to 3.9.0. The `_create_webhook()` function in `mlflow/server/handlers.py` accepts a user-controlled `url` parameter without validation, and the `_send_webhook_request()` function in `mlflow/webhooks/delivery.py` sends HTTP POST requests to this attacker-controlled URL. This allows an authenticated attacker to force the MLflow backend to send HTTP requests to internal services, cloud metadata endpoints, or arbitrary external servers. The lack of input sanitization, URL scheme filtering, or allowlist validation on the webhook URL enables exploitation, potentially leading to cloud credential theft, internal network access, and data exfiltration. |
| MaxKB is an open-source AI assistant for enterprise. MaxKB 2.8.0 and prior are vulnerable to a server-side request forgery (SSRF) bypass in the OSS file service URL fetch functionality due to inconsistent DNS resolution between validation and actual request execution, allowing attackers to access internal network services. This vulnerability is fixed in 2.8.1. |
| A flaw has been found in ItzCrazyKns Vane up to 1.12.1. This vulnerability affects unknown code of the file src/app/api/providers/route.ts of the component Model Provider API. This manipulation of the argument baseURL causes server-side request forgery. Remote exploitation of the attack is possible. The exploit has been published and may be used. The project was informed of the problem early through an issue report but has not responded yet. |
| MaxKB is an open-source AI assistant for enterprise. Prior to 2.9.1, SSRF via work_flow_template Import. Authenticated users can supply arbitrary URLs in work_flow_template.downloadUrl which are fetched server-side without any URL validation or internal IP filtering. This vulnerability is fixed in 2.9.1. |
| Bugsink is a self-hosted error tracking tool. Prior to 2.1.3, Bugsink’s webhook URL validation could be (partially) bypassed because of a mismatch in URL parsing. The original validation logic parsed webhook URLs with Python’s urllib.parse.urlparse, then sent the request with requests.post. For malformed inputs involving backslashes and @, those components can disagree about where the authority ends and which hostname is the real target. A URL may therefore appear to target an allowlisted public hostname during validation, while the HTTP client actually connects to a different host. This vulnerability is fixed in 2.1.3. |
| Interpretation Conflict vulnerability in benoitc hackney allows Server Side Request Forgery. hackney_url:normalize/2 URL-decodes the host component after the URL has been parsed into a #hackney_url{} record. OTP's uri_string:parse/1 and inet:parse_address/1 do not decode percent-escapes in the host, so a URL such as http://%31%32%37%2E%30%2E%30%2E%31/ is seen by a caller's allowlist validator with host %31%32%37%2E%30%2E%30%2E%31 (not an IP address), which passes the allowlist check. hackney's normalizer then decodes the host to 127.0.0.1 and opens a TCP connection to loopback. Because hackney:request/5 always calls hackney_url:normalize/2 with no opt-out, every request that takes a binary or list URL is affected. The same technique reaches cloud instance metadata services (169.254.169.254), RFC1918 networks, and any admin interface listening on localhost.
This issue affects hackney: from 0.13.0 before 4.0.1. |
| A server-side request forgery (SSRF) vulnerability was identified in GitHub Enterprise Server that allowed an unauthenticated attacker to send crafted requests to internal services by exploiting insufficient input validation in an upload endpoint. By injecting path traversal content into request parameters, an attacker could bypass the intended request flow and redirect internal API calls, potentially accessing internal services and exposing sensitive credentials. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.22 and was fixed in versions 3.16.20, 3.17.17, 3.18.11, 3.19.8, 3.20.4, and 3.21.1. This vulnerability was reported via the GitHub Bug Bounty program. |
| Karakeep is a elf-hostable bookmark-everything app. A Server-Side Request Forgery (SSRF) protection bypass vulnerability was identified in versions prior to 0.32.0 affecting redirect-following processing components. Although the application implements protections intended to prevent requests toward internal/private network destinations, these protections could be bypassed through crafted HTTP redirect chains. By leveraging attacker-controlled redirects, an authenticated user could cause vulnerable application components to initiate requests toward internally reachable Docker network services accessible from the application environment. The issue affected multiple processing paths, including crawler-related functionality and video download processing flows. Version 0.32.0 contains a patch. |
| e107 is a content management system (CMS). Prior to 2.3.4, you can access the local environment by specifying the URL of the local environment from "Image/File URL:" of "From a remote location" in "Media Manager" on the administrator screen. This vulnerability is fixed in 2.3.4. |
| A vulnerability in the Google Cloud Apigee SetIntegrationRequest policy allowed remote attackers to perform Server-Side Request Forgery (SSRF) and exfiltrate service account access tokens.
For successful exploitation, an administrator must initially establish an insecure configuration of the API proxy. |
| A security flaw has been discovered in calcom cal.diy up to 4.9.4. The affected element is the function validateUrlForSSRF of the file apps/web/app/api/logo/route.ts of the component Logo API. The manipulation results in server-side request forgery. It is possible to launch the attack remotely. Attacks of this nature are highly complex. The exploitability is described as difficult. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way. |
| Roundcube Webmail 1.6.x between 1.6.14 and 1.6.16,and 1.7.x before 1.7.1 has Insufficient Cascading Style Sheets (CSS) sanitization in HTML e-mail messages may lead to SSRF or Information Disclosure, e.g., if stylesheet links point to local network hosts. The issue stems from an insufficient fix for CVE-2026-35540. |
| WeKan before 8.35 contains a server-side request forgery vulnerability in webhook integration URL handling where the URL scheme field accepts any string without protocol restriction or destination validation. Attackers who can create or modify integrations can set webhook URLs to internal network addresses, causing the server to issue HTTP POST requests to attacker-controlled internal targets with full board event payloads, and can additionally exploit response handling to overwrite arbitrary comment text without authorization checks. |
| prompts.chat prior to commit 30a8f04 contains a server-side request forgery vulnerability in the Fal.ai media status polling feature that allows authenticated users to perform arbitrary outbound requests by supplying attacker-controlled URLs in the token parameter. Attackers can exploit the lack of URL validation to disclose the FAL_API_KEY in the Authorization header, enabling credential theft, internal network probing, and abuse of the victim's Fal.ai account. |
| Rob--W cors-anywhere instances configured as an open proxy allow unauthenticated external users to induce the server to make HTTP requests to arbitrary targets (SSRF). Because the proxy forwards requests and headers, an attacker can reach internal-only endpoints and link-local metadata services, retrieve instance role credentials or other sensitive metadata, and interact with internal APIs and services that are not intended to be internet-facing. The vulnerability is exploitable by sending crafted requests to the proxy with the target resource encoded in the URL; many cors-anywhere deployments forward arbitrary methods and headers (including PUT), which can permit exploitation of IMDSv2 workflows as well as access to internal management APIs. Successful exploitation can result in theft of cloud credentials, unauthorized access to internal services, remote code execution or privilege escalation (depending on reachable backends), data exfiltration, and full compromise of cloud resources. Mitigation includes: restricting the proxy to trusted origins or authentication, whitelisting allowed target hosts, preventing access to link-local and internal IP ranges, removing support for unsafe HTTP methods/headers, enabling cloud provider mitigations, and deploying network-level protections. |
| Typebot is a chatbot builder tool. In versions 3.15.2 and prior, the preview chat endpoint (POST /api/v1/typebots/{typebotId}/preview/startChat) allows unauthenticated users to achieve Server-Side Request Forgery (SSRF) by supplying a custom typebot definition with server-side code blocks. The fetch function exposed inside the isolated-vm sandbox calls Node.js native fetch without the SSRF validation (validateHttpReqUrl) that protects the HTTP Request block. This bypasses all SSRF mitigations added after GHSA-8gq9-rw7v-3jpr. Exploitation of this unauthenticated SSRF vulnerability can lead to cloud credential theft, internal network access and data exfiltration for any self-hosted Typebot deployments and hosted services. This issue has been fixed in version 3.16.0. |
| TypeBot is a chatbot builder tool. In versions prior to 3.16.0, SSRF protection for Webhook / HTTP Request blocks validates only the URL string, blocked hostname literals, and literal IP formats. It does not resolve DNS before allowing the request. As a result, a hostname such as ssrf-repro.example that resolves to 127.0.0.1, 169.254.169.254, or RFC1918/private space passes validation and is later fetched by the backend HTTP client. This enables server-side request forgery to loopback, cloud metadata, and private network targets. This issue has been resolved in version 3.16.0. |
| TypeBot is a chatbot builder tool. Versions 3.15.2 and prior contain an SSRF via Open Redirect Bypass as the HTTP Request block and Code block validate the initial request URL via validateHttpReqUrl() to block private IPs and cloud metadata hostnames. However, the HTTP clients (ky and fetch) follow 302 redirects without re-validating the redirect destination. An authenticated user can point a bot block to an attacker-controlled server that responds with a redirect to an internal IP, causing the Typebot server to reach internal services. An authenticated Typebot user can reach AWS metadata (169.254.169.254), private subnets, and container-internal services. Exploitable to extract cloud IAM credentials or probe internal APIs inaccessible from the internet. This issue has been fixed in version 3.16.0. |
| In Concrete CMS 9.5.0 and below, the RSS Displayer block accepts a feed URL from any page editor and fetches it server-side without validation enabling redirect-to-internal bypasses. The Concrete CMS security team gave this vulnerability a CVSS v.4.0 score of 2.1 with a vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:L/VA:N/SC:L/SI:N/SA:N. |
