I, Librarian version 4.9 and earlier contains an Incorrect Access Control vulnerability in ajaxdiscussion.php that can result in any users gaining unauthorized access (read, write and delete) to project discussions.

I Librarian I-librarian version 4.8 and earlier contains a XML External Entity (XXE) vulnerability in line 154 of importmetadata.php(simplexml_load_string) that can result in an attacker reading the contents of a file and SSRF. This attack appear to be exploitable via posting xml in the Parameter form_import_textarea.

I, Librarian version <=4.6 & 4.7 is vulnerable to Server-Side Request Forgery in the ajaxsupplement.php resulting in the attacker being able to reset any user's password.

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

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

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.

A vulnerability in Trend Micro Control Manager (versions 6.0 and 7.0) could allow an attacker to conduct a server-side request forgery (SSRF) attack on vulnerable installations.

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.

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).

The OneStore Sites plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 0.1.1 via the class-export.php file. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.

The Platform.ly for WooCommerce plugin for WordPress is vulnerable to Blind Server-Side Request Forgery in all versions up to, and including, 1.1.6 via the 'hooks' function. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.

The Starter Templates by FancyWP plugin for WordPress is vulnerable to Blind Server-Side Request Forgery in all versions up to, and including, 2.0.0 via the 'http_request_host_is_external' filter. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.

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 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.

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.

halo v2.20.17 and before is vulnerable to server-side request forgery (SSRF) in /apis/uc.api.storage.halo.run/v1alpha1/attachments/-/upload-from-url.

The nelio-ab-testing plugin before 4.5.11 for WordPress has SSRF in ajax/iesupport.php.

ThingsBoard versions < 4.2.1 contain a server-side request forgery (SSRF) vulnerability in the dashboard's Image Upload Gallery feature. An attacker can upload a malicious SVG file that references a remote URL. If the server processes the SVG file in a way that parses external references, it may initiate unintended outbound requests. This can be used to access internal services or resources.

openapi-generator up to v6.4.0 was discovered to contain a Server-Side Request Forgery (SSRF) via the component /api/gen/clients/{language}. This vulnerability allows attackers to access network resources and sensitive information via a crafted API request.

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

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.

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

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.

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

Myucms v2.2.1 contains a server-side request forgery (SSRF) in the component \controller\index.php, which can be exploited via the sj() method.

Yifang CMS v2.0.2 is vulnerable to Server-Side Request Forgery (SSRF) in /api/file/getRemoteContent.

An issue was discovered in Acronis Cyber Backup before 12.5 Build 16342. Some API endpoints on port 9877 under /api/ams/ accept an additional custom Shard header. The value of this header is afterwards used in a separate web request issued by the application itself. This can be abused to conduct SSRF attacks against otherwise unreachable Acronis services that are bound to localhost such as the NotificationService on 127.0.0.1:30572.

ftp-srv is an npm package which is a modern and extensible FTP server designed to be simple yet configurable. In ftp-srv before versions 2.19.6, 3.1.2, and 4.3.4 are vulnerable to Server-Side Request Forgery. The PORT command allows arbitrary IPs which can be used to cause the server to make a connection elsewhere. A possible workaround is blocking the PORT through the configuration. This issue is fixed in version2 2.19.6, 3.1.2, and 4.3.4. More information can be found on the linked advisory.

Insufficient validation in the Bitdefender Update Server and BEST Relay components of Bitdefender Endpoint Security Tools versions prior to 6.6.20.294 allows an unprivileged attacker to bypass the in-place mitigations and interact with hosts on the network. This issue affects: Bitdefender Update Server versions prior to 6.6.20.294.

Apache Batik 1.13 is vulnerable to server-side request forgery, caused by improper input validation by the NodePickerPanel. By using a specially-crafted argument, an attacker could exploit this vulnerability to cause the underlying server to make arbitrary GET requests.

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.

Docker Model Runner (DMR) is software used to manage, run, and deploy AI models using Docker. Prior to version 1.1.25, Docker Model Runner contains an SSRF vulnerability in its OCI registry token exchange flow. When pulling a model, Model Runner follows the realm URL from the registry's WWW-Authenticate header without validating the scheme, hostname, or IP range. A malicious OCI registry can set the realm to an internal URL (e.g., http://127.0.0.1:3000/), causing Model Runner running on the host to make arbitrary GET requests to internal services and reflect the full response body back to the caller. Additionally, the token exchange mechanism can relay data from internal services back to the attacker-controlled registry via the Authorization: Bearer header. This issue has been patched in version 1.1.25. For Docker Desktop users, enabling Enhanced Container Isolation (ECI) blocks container access to Model Runner, preventing exploitation. However, if the Docker Model Runner is exposed to localhost over TCP in specific configurations, the vulnerability is still exploitable.

The /plugins/servlet/gadgets/makeRequest resource in Jira before version 8.4.0 allows remote attackers to access the content of internal network resources via a Server Side Request Forgery (SSRF) vulnerability due to a logic bug in the JiraWhitelist class.

A Server-Side Request Forgery (SSRF) vulnerability exists in the Print Format functionality of ERPNext v16.0.1 and Frappe Framework v16.1.1, where user-supplied HTML is insufficiently sanitized before being rendered into PDF. When generating PDFs from user-controlled HTML content, the application allows the inclusion of HTML elements such as <iframe> that reference external resources. The PDF rendering engine automatically fetches these resources on the server side. An attacker can abuse this behavior to force the server to make arbitrary HTTP requests to internal services, including cloud metadata endpoints, potentially leading to sensitive information disclosure.

LuquidPixels LiquiFire OS 4.8.0 allows SSRF via the call%3Durl substring followed by a URL in square brackets.

A Server-Side Request Forgery (SSRF): CWE-918 vulnerability exists in U.motion Server (MEG6501-0001 - U.motion KNX server, MEG6501-0002 - U.motion KNX Server Plus, MEG6260-0410 - U.motion KNX Server Plus, Touch 10, MEG6260-0415 - U.motion KNX Server Plus, Touch 15), which could cause server configuration data to be exposed when an attacker modifies a URL.

The fetch API in Tightrope Media Carousel before 7.1.3 has CarouselAPI/v0/fetch?url= SSRF. This has two potential areas for abuse. First, a specially crafted URL could be used in a phishing attack to hijack the trust the user and the browser have with the website and could serve malicious content from a third-party attacker-controlled system. Second, arguably more severe, is the potential for an attacker to circumvent firewall controls, by proxying traffic, unauthenticated, into the internal network from the internet.

Lack of validation in the HTML parser in RealObjects PDFreactor before 10.1.10722 leads to SSRF, allowing attackers to access network or file resources on behalf of the server by supplying malicious HTML content.

maccms10 v2025.1000.4047 is vulnerable to Server-Side Request Forgery (SSRF) via the Scheduled Task function.

maccms10 v2025.1000.4047 is vulnerable to Server-Side Request Forgery (SSRF) in the Collection Custom Interface feature.

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

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

A Server-Side Request Forgery (SSRF) in the UISP Application may allow a malicious actor with certain permissions to make requests outside of UISP Application scope.

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.

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).

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.

In grav <1.7.49.5, a SSRF (Server-Side Request Forgery) vector may be triggered via Twig templates when page content is processed by Twig and the configuration allows undefined PHP functions to be registered

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.

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.