#ssrf

### Summary The Coverage rest api `/workspaces/{workspaceName}/coveragestores/{storeName}/{method}.{format}` allow to upload file with a specified url (with {method} equals 'url') with no restrict. ### Details The Coverage rest api `/workspaces/{workspaceName}/coveragestores/{storeName}/{method}.{format}` allow to upload file with a specified url (with {method} equals 'url'). But this url has not been check with [URL Checks feature](https://docs.geoserver.org/latest/en/user/security/urlchecks.html#url-checks). For example, should add the code below to check fileURL: ```java URLCheckers.confirm(fileURL) ``` The vulnerable code was [RESTUtils.java](https://github.com/geoserver/geoserver/blob/main/src/rest/src/main/java/org/geoserver/rest/util/RESTUtils.java#L176) ### Impact This vulnerability presents the opportunity for Server Side Request Forgery. ### References - https://osgeo-org.atlassian.net/browse/GEOS-11468 - https://osgeo-org.atlassian.net/browse/GEOS-11717

### Summary An improper URI validation vulnerability exists that enables an unauthorized attacker to perform XML External Entities (XEE) attack, then send GET request to any HTTP server. Attacker can abuse this to scan internal networks and gain information about them then exploit further. Moreover, attacker can read limited `.xsd` file on system. ### Details By default, GeoServer use `PreventLocalEntityResolver` class from GeoTools to filter out malicious URIs in XML entities before resolving them. The URI must match the regex `(?i)(jar:file|http|vfs)[^?#;]*\\.xsd`. But the regex leaves a chance for attackers to request to any HTTP server or limited file. ### Impact An unauthenticated attacker can: 1. Scan internal network to gain insight about it and exploit further. 2. SSRF to endpoint ends with `.xsd`. 3. Read limited `.xsd` file on system. ### Mitigation 1. Define the system property ``ENTITY_RESOLUTION_ALLOWLIST`` to limit the supported external schema locaitons. 2. The buil...

### Summary It possible to achieve Service Side Request Forgery (SSRF) via the Demo request endpoint if Proxy Base URL has not been set. ### Details A unauthenticated user can supply a request that will be issued by the server. This can be used to enumerate internal networks and also in the case of cloud instances can be used to obtain sensitive data. ### Mitigation 1. When using GeoServer with a proxy, manage the proxy base value as a system administrator, use the application property ``PROXY_BASE_URL`` to provide a non-empty value that cannot be overridden by the user interface or incoming request. 2. When using GeoServer directly without a proxy, block all access to TestWfsPost by editing the web.xml file. Adding this block right before the end: ```xml <security-constraint> <web-resource-collection> <web-resource-name>BlockDemoRequests</web-resource-name> <url-pattern>/TestWfsPost/*</url-pattern> </web-resource-coll...

A possible arbitrary file read and SSRF vulnerability has been identified in Apache Kafka Client. Apache Kafka Clients accept configuration data for setting the SASL/OAUTHBEARER connection with the brokers, including "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url". Apache Kafka allows clients to read an arbitrary file and return the content in the error log, or sending requests to an unintended location. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use the "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url" configuratin to read arbitrary contents of the disk and environment variables or make requests to an unintended location. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment/URL access, which may be undesirable in certain environments, including SaaS products. Since Apache Kafka 3.9.1/4.0.0,...

### Summary GeoTools Schema class use of Eclipse XSD library to represent schema data structure is vulnerable to XML External Entity (XXE) exploit. ### Impact This impacts whoever exposes XML processing with ``gt-xsd-core`` involved in parsing, when the documents carry a reference to an external XML schema. The ``gt-xsd-core`` Schemas class is not using the EntityResolver provided by the ParserHandler (if any was configured). This also impacts users of ``gt-wfs-ng`` DataStore where the ENTITY_RESOLVER connection parameter was not being used as intended. ### Resolution GeoTools API change allows EntityResolver to be supplied to the following methods: ```java Schemas.parse( location, locators, resolvers, uriHandlers, entityResolver); Schemas.findSchemas(Configuration configuration, EntityResolver entityResolver); ``` With this API change the `gt-wfs-ng` WFS DataStore ENTITY_RESOLVER parameter is now used. ### Reference * [GHSA-jj54-8f66-c5pc](https://github.com/geoserver/geoser...

Hewlett Packard Enterprise (HPE) has released security updates to address as many as eight vulnerabilities in its StoreOnce data backup and deduplication solution that could result in an authentication bypass and remote code execution. "These vulnerabilities could be remotely exploited to allow remote code execution, disclosure of information, server-side request forgery, authentication bypass,

All versions of the package mcp-markdownify-server are vulnerable to Server-Side Request Forgery (SSRF) via the Markdownify.get() function. An attacker can craft a prompt that, once accessed by the MCP host, can invoke the webpage-to-markdown, bing-search-to-markdown, and youtube-to-markdown tools to issue requests and read the responses to attacker-controlled URLs, potentially leaking sensitive information.

## Description In Strapi latest version, at function Settings -> Webhooks, the application allows us to input a URL in order to create a Webook connection. However, we can input into this field the local domains such as `localhost`, `127.0.0.1`, `0.0.0.0`,.... in order to make the Application fetching into the internal itself, which causes the vulnerability `Server - Side Request Forgery (SSRF)`. ## Payloads - `http://127.0.0.1:80` -> `The Port is not open` - `http://127.0.0.1:1337` -> `The Port which Strapi is running on` ## Steps to Reproduce - First of all, let's input the URL `http://127.0.0.1:80` into the `URL` field, and click "Save".  - Next, use the "Trigger" function and use Burp Suite to capture the request / response  ...

A cross-site scripting (XSS) vulnerability exists in Grafana caused by combining a client path traversal and open redirect. This allows attackers to redirect users to a website that hosts a frontend plugin that will execute arbitrary JavaScript. This vulnerability does not require editor permissions and if anonymous access is enabled, the XSS will work. If the Grafana Image Renderer plugin is installed, it is possible to exploit the open redirect to achieve a full read SSRF. The default Content-Security-Policy (CSP) in Grafana will block the XSS though the `connect-src` directive.

### Problem Webhooks are inherently vulnerable to Server-Side Request Forgery (SSRF), which can be exploited by adversaries to target internal resources (e.g., _localhost_ or other services on the local network). While this is not a vulnerability in TYPO3 itself, it may enable attackers to blindly access systems that would otherwise be inaccessible. An administrator-level backend user account is required to exploit this vulnerability. ### Solution Update to TYPO3 versions 12.4.31 LTS, 13.4.12 LTS that fix the problem described. > [!IMPORTANT] > > **Manual actions required** > > To mitigate potential SSRF risks via webhooks, it is recommended to explicitly allow access only to trusted hosts. This can be achieved by configuring the allowlist in `$GLOBALS['TYPO3_CONF_VARS']['HTTP']['allowed_hosts']['webhooks']`. > > If the allowlist is not defined or set to `null`, all requests will be allowed. > If the allowlist is an empty `array`, all requests will be blocked. > > By default, the f...