IBM WebSphere Application Server 9.0, and 8.5 is vulnerable to server-side request forgery (SSRF) with the Ajax Proxy configured. This may allow an attacker to send unauthorized requests from the system, resulting in a security bypass or information disclosure.

PublicCMS V5.202506.b is vulnerable to SSRF. in the chat interface of SimpleAiAdminController.

Crawl4AI <=0.4.247 is vulnerable to SSRF in /crawl4ai/async_dispatcher.py.

A SSRF vulnerability in WADL service description in versions of Apache CXF before 4.0.5, 3.6.4 and 3.5.9 allows an attacker to perform SSRF style attacks on REST webservices. The attack only applies if a custom stylesheet parameter is configured.

A Server-Side Request Forgery (SSRF) in the installUpdateThemePluginAction function of WonderCMS v3.1.3 allows attackers to force the application to make arbitrary requests via injection of crafted URLs into the installThemePlugin parameter.

JizhiCMS v2.5.4 was discovered to contain a Server-Side Request Forgery (SSRF) via the component \c\PluginsController.php. This vulnerability allows attackers to perform an intranet scan via a crafted request.

A critical vulnerability has been identified in givanz VvvebJs 1.7.2, which allows both Server-Side Request Forgery (SSRF) and arbitrary file reading. The vulnerability stems from improper handling of user-supplied URLs in the "file_get_contents" function within the "save.php" file.

An SSRF issue in REBUILD v.3.5 allows a remote attacker to obtain sensitive information and execute arbitrary code via the FileDownloader.java, proxyDownload,URL parameters.

Server Side Request Forgery (SSRF) vulnerability in Friendica versions after v.2023.12, allows a remote attacker to execute arbitrary code and obtain sensitive information via the fpostit.php component.

Server-side request forgery vulnerability in Energy Management Controller with Cloud Services JH-RVB1 /JH-RV11 Ver.B0.1.9.1 and earlier allows a network-adjacent unauthenticated attacker to send an arbitrary HTTP request (GET) from the affected product.

Whoogle Search is a self-hosted metasearch engine. In versions 0.8.3 and prior, the `window` endpoint does not sanitize user-supplied input from the `location` variable and passes it to the `send` method which sends a `GET` request on lines 339-343 in `request.py,` which leads to a server-side request forgery. This issue allows for crafting GET requests to internal and external resources on behalf of the server. For example, this issue would allow for accessing resources on the internal network that the server has access to, even though these resources may not be accessible on the internet. This issue is fixed in version 0.8.4.

A Server-Side Request Forgery (SSRF) vulnerability was identified in the @opennextjs/cloudflare package. The vulnerability stems from an unimplemented feature in the Cloudflare adapter for Open Next, which allowed unauthenticated users to proxy arbitrary remote content via the /_next/image endpoint. This issue allowed attackers to load remote resources from arbitrary hosts under the victim site’s domain for any site deployed using the Cloudflare adapter for Open Next.  For example: https://victim-site.com/_next/image?url=https://attacker.com In this example, attacker-controlled content from attacker.com is served through the victim site’s domain (victim-site.com), violating the same-origin policy and potentially misleading users or other services. Impact: * SSRF via unrestricted remote URL loading * Arbitrary remote content loading * Potential internal service exposure or phishing risks through domain abuse Mitigation: The following mitigations have been put in place: * Server side updates to Cloudflare’s platform to restrict the content loaded via the /_next/image endpoint to images. The update automatically mitigates the issue for all existing and any future sites deployed to Cloudflare using the affected version of the Cloudflare adapter for Open Next * Root cause fix https://github.com/opennextjs/opennextjs-cloudflare/pull/727  to the Cloudflare adapter for Open Next. The patched version of the adapter is found here  @opennextjs/cloudflare@1.3.0 https://www.npmjs.com/package/@opennextjs/cloudflare/v/1.3.0 * Package dependency update https://github.com/cloudflare/workers-sdk/pull/9608  to create-cloudflare (c3) to use the fixed version of the Cloudflare adapter for Open Next. The patched version of create-cloudflare is found here:  create-cloudflare@2.49.3 https://www.npmjs.com/package/create-cloudflare/v/2.49.3 In addition to the automatic mitigation deployed on Cloudflare’s platform, we encourage affected users to upgrade to @opennext/cloudflare v1.3.0 and use the remotePatterns https://nextjs.org/docs/pages/api-reference/components/image#remotepatterns filter in Next config https://nextjs.org/docs/pages/api-reference/components/image#remotepatterns if they need to allow-list external urls with images assets.

