| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A Server-Side Request Forgery (SSRF) vulnerability exists in nltk/nltk versions 3.9.4 and the current develop branch. The `nltk.pathsec.validate_network_url()` function, intended to prevent SSRF by rejecting internal network addresses, fails to reject IPs in the RFC 6598 shared address space (`100.64.0.0/10`). This occurs because Python's `ipaddress` module does not classify such addresses as `is_private` or `is_global`, and the current guard only checks `is_private` and a few explicit categories. An attacker who can influence a URL passed to NLTK's network-loading helpers can exploit this vulnerability to make a strict-mode application send requests to shared-address-space hosts, potentially exposing non-public infrastructure reachable from the application host. The impact is limited to SSRF-style confidentiality exposure, with no code execution claimed. |
| A server-side request forgery (SSRF) vulnerability was found in OpenStack Glance. The web-download image import method allows authenticated users to provide a URI from which the Glance service fetches data. Due to insufficient default host filtering, an attacker with standard tenant credentials can make Glance issue HTTP requests to arbitrary internal network hosts, including the cloud metadata service. The fetched response is stored as image data and can be downloaded by the attacker, enabling exfiltration of sensitive internal data such as cloud instance credentials. |
| A flaw was found in OpenStack Glance. The web-download image import method can bypass host-based blocklist filtering. When an operator configures disallowed_hosts with IP addresses to block access to internal services, an attacker can circumvent this protection by using a hostname that resolves to the blocked IP address. The hostname-to-IP resolution result is not used for blocklist comparison, allowing an authenticated user to force the Glance server to make requests to internal network services that were intended to be blocked. |
| OpenPanel before 2.3.0 contains an unauthenticated server-side request forgery vulnerability in the GET /tools/site-checker endpoint that accepts a fully client-controlled URL parameter with no private IP filtering or DNS-rebinding protection. Attackers can make the OpenPanel server issue requests to internal services, localhost, and cloud metadata endpoints, reading internal HTTP response titles, headers, status codes, and SSL certificate information. |
| OpenPanel before 2.3.0 contains an unauthenticated server-side request forgery vulnerability in the /misc/favicon and /misc/og endpoints that accept an attacker-supplied url parameter with insufficient validation. Attackers can force the API to fetch arbitrary internal hosts and cloud metadata endpoints, with small responses returned verbatim enabling credential theft and internal service enumeration. |
| Improper input validation of the auto-configuration account identifier in Snowflake JDBC Driver versions 4.2.0 through 4.3.3 allowed a credential-bearing login request to be redirected to an attacker-selected HTTPS endpoint. An attacker able to control the account value could cause the driver to transmit a reusable login credential to a host of their choosing and replay it to obtain the privileges granted to that credential. Successful exploitation requires an application using jdbc:snowflake:auto with a connections.toml section that omits an explicit host and a lower-trust principal able to set the account value; ordinary JDBC URLs are unaffected. The fix is available in Snowflake JDBC Driver version 4.3.4. Users must manually upgrade. |
| Missing Authentication for Critical Function, Server-Side Request Forgery (SSRF), and Use of Hard-coded Credentials in ASUS Control Center allow an unauthorized user to obtain the encryption key via an HTTP request, causing a local service to enable SSH on port 2222. The attacker can then log in with the hardcode credentials to obtain a root shell, enabling direct reading, writing, and deletion of data on ASUS Control Center, as well as remote control of all servers, PCs, and workstations within the company.
Refer to the 'Security Update for ASUS Control Center' section on the ASUS Security Advisory for more information. |
| Open edX Platform enables the authoring and delivery of online learning at any scale. Prior to commit 00b7c3c, the endpoint accepts user-supplied files[].url, performs a server-side fetch using "requests.get(url, allow_redirects=True)". The fetched bytes are then returned inside a ZIP response. This enables SSRF with response exfiltration. Redirect-following is enabled, and there is no timeout in the vulnerable fetch path. This issue has been patched via commit 00b7c3c. |
| PlaywrightCapture contains a server-side request forgery (SSRF) vulnerability in its favicon retrieval functionality. When only_global_lookup is enabled, the application validates the initial favicon URL to prevent requests to localhost, loopback, or other non-public network addresses. However, redirects followed by aiohttp were not subjected to the same validation.
An attacker able to influence the content of a page processed by PlaywrightCapture could specify a publicly reachable favicon URL that responds with an HTTP redirect to a local or otherwise restricted address, such as 127.0.0.1, localhost, or an internal network service. Because aiohttp automatically followed the redirect, the resulting request could bypass the application's local-address restrictions and cause the PlaywrightCapture host to issue HTTP requests to resources that should not be externally reachable.
Depending on the services reachable from the PlaywrightCapture host and how retrieved favicon data is subsequently exposed or processed, this could be used to probe internal HTTP services or potentially obtain information from otherwise inaccessible endpoints.
The patch introduces an aiohttp request middleware that applies the existing local-URL validation to every request in the redirect chain. Requests resolving to restricted/local destinations are rejected before they are issued. |
| A flaw was found in Red Hat Quay's repository-level mirror configuration
feature. The POST and PUT handlers in endpoints/api/mirror.py accept an
external_reference parameter without SSRF validation, unlike the
organization-level mirror handlers which apply validate_external_registry_url().
A repository administrator can supply a crafted hostname that causes the Quay
mirror worker to make requests via Skopeo to internal network services, cloud
metadata endpoints, or other resources not intended to be reachable from the
Quay application. |
| The Versa Director SD-WAN orchestration platform includes a Webhook feature for sending notifications to external HTTP endpoints. However, the "Add Webhook" and "Test Webhook" functionalities can be abused by an authenticated user to send crafted HTTP requests to localhost. This can be leveraged to execute commands on behalf of the versa user, who has sudo privileges, potentially leading to privilege escalation or remote code execution.
Exploitation Status:
Versa Networks is not aware of any reported instance where this vulnerability was exploited. Proof of concept for this vulnerability has been disclosed by third party security researchers.
Workarounds or Mitigation:
There are no workarounds to disable the GUI option. Versa recommends that Director be upgraded to one of the remediated software versions. |
| Wallos is an open-source, self-hostable personal subscription tracker. Prior to version 5.0.0, the fix for CVE-2026-33407 (GHSA-hhjq-82f8-m6rc, "SSRF via HTTP Proxy Environment Variable") hardened endpoints/logos/search.php by disabling cURL proxying (CURLOPT_PROXY = '' + CURLOPT_NOPROXY = '*'). However, Wallos ships a second, near-identical, unauthenticated logo-image search endpoint — endpoints/payments/search.php — that was not given the same hardening. It still passes the HTTP_PROXY/HTTPS_PROXY environment variable straight into CURLOPT_PROXY. This issue has been patched in version 5.0.0. |
| elFinder is an open-source file manager for web, written in JavaScript using jQuery UI. Prior to 2.1.70, elFinder URL uploads in php/elFinder.class.php can bypass server-side request forgery protections when PHP cURL is unavailable because validate_address() validates $info['ip'], but get_remote_contents() selects fsock_get_contents(), which connects to $arr['host'] and performs a second DNS resolution. An attacker able to submit a URL upload can use DNS rebinding to have the first resolution return a public address and the connection resolution return a loopback or private address, causing the internal HTTP response body to be stored as an uploaded file and made readable through elFinder. After a successful fetch, get_headers($url, true) separately requests the original hostname without reusing the validated and pinned connection, creating an additional blind server-side request forgery path even when curl_get_contents() is selected. This issue is fixed in version 2.1.70. |
| A server-side request forgery vulnerability in Progress MarkLogic Server before 11.3.6 and 12.0.3 allows an authenticated user with low-privileged roles to bypass protections for cloud instance metadata endpoints. Successful exploitation can disclose cloud credentials and compromise cloud resources accessible to the host instance. |
| Dell Cloud Disaster Recovery, versions 20.2 and prior, contain a Server-Side Request Forgery (SSRF) vulnerability. A low privileged attacker with remote access could potentially exploit this vulnerability, leading to Server-side request forgery. |
| Ollama fails to validate redirect destinations when pulling tensor-layer models, allowing unauthenticated attackers to redirect blob downloads to arbitrary hosts. An attacker can control a registry, serve a malicious tensor-layer manifest, and cause the server to issue GET requests to internal hosts including cloud metadata endpoints. |
| AVideo through commit c91b5975d contains a server-side request forgery vulnerability in the EPG parser that allows authenticated uploaders to fetch arbitrary internal URLs. An attacker can supply an internal URL via the epg_link parameter during video upload, which is validated only for syntax and later fetched server-side during EPG generation without SSRF protection checks. |
| LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. Prior to versions 1.88.6 and 1.96.2, any authenticated LiteLLM proxy user could redirect an outbound provider call to a destination the user controls and cause the proxy to send its configured provider credentials to that destination. Request validation in litellm/proxy/auth/auth_utils.py, litellm/proxy/common_request_processing.py, litellm/proxy/health_endpoints/_health_endpoints.py, litellm/proxy/image_endpoints/endpoints.py, and litellm/proxy/litellm_pre_call_utils.py used incomplete checks that did not cover every sensitive parameter or inspect equivalent values across nested request fields, path values, and bracket-notation form data. Routing and credential parameters including api_base, base_url, model_list, fallbacks, and litellm_credential_name could therefore be applied without clearing the operator's stored key, exposing upstream provider credentials and other configured secrets and permitting server-side requests to internal services reachable by the proxy. This issue is fixed in versions 1.88.6 and 1.96.2. |
| A Server-Side Request Forgery and supply chain flaw was found in the OpenShift Console Helm catalog proxy. A namespace tenant can plant a ProjectHelmChartRepository with an arbitrary URL that the console pod fetches server-side, bypassing tenant egress restrictions. Combined with catalog metadata poisoning and admin-mediated chart installation, this enables privilege escalation. |
| An authenticated SSRF flaw was found in the OpenShift Console Dev Console webhook helpers. User-supplied target URLs are fetched server-side without validation, with path neutralization enabling arbitrary endpoint targeting and full response reflection from the console pod's privileged network position. |
