#ssrf

# Introduction This write-up describes a vulnerability found in [Label Studio](https://github.com/HumanSignal/label-studio), a popular open source data labeling tool. The vulnerability affects all versions of Label Studio prior to `1.10.1` and was tested on version `1.9.2.post0`. # Overview [Label Studio](https://github.com/HumanSignal/label-studio) had a remote import feature allowed users to import data from a remote web source, that was downloaded and could be viewed on the website. This feature could had been abused to download a HTML file that executed malicious JavaScript code in the context of the Label Studio website. # Description The following [code snippet in Label Studio](https://github.com/HumanSignal/label-studio/blob/1.9.2.post0/label_studio/data_import/uploader.py#L125C5-L146) showed that is a URL passed the SSRF verification checks, the contents of the file would be downloaded using the filename in the URL. ```python def tasks_from_url(file_upload_ids, project, u...

HaoKeKeJi YiQiNiu versions up to 3.1 suffer from a server-side request forgery vulnerability.

** UNSUPPORTED WHEN ASSIGNED ** Improper Input Validation vulnerability in Apache Axis allowed users with access to the admin service to perform possible SSRF. This issue affects Apache Axis through 1.3. As Axis 1 has been EOL, we recommend you migrate to a different SOAP engine, such as Apache Axis 2/Java. Alternatively you could use a build of Axis with the patch from https://github.com/apache/axis-axis1-java/commit/685c309febc64aa393b2d64a05f90e7eb9f73e06 applied. The Apache Axis project does not expect to create an Axis 1.x release fixing this problem, though contributors that would like to work towards this are welcome.

### Impact Users hosting D-Tale publicly can be vulnerable to server-side request forgery (SSRF) allowing attackers to access files on the server. ### Patches Users should upgrade to version 3.9.0 where the "Load From the Web" input is turned off by default. You can find out more information on how to turn it back on [here](https://github.com/man-group/dtale?tab=readme-ov-file#load-data--sample-datasets) ### Workarounds The only workaround for versions earlier than 3.9.0 is to only host D-Tale to trusted users. ### References See "Load Data & Sample Datasets" [documentation](https://github.com/man-group/dtale?tab=readme-ov-file#load-data--sample-datasets)

### Impact An authenticated attacker with valid credentials (user or host) can make non-blind Server-Side Request Forgery (SSRF) through the proxy and/or agents to arbitrary hosts. During investigation of this functionality, it was discovered that there are several permutations where this SSRF is possible. This release addresses all but one: a root proxy administrator with access to the root proxy credentials can make requests through leaf proxies in Trusted Clusters. This behavior will be restricted in future releases. For customers using Teleport in a Trusted Cluster configuration, we encourage leaf clusters to have network restrictions in place to mitigate SSRF. For example, we recommend restricting outbound network connections to only the Auth Service, your SSO provider, and any agents, databases or applications needed to be accessed from the proxy. If running in a cloud environment pay careful attention to what cloud resources are accessible from the proxy. ### Patches Fixed in ...

### Impact The V8 inspector intentionally allows arbitrary code execution within the Workers sandbox for debugging. `wrangler dev` would previously start an inspector server listening on all network interfaces. This would allow an attacker on the local network to connect to the inspector and run arbitrary code. Additionally, the inspector server did not validate `Origin`/`Host` headers, granting an attacker that can trick any user on the local network into opening a malicious website the ability to run code. If `wrangler dev --remote` was being used, an attacker could access production resources if they were bound to the worker. ### Patches This issue was fixed in `[email protected]` and `[email protected]`. Whilst `wrangler dev`'s inspector server listens on local interfaces by default as of `[email protected]`, an [SSRF vulnerability in `miniflare`](https://github.com/cloudflare/workers-sdk/security/advisories/GHSA-fwvg-2739-22v7) allowed access from the local network until `[email protected]...

### Impact Sending specially crafted HTTP requests to Miniflare's server could result in arbitrary HTTP and WebSocket requests being sent from the server. If Miniflare was configured to listen on external network interfaces (as was the default in `wrangler` until `3.19.0`), an attacker on the local network could access other local servers. ### Patches The issue was fixed in `[email protected]`. ### Workarounds Ensure Miniflare is configured to listen on just local interfaces. This is the default behaviour, but can also be configured with the `host: "127.0.0.1"` option. ### References - https://github.com/cloudflare/workers-sdk/pull/4532

A new zero-day security flaw has been discovered in the Apache OfBiz, an open-source Enterprise Resource Planning (ERP) system that could be exploited to bypass authentication protections. The vulnerability, tracked as CVE-2023-51467, resides in the login functionality and is the result of an incomplete patch for another critical vulnerability (CVE-2023-49070, CVSS score: 9.8) that was

automad up to 1.10.9 is vulnerable to an authenticated blind server-side request forgery in `importUrl` as the `import` function on the `FileController.php` file was not properly validating the value of the `importUrl` argument. This issue may allow attackers to perform a port scan against the local environment or abuse some service.

Older versions of `gradio` contained a vulnerability in the `/file` route which made them susceptible to file traversal attacks in which an attacker could access arbitrary files on a machine running a Gradio app with a public URL (e.g. if the demo was created with `share=True`, or on Hugging Face Spaces) if they knew the path of files to look for. This was not possible through regular URLs passed into a browser, but it was possible through the use of programmatic tools such as `curl` with the `--pass-as-is` flag. Furthermore, the `/file` route in Gradio apps also contained a vulnerability that made it possible to use it for SSRF attacks. Both of these vulnerabilities have been fixed in `gradio==4.11.0`