A Server-Side Request Forgery (SSRF) in the automatic short URL title resolution component of shlink v5.0.1 allows attackers to scan internal resources via supplying a crafted longUrl.

Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), Improper Input Validation, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel Solr component. The camel-solr producer copies Exchange message headers whose names begin with the SolrParam. prefix into the parameters of the Solr request, and headers whose names begin with the SolrField. prefix into the fields of the indexed Solr document. The prefix constants (SolrConstants.HEADER_PARAM_PREFIX / HEADER_FIELD_PREFIX) were the plain strings SolrParam. / SolrField.. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a solr: producer, any HTTP client could therefore set SolrParam.* headers to inject arbitrary Solr request parameters - including shards or stream.url, which cause the Solr server to issue server-side requests to an attacker-chosen URL (server-side request forgery, for example to an internal service or a cloud metadata endpoint), or qt to reach administrative request handlers - and set SolrField.* headers to inject arbitrary fields into indexed documents. No credentials are required when the bridging consumer is unauthenticated. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that set Solr parameters or fields via the raw header prefixes must use CamelSolrParam. / CamelSolrField. instead of SolrParam. / SolrField.. For deployments that cannot upgrade immediately, strip the SolrParam.* and SolrField.* headers from any untrusted ingress before the solr: producer, and set the required Solr parameters and fields from a trusted source in the route.

Improper Input Validation, Server-Side Request Forgery (SSRF) vulnerability in Apache Camel DNS component. The camel-dns producers read DNS operation parameters - the resolver to query, the name or domain to look up, the record type and class, and the search term - from Exchange message headers whose constant values (DnsConstants.DNS_SERVER, DNS_NAME, DNS_DOMAIN, DNS_TYPE, DNS_CLASS, TERM) were the plain strings dns.server, dns.name, dns.domain, dns.type, dns.class and term. Because these names do not start with the Camel / camel prefix, HttpHeaderFilterStrategy - which blocks only the Camel header namespace on the HTTP boundary - let them pass from an inbound HTTP request straight into the Exchange. In a route that bridges an HTTP consumer (for example platform-http) into a dns: producer, any HTTP client could therefore set the dns.server header to make the dig producer build a SimpleResolver pointing at an attacker-controlled DNS server - a server-side request forgery via DNS, through which the attacker observes the queried name and can return poisoned responses - and set the dns.name / dns.domain headers to resolve arbitrary internal hostnames, disclosing whether they exist (internal network reconnaissance). No credentials are required when the bridging consumer is unauthenticated. This issue affects Apache Camel: from 4.0.0 before 4.14.8, from 4.15.0 before 4.18.3, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.21.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.8. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.3. After upgrading, routes that drive DNS operations via the raw header names must use CamelDnsServer / CamelDnsName / CamelDnsDomain / CamelDnsType / CamelDnsClass / CamelDnsTerm instead of the dns.* / term names. For deployments that cannot upgrade immediately, strip the dns.* and term headers from any untrusted ingress before the dns: producer, and set the DNS server and lookup parameters from a trusted source in the route.

Microsoft Exchange Server Remote Code Execution Vulnerability

pyLoad is a free and open-source download manager written in Python. In 0.5.0b3.dev96 and earlier, pyLoad has a server-side request forgery (SSRF) vulnerability. The fix for CVE-2026-33992 added IP validation to BaseDownloader.download() that checks the hostname of the initial download URL. However, pycurl is configured with FOLLOWLOCATION=1 and MAXREDIRS=10, causing it to automatically follow HTTP redirects. Redirect targets are never validated against the SSRF filter. An authenticated user with ADD permission can bypass the SSRF fix by submitting a URL that redirects to an internal address.

XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.16, there is a vulnerability where the processed stream at unmarshalling time contains type information to recreate the formerly written objects. XStream creates therefore new instances based on these type information. An attacker can manipulate the processed input stream and replace or inject objects, that result in a server-side forgery request. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16.

