| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Chartbrew is an open-source web application for creating charts from databases and APIs. In versions 4.8.5 through 5.2.2, API connection creation and update operations accept the internal allowPrivateHost field from user input. An authenticated user with permission to manage API connections can enable this field to bypass private and reserved-network destination restrictions. An upgrade migration also enables the override on pre-existing API connections. The per-connection setting takes precedence over CB_ALLOW_PRIVATE_NETWORK_CALLS , so disabling that instance option does not protect connections with the override enabled. Successful exploitation allows requests to internal HTTP services reachable from the Chartbrew server, potentially disclosing information or triggering unauthorized actions depending on the target service. Recognized cloud metadata endpoints remain separately blocked. This issue is fixed in version 5.2.3. |
| Chartbrew is an open-source web application that can connect directly to databases and APIs and use the data to create charts. Prior to 5.2.1, the outbound URL guard recognized ordinary IPv4, IPv6, and IPv4-mapped IPv6 destinations but did not recognize IPv4 addresses embedded in NAT64 prefixes. The vulnerable surface is aPI Data Connection outbound requests routed through server/modules/outboundTargetPolicy.js. An authenticated user with permission to create or edit an API connection supplies an attacker-controlled hostname or redirect whose DNS answer is a NAT64 address embedding a private or link-local IPv4 destination. The policy treated the NAT64 address as public; a NAT64 gateway then translated it to the embedded private IPv4 address after validation. The bypass requires a NAT64/DNS64 deployment path and connection-management privileges. IPv4-only deployments are not affected by this specific bypass. The attacker can read responses from 169.254.169.254 cloud metadata and arbitrary internal IPv4 hosts and ports reachable through the NAT64 gateway. This issue is fixed in version 5.2.1. |
| 2FAuth is a web app to manage Two-Factor Authentication (2FA) accounts and generate their security codes. Prior to 8.0.0, the otpauth image-fetch path validates a hostname through ValidatesUrls::isExternalHost() and then lets IconService::storeRemoteImage() resolve the same hostname again for the HTTP request. When external otpauth image fetching is enabled, an authenticated user controlling low-TTL authoritative DNS can return a public address during validation and an internal address during the later connection, bypassing the private-address deny list to reach loopback, private-network, link-local, or cloud metadata endpoints. This issue is fixed in version 8.0.0. |
| 2FAuth is a web app to manage Two-Factor Authentication (2FA) accounts and generate their security codes. From 6.1.0 until 8.0.0, App\Services\Traits\ValidatesUrls::isPublicIp() does not recognize the 64:ff9b::/96 and 64:ff9b:1::/48 NAT64 prefixes, so an otpauth URI image parameter can pass an IPv6 literal or DNS64-synthesized address whose embedded IPv4 target is private, link-local, loopback, or cloud metadata. In a deployment with image fetching enabled and a NAT64 translation path to the internal IPv4 target, an account holder can submit the crafted URI directly, or an external attacker can induce a victim to import a crafted URI or migration payload. IconService::buildFromRemoteImage() then issues an HTTP GET to the embedded target, allowing image-shaped responses to be recovered or other endpoints to be probed blindly. This issue is fixed in version 8.0.0. |
| Server-side request forgery in the Jira ticketing filter lookup in Devolutions Server 2026.2.22.0 and earlier allows an authenticated low-privileged user to obtain the stored Jira service account credentials via an attacker-controlled server address in the request. |
| Server-side request forgery in the Active Directory credential validation in Devolutions Server 2026.3.12.0 and earlier allows an authenticated low-privileged user to capture the NetNTLMv2 hash of the DVLS service account via an attacker-controlled domain name in the request. |
| In JetBrains IntelliJ IDEA before 2026.3 blind SSRF was possible via remote references in JSON Schema validation |
| In WhatsUp Gold versions released before 2026.0.2, an unauthenticated remote attacker with network access to the affected service can execute arbitrary code in the context of the IIS application service account. |
| In Apache James server prior version 3.9.1 improper validation in JMAP webPush SSRF validation did lead to the possibility to reach internal addresses.
Users are recommended to upgrade to version 3.9.1 which fixes this issue. |
| CrewAI contains an SSRF vulnerability caused by its SSRF guard and HTTP client, which both miss malicious content in URLs by checking opposite content passed to it, enabling any request that injects a malicious URL to perform SSRF, such as with the ScrapWebsiteTool. |
| FreeScout is a self-hosted help desk and shared mailbox. Prior to 1.8.230, multiple outbound paths in Helper::downloadRemoteFile(), Helper::checkPort(), Helper::sanitizeRemoteUrl(), MailboxesController.php, and ModulesController.php do not consistently enforce a sink-level restricted-host policy. An authenticated administrator, or another authenticated user permitted to change mailbox connection settings or trigger module update or installation paths, can supply attacker-controlled URLs or hosts. The independent download and port-test sinks can reach encoded or otherwise uncovered loopback and internal addresses. The redirect-validation bypass additionally requires a configured whitelist that permits the original and final hosts while a restricted internal host appears only as an intermediate redirect hop. No unauthenticated SSRF path is established. The server can consequently contact loopback and internal services, provide a blind internal port oracle, and retrieve internal HTTP responses into application-controlled download sinks. This issue is fixed in version 1.8.230. |
| IBM ContextForge MCP Gateway 0.1.0 through 1.0.5 is vulnerable to a server-side request Forgery (SSRF) that allows authenticated users with gateway creation privileges to perform arbitrary HTTP POST requests to internal network resources and cloud metadata endpoints. The vulnerability occurs during OAuth-enabled gateway registration when the system fails to validate the oauth_config.token_url parameter. When registering a gateway with OAuth client credentials authentication, an attacker can supply a malicious token_url pointing to internal services, cloud metadata endpoints (AWS IMDSv1, GCP, Azure), or localhost-bound services. The application immediately performs an HTTP POST request to the attacker-controlled URL with form-encoded credentials in the body. If the response cannot be parsed as a valid OAuth token response, up to 256 characters of the response body are reflected back to the attacker in the HTTP 502 error message. This vulnerability bypasses existing SSRF protections that are applied to the gateway.url field but not to OAuth configuration parameters. |
| A flaw was found in the FTP GVfs backend. A malicious FTP server can exploit this vulnerability by providing an arbitrary IP address and port in its passive mode (PASV) response. The client unconditionally trusts this information and attempts to connect to the specified endpoint, allowing the malicious server to probe for open ports accessible from the client's network. |
| Wanderer is a self-hosted trail database for saving and sharing adventures. Prior to 0.20.0, when PUBLIC_PRIVATE_INSTANCE is not set to true, the unauthenticated POST /api/v1/trail/download handler passes the attacker-controlled JSON url field directly to event.fetch() and returns the fetched response. This allows requests to internal services such as db:8090 and search:7700, cloud metadata addresses, and other network destinations, exposing returned data and permitting internal network reconnaissance or denial of service. This issue is fixed in version 0.20.0. |
| Dify before 1.15.0 contains a server-side request forgery vulnerability that allows any authenticated console user to bypass SSRF protections and issue arbitrary HTTP requests to internal services and cloud metadata endpoints due to the Squid proxy configuration only defining source ACLs without destination deny rules and the make_request() helper performing no independent destination IP validation. Attackers can use endpoints such as GET /console/api/remote-files/<url>, POST /console/api/remote-files/upload, the HTTP Request workflow node, website crawl, or document import from URL to reach internal components like the sandbox, internal APIs, and PostgreSQL, and on AWS deployments read IAM credentials from the instance metadata service, with the HTTP Request node further enabling POST, PUT, and DELETE writes to internal services relying on network isolation for authorization. |
| In JetBrains IntelliJ IDEA before 2026.3 sSRF was possible via custom plugin repositories |
| RAGFlow before 0.27.0 contains a server-side request forgery vulnerability that allows authenticated attackers to force the server to issue requests to arbitrary internal or external endpoints by supplying an unvalidated base_url to the POST /v1/llm/set_api_key endpoint handled by set_api_key() in api/apps/llm_app.py. Attackers can exploit this flaw to probe shared-network services such as MySQL, Elasticsearch, Redis, MinIO, the Infinity vector database, and cloud metadata endpoints, with raw upstream exception text returned in the response leaking internal service details, open ports, and configuration fingerprints. |
| ERPNext OCR app for Frappe/ERPNext through 1.1.1 contains a missing authorization and path traversal vulnerability that allows any authenticated user to read arbitrary server files by passing a fully client-controlled path argument to the whitelisted read_document method. Attackers can supply local file paths to bypass Frappe's File doctype permission model and access other users' private uploads, or supply arbitrary URLs to trigger server-side requests reaching internal services and cloud metadata endpoints. |
| Kroki creates diagrams from textual descriptions. From 0.26.0 until 0.31.2, the optional Mermaid companion's mermaid/src/worker.js renders attacker-controlled flowchart image nodes in headless Chromium without a network request policy, even when KROKI_SAFE_MODE is set to secure. An actor who can submit Mermaid source and satisfy any authentication or authorization configured by the deployment can cause the companion to issue HTTP or HTTPS GET requests when requesting PNG output. Exploitation requires the Mermaid companion, PNG rendering through its headless Chromium process, a diagram-submission path available to the actor, and network reachability from the companion to the target. The demonstrated impact is limited to blind request reachability and possible state-changing GET endpoints; response exfiltration, cloud metadata access, port scanning, and access beyond the companion's network reachability are not established. This issue is fixed in version 0.31.2. |
| Server side request forgery vulnerability exists in the DLP on-prem extensions version 11.13.1 and earlier allows the file Prefix parameter in the OpenEventEvidenceFile.do endpoint accepts arbitrary UNC paths without validation. The server-side code attempts to open the specified file path, causing Windows to resolve the hostname and initiate SMB authentication to the attacker-controlled host. |
