#ssrf

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

Not every security vulnerability is high risk on its own - but in the hands of an advanced attacker, even small weaknesses can escalate into major breaches. These five real vulnerabilities, uncovered by Intruder’s bug-hunting team, reveal how attackers turn overlooked flaws into serious security incidents. 1. Stealing AWS Credentials with a Redirect Server-Side Request Forgery (SSRF) is a

Enterprises using Commvault Innovation Release are urged to patch immediately against CVE-2025-34028. This critical flaw allows attackers to…

This month, the Microsoft Security Response Center recently welcomed some of the world’s most talented security researchers at Microsoft’s Zero Day Quest, the largest live hacking competition of its kind. The inaugural event challenged the security community to focus on the highest-impact security scenarios for Copilot and Cloud with up to $4 million in potential awards.

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

### Summary An attacker with the ability to create Kyverno policies in a Kubernetes cluster can use Service Call functionality to perform SSRF to a server under their control in order to exfiltrate data. ### Details According to the documentation, Service Call is intended to address services located inside the Kubernetes cluster, but this method can also resolve external addresses, which allows making requests outside the Kubernetes cluster. https://kyverno.io/docs/writing-policies/external-data-sources/#variables-from-service-calls ### PoC Create a slightly modified Cluster Policy from the documentation. In the url we specify the address of a server controlled by the attacker, for example Burp Collaborator. ```yaml apiVersion: kyverno.io/v1 kind: ClusterPolicy metadata: name: check-namespaces spec: rules: - name: call-extension match: any: - resources: kinds: - ConfigMap context: - name: result apiCall: method: P...

SurrealDB offers http functions that can access external network endpoints. A typical, albeit [not recommended ](https://surrealdb.com/docs/surrealdb/reference-guide/security-best-practices#example-deny-all-capabilities-with-some-exceptions) configuration would be to start SurrealDB with all network connections allowed with the exception of a deny list. For example, `surreal start --allow-net --deny-net 10.0.0.0/8` will allow all network connections except to the 10.0.0.0/8 block. An authenticated user of SurrealDB can use redirects to bypass this restriction. For example by hosting a server on the public internet which redirects to the IP addresses blocked by the administrator of the SurrealDB server via HTTP 301 or 307 response codes. When sending SurrealDB statements containing the `http::*` functions to the attacker controlled host, the SurrealDB server will follow the redirects to the blocked IP address. Because the statements also return the responses to the attacker, this iss...

A bypass has been identified for the previously known vulnerability CVE-2017-0929, allowing unauthenticated attackers to execute arbitrary GET requests against target systems, including internal or adjacent networks. ### Impact This vulnerability facilitates a semi-blind SSRF attack, allowing attackers to make the target server send requests to internal or external URLs without viewing the full responses. Potential impacts include internal network reconnaissance, bypassing firewalls.