AVideo is a video-sharing Platform. Versions prior to 8.0 contain a Server-Side Request Forgery vulnerability (CWE-918) in the public thumbnail endpoints getImage.php and getImageMP4.php. Both endpoints accept a base64Url GET parameter, base64-decode it, and pass the resulting URL to ffmpeg as an input source without any authentication requirement. The prior validation only checked that the URL was syntactically valid (FILTER_VALIDATE_URL) and started with http(s)://. This is insufficient: an attacker can supply URLs such as http://169.254.169.254/latest/meta-data/ (AWS/cloud instance metadata), http://192.168.x.x/, or http://127.0.0.1/ to make the server reach internal network resources. The response is not directly returned (blind), but timing differences and error logs can be used to infer results. The issue has been fixed in version 8.0.

WWBN AVideo is an open source video platform. Prior to version 26.0, a Server-Side Request Forgery (SSRF) vulnerability exists in `plugin/Live/standAloneFiles/saveDVR.json.php`. When the AVideo Live plugin is deployed in standalone mode (the intended configuration for this file), the `$_REQUEST['webSiteRootURL']` parameter is used directly to construct a URL that is fetched server-side via `file_get_contents()`. No authentication, origin validation, or URL allowlisting is performed. Version 26.0 contains a patch for the issue.

LoLLMs WEBUI provides the Web user interface for Lord of Large Language and Multi modal Systems. A critical Server-Side Request Forgery (SSRF) vulnerability has been identified in all known existing versions of `lollms-webui`. The `@router.post("/api/proxy")` endpoint allows unauthenticated attackers to force the server into making arbitrary GET requests. This can be exploited to access internal services, scan local networks, or exfiltrate sensitive cloud metadata (e.g., AWS/GCP IAM tokens). As of time of publication, no known patched versions are available.

DataHub is an open-source metadata platform. The DataHub frontend acts as a proxy able to forward any REST or GraphQL requests to the backend. The goal of this proxy is to perform authentication if needed and forward HTTP requests to the DataHub Metadata Store (GMS). It has been discovered that the proxy does not adequately construct the URL when forwarding data to GMS, allowing external users to reroute requests from the DataHub Frontend to any arbitrary hosts. As a result attackers may be able to reroute a request from originating from the frontend proxy to any other server and return the result. This vulnerability was discovered and reported by the GitHub Security lab and is tracked as GHSL-2022-076.

2FAuth is a web app to manage Two-Factor Authentication (2FA) accounts and generate their security codes. Prior to 6.1.0, a blind SSRF vulnerability exists in 2FAuth that allows authenticated users to make arbitrary HTTP requests from the server to internal networks and cloud metadata endpoints. The image parameter in OTP URL is not properly validated for internal / private IP addresses before making HTTP requests. While the previous fix added response validation to ensure only valid images are stored but HTTP request is still made to arbitrary URLs before this validation occurs. This vulnerability is fixed in 6.1.0.

NextChat, also known as ChatGPT-Next-Web, is a cross-platform chat user interface for use with ChatGPT. Versions 2.11.2 and prior are vulnerable to server-side request forgery and cross-site scripting. This vulnerability enables read access to internal HTTP endpoints but also write access using HTTP POST, PUT, and other methods. Attackers can also use this vulnerability to mask their source IP by forwarding malicious traffic intended for other Internet targets through these open proxies. As of time of publication, no patch is available, but other mitigation strategies are available. Users may avoid exposing the application to the public internet or, if exposing the application to the internet, ensure it is an isolated network with no access to any other internal resources.

A blind Server-Side Request Forgery (SSRF) vulnerability was found in Moodle. This flaw exists due to insufficient validation of user-supplied input in LTI provider library. The library does not utilise Moodle's inbuilt cURL helper, which resulted in a blind SSRF risk. An attacker can send a specially crafted HTTP request and trick the application to initiate requests to arbitrary systems. This vulnerability allows a remote attacker to perform SSRF attacks.

hopetree izone lts c011b48 contains a server-side request forgery (SSRF) vulnerability in the active push function as \\apps\\tool\\apis\\bd_push.py does not securely filter user input through push_urls() and get_urls().

A security issue was discovered in WeBid <=1.2.2. A Server-Side Request Forgery (SSRF) vulnerability in the admin/theme.php file allows remote attackers to inject payloads via theme parameters to read files across directories.

