Imthatt

**Name of the Vulnerable Software and Affected Versions** GeoNode versions prior to 4.2.3 **Description** The issue exists within GeoNode, a geospatial content management system, where the current rich text editor is vulnerable to Stored XSS. This allows an attacker to retrieve a victim's CSRF token and issue a request to change another user's email address, potentially leading to a full account takeover. The script element does not impact the CORS policy, allowing requests to succeed. **Recommendations** For versions prior to 4.2.3, update to version 4.2.3 to resolve the issue. As a temporary workaround, consider disabling the rich text editor until a patch is available. Restrict access to sensitive user account settings to minimize the risk of exploitation. Avoid using the vulnerable rich text editor in the affected GeoNode platform until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Piwigo versions prior to 14.3.0 **Description** A Cross Site Scripting issue exists due to missing sanitization in the `create tag` function in `admin/include/functions.php`. **Recommendations** For versions prior to 14.3.0, update to version 14.3.0 or later to resolve the issue. As a temporary workaround, consider restricting access to the `create tag` function in `admin/include/functions.php` until a patch is available.

**Name of the Vulnerable Software and Affected Versions** Piwigo versions prior to 14.2.0 **Description** An issue exists within Piwigo allowing a malicious user to take over the application. This exploit involves chaining a Cross Site Request Forgery vulnerability to issue a Stored Cross Site Scripting payload stored within an Admin user's dashboard, executing remote JavaScript. This can be used to upload a new PHP file under an administrator and directly call that file from the victim's instance to connect back to a malicious listener. The vulnerability can also be used by a remote attacker to escalate privileges via the batch function on the admin page. **Recommendations** For versions prior to 14.2.0, update to version 14.2.0 or later to resolve the issue. As a temporary workaround, consider disabling the batch function on the admin page and restricting access to the admin dashboard to minimize the risk of exploitation. Avoid using the application's admin features until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** GeoNode versions 3.2.0 through 4.1.3 **Description** A SSRF vulnerability exists, bypassing existing controls on the software. This can allow a user to request internal services for a full read SSRF, returning any data from the internal network. The application is using a whitelist, but the whitelist can be bypassed with `@` or `%40`. For example, a GET request to `/proxy/?url=http://development.demo.geonode.org%40geoserver:8080/geoserver/web` will trick the application that the first host is a whitelisted address, but the browser will use `@` or `%40` as a credential to the host geoserver on port 8080, returning the data to that host on the response. **Recommendations** For versions 3.2.0 through 4.1.3, update to version 4.1.3.post1 or later to resolve the issue. As a temporary workaround, consider restricting access to the `/proxy/` API endpoint until a patch is available. Avoid using the `url` parameter in the affected API endpoint with `@` or `%40` characters until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** GeoNode versions 3.2.0 through 4.1.2 **Description** The issue concerns a server-side request forgery problem in GeoNode. Specifically, the endpoint `/proxy/?url=` does not properly protect against this type of attack, allowing an attacker to port scan internal hosts and request information from them. This can be exploited by using specific URL formats, such as `/proxy/?url=http://169.254.169.254@whitelistedIPhere`, to determine if an internal host is alive. Additionally, an attacker can use a hashfrag on the URL, like `/proxy/?url=http://169.254.169.254@#whitelisteddomain.com` or `/proxy/?url=http://169.254.169.254@%23whitelisteddomain.com`, to display metadata. **Recommendations** For GeoNode versions 3.2.0 through 4.1.2, apply the patch available at commit a9eebae80cb362009660a1fd49e105e7cdb499b9 to resolve the issue. As a temporary workaround, consider restricting access to the `/proxy/?url=` endpoint until the patch is applied.