#ssrf

An SSRF (Server-Side Request Forgery) vulnerability exists in the gradio-app/gradio repository, allowing attackers to scan and identify open ports within an internal network. By manipulating the 'file' parameter in a GET request, an attacker can discern the status of internal ports based on the presence of a 'Location' header or a 'File not allowed' error in the response.

### Impact Prior to the patched version, an authenticated user of Mautic could read system files and access the internal addresses of the application due to a Server-Side Request Forgery (SSRF) vulnerability. ### Patches Update to 4.4.12 or 5.0.4 ### Workarounds None ### References - https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/ If you have any questions or comments about this advisory: Email us at [[email protected]](mailto:[email protected])

A flaw was found in` JwtValidator.resolvePublicKey` in JBoss EAP, where the validator checks jku and sends a HTTP request. During this process, no whitelisting or other filtering behavior is performed on the destination URL address, which may result in a server-side request forgery (SSRF) vulnerability.

Authenticated attackers can exploit a weakness in the XML parser functionality of the Visual Planning application in order to obtain read access to arbitrary files on the application server. Depending on configured access permissions, this vulnerability could be used by an attacker to exfiltrate secrets stored on the local file system. All versions prior to Visual Planning 8 (Build 240207) are affected.

Large language models require rethinking how to bake security into the software development process earlier.

### Impact _What kind of vulnerability is it? Who is impacted?_ SSRF vulnerability in firebase database check logic. The attacker can cause the server to make a connection to internal-only services within the organization’s infrastructure. When malicious app is uploaded to Static analyzer, it is possible to make internal requests. Credits: Oleg Surnin (Positive Technologies). ### Patches _Has the problem been patched? What versions should users upgrade to?_ v3.9.8 and above ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ Code level patch ### References _Are there any links users can visit to find out more?_ https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/2373

Server Side Request Forgery (SSRF) vulnerability in Gleez Cms 1.2.0, allows remote attackers to execute arbitrary code and obtain sensitive information via modules/gleez/classes/request.php.

The /proxy route allows a user to proxy arbitrary urls including potential internal endpoints.

### Summary While examining the "App Link assetlinks.json file could not be found" vulnerability detected by MobSF, we, as the Trendyol Application Security team, noticed that a GET request was sent to the "/.well-known/assetlinks.json" endpoint for all hosts written with "android:host". In the AndroidManifest.xml file. Since MobSF does not perform any input validation when extracting the hostnames in "android:host", requests can also be sent to local hostnames. This may cause SSRF vulnerability. ### Details Example <intent-filter structure in AndroidManifest.xml: ``` <intent-filter android:autoVerify="true"> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:host="192.168.1.102/user/delete/1#" android:scheme="http" /> </intent-filter> ``` We defined it as android:host="192.168.1.102/user/delete/1#". Here, the "#" character at the end of the hos...

Red Hat Security Advisory 2024-1353-03 - An update is now available for Red Hat Process Automation Manager. Issues addressed include code execution, denial of service, and deserialization vulnerabilities.