ndk design NdkAdvancedCustomizationFields 3.5.0 is vulnerable to Server-side request forgery (SSRF) via rotateimg.php.

Anyscale Ray 2.6.3 and 2.8.0 allows /log_proxy SSRF. NOTE: the vendor's position is that this report is irrelevant because Ray, as stated in its documentation, is not intended for use outside of a strictly controlled network environment

IBM Cognos Analytics 11.1.7 11.2.0, and 11.2.1 could be vulnerable to a Server-Side Request Forgery Attack (SSRF) attack by constructing URLs from user-controlled data. This could enable attackers to make arbitrary requests to the internal network or to the local file system. IBM X-Force ID: 234180.

The Kirki WordPress plugin before 6.0.12 does not validate a user-supplied URL before requesting it server-side, allowing unauthenticated attackers to make the site issue HTTP requests to arbitrary hosts (Server-Side Request Forgery).

QD 20230821 is vulnerable to Server-side request forgery (SSRF) via a crafted request

The does not validate a parameter before making a request to it, which could allow unauthenticated users to perform SSRF attack

maccms10 v2025.1000.4047 has a Server-Side Request Forgery (SSRF) vulnerability via Add Article.

SoftVision webPDF before 10.0.2 is vulnerable to Server-Side Request Forgery (SSRF). The PDF converter function does not check if internal or external resources are requested in the uploaded files and allows for protocols such as http:// and file:///. This allows an attacker to upload an XML or HTML file in the application, which when rendered to a PDF allows for internal port scanning and Local File Inclusion (LFI).

A Server-Side Request Forgery (SSRF) in the getFileBinary function of nbnbk cms 3 allows attackers to force the application to make arbitrary requests via injection of arbitrary URLs into the URL parameter.

Kity Minder v1.3.5 was discovered to contain a Server-Side Request Forgery (SSRF) via the init function at ImageCapture.class.php.

Server side request forgery (SSRF) vulnerability in makeplane plane 0.23.1 via the password recovery.

Jizhicms v2.5.4 is vulnerable to Server-Side Request Forgery (SSRF) in User Evaluation, Message, and Comment modules.

Server-Side Request Forgery (SSRF) vulnerability exists in the URL processing functionality of PHProxy version 1.1.1 and prior. The input validation for the _proxurl parameter can be bypassed, allowing a remote, unauthenticated attacker to submit a specially crafted URL

Esri Portal for ArcGIS 11.4 and prior allows a remote, unauthenticated attacker to bypass the Portal’s SSRF protections.

The 'wp_ajax_boost_proxy_ig' action allows administrators to make GET requests to arbitrary URLs.

Best Practical RT for Incident Response (RTIR) before 4.0.3 and 5.x before 5.0.3 allows SSRF via the whois lookup tool.

MonstaFTP v2.10.3 was discovered to contain a Server-Side Request Forgery (SSRF) via the function performFetchRequest at HTTPFetcher.php.

Server-Side Request Forgery (SSRF) in Microsoft Power Apps allows an unauthorized attacker to disclose information over a network

Best Practical RT for Incident Response (RTIR) before 4.0.3 and 5.x before 5.0.3 allows SSRF via Scripted Action tools.

JetBrains Hub before 2021.1.14276 was vulnerable to blind Server-Side Request Forgery (SSRF).

Jizhicms v2.2.5 was discovered to contain a Server-Side Request Forgery (SSRF) vulnerability via the Update function in app/admin/c/TemplateController.php.

A Server-Side Request Forgery (SSRF) vulnerability in the /Upgrade/FixConfig route in Open Library Foundation VuFind 2.0 through 9.1 before 9.1.1 allows a remote attacker to overwrite local configuration files to gain access to the administrator panel and achieve Remote Code Execution. A mitigating factor is that it requires the allow_url_include PHP runtime setting to be on, which is off in default installations. It also requires the /Upgrade route to be exposed, which is exposed by default after installing VuFind, and is recommended to be disabled by setting autoConfigure to false in config.ini.

I, Librarian version 4.8 and earlier contains a SSRF vulnerability in "url" parameter of getFromWeb in functions.php that can result in the attacker abusing functionality on the server to read or update internal resources.