XWiki Platform sends cookies to external images in rendered diff and is vulnerable to server side request forgery

XWiki Platform is a generic wiki platform. The rendered diff in XWiki embeds images to be able to compare the contents and not display a difference for an actually unchanged image. For this, XWiki requests all embedded images on the server side. These requests are also sent for images from other domains and include all cookies that were sent in the original request to ensure that images with restricted view right can be compared. Starting in version 11.10.1 and prior to versions 14.10.15, 15.5.1, and 15.6, this allows an attacker to steal login and session cookies that allow impersonating the current user who views the diff. The attack can be triggered with an image that references the rendered diff, thus making it easy to trigger. Apart from stealing login cookies, this also allows server-side request forgery (the result of any successful request is returned in the image's source) and viewing protected content as once a resource is cached, it is returned for all users. As only successful requests are cached, the cache will be filled by the first user who is allowed to access the resource. This has been patched in XWiki 14.10.15, 15.5.1 and 15.6. The rendered diff now only downloads images from trusted domains. Further, cookies are only sent when the image's domain is the same the requested domain. The cache has been changed to be specific for each user. As a workaround, the image embedding feature can be disabled by deleting `xwiki-platform-diff-xml-<version>.jar` in `WEB-INF/lib/`.

An issue in PublicCMS v.4.0.202302.e allows a remote attacker to obtain sensitive information via the appToken and Parameters parameter of the api/method/getHtml component.

Anyscale Ray 2.6.3 and 2.8.0 allows /log_proxy SSRF. NOTE: the vendor's position is that this report is irrelevant because Ray, as stated in its documentation, is not intended for use outside of a strictly controlled network environment

Authenticated PostHog users vulnerable to SSRF

PostHog provides open-source product analytics, session recording, feature flagging and A/B testing that you can self-host. A server-side request forgery (SSRF), which can only be exploited by authenticated users, was found in Posthog. Posthog did not verify whether a URL was local when enabling webhooks, allowing authenticated users to forge a POST request. This vulnerability has been addressed in `22bd5942` and will be included in subsequent releases. There are no known workarounds for this vulnerability.

Server-Side Request Forgery in espocrm

EspoCRM is an Open Source CRM (Customer Relationship Management) software. In affected versions there is Server-Side Request Forgery (SSRF) vulnerability via the upload image from url api. Users who have access to `the /Attachment/fromImageUrl` endpoint can specify URL to point to an internal host. Even though there is check for content type, it can be bypassed by redirects in some cases. This SSRF can be leveraged to disclose internal information (in some cases), target internal hosts and bypass firewalls. This vulnerability has been addressed in commit `c536cee63` which is included in release version 8.0.5. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Server-Side Request Forgery in groupoffice

Group-Office is an enterprise CRM and groupware tool. In affected versions there is full Server-Side Request Forgery (SSRF) vulnerability in the /api/upload.php endpoint. The /api/upload.php endpoint does not filter URLs which allows a malicious user to cause the server to make resource requests to untrusted domains. Note that protocols like file:// can also be used to access the server disk. The request result (on success) can then be retrieved using /api/download.php. This issue has been addressed in versions 6.8.15, 6.7.54, and 6.6.177. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Sentry Next.js vulnerable to SSRF via Next.js SDK tunnel endpoint

sentry-javascript provides Sentry SDKs for JavaScript. An unsanitized input of Next.js SDK tunnel endpoint allows sending HTTP requests to arbitrary URLs and reflecting the response back to the user. This issue only affects users who have Next.js SDK tunneling feature enabled. The problem has been fixed in version 7.77.0.

FoodCoopShop Server-Side Request Forgery vulnerability

FoodCoopShop is open source software for food coops and local shops. Versions starting with 3.2.0 prior to 3.6.1 are vulnerable to server-side request forgery. In the Network module, a manufacturer account can use the `/api/updateProducts.json` endpoint to make the server send a request to an arbitrary host. This means that the server can be used as a proxy into the internal network where the server is. Furthermore, the checks on a valid image are not adequate, leading to a time of check time of use issue. For example, by using a custom server that returns 200 on HEAD requests, then return a valid image on first GET request and then a 302 redirect to final target on second GET request, the server will copy whatever file is at the redirect destination, making this a full SSRF. Version 3.6.1 fixes this vulnerability.

An issue in openCRX v.5.2.2 allows a remote attacker to read internal files and execute server side request forgery attack via insecure DocumentBuilderFactory.

An unauthenticated attacked could send a specifically crafted web request causing a Server-Side Request Forgery (SSRF) in Ivanti Avalanche Remote Control server.

FOG SSRF via unauthenticated endpoint(s)

FOG is a free open-source cloning/imaging/rescue suite/inventory management system. Prior to version 1.5.10, a server-side-request-forgery (SSRF) vulnerability allowed an unauthenticated user to trigger a GET request as the server to an arbitrary endpoint and URL scheme. This also allows remote access to files visible to the Apache user group. Other impacts vary based on server configuration. Version 1.5.10 contains a patch.

LangChain before 0.0.317 allows SSRF via document_loaders/recursive_url_loader.py because crawling can proceed from an external server to an internal server.

crypto-es PBKDF2 1,000 times weaker than specified in 1993 and 1.3M times weaker than current standard

CryptoES is a cryptography algorithms library compatible with ES6 and TypeScript. Prior to version 2.1.0, CryptoES PBKDF2 is 1,000 times weaker than originally specified in 1993, and at least 1,300,000 times weaker than current industry standard. This is because it both defaults to SHA1, a cryptographic hash algorithm considered insecure since at least 2005, and defaults to one single iteration, a 'strength' or 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2 relies on iteration count as a countermeasure to preimage and collision attacks. If used to protect passwords, the impact is high. If used to generate signatures, the impact is high. Version 2.1.0 contains a patch for this issue. As a workaround, configure CryptoES to use SHA256 with at least 250,000 iterations.

Server-Side Request Forgery Vulnerability in Custom Integration Upload

Fides is an open-source privacy engineering platform for managing the fulfillment of data privacy requests in runtime environments, and the enforcement of privacy regulations in code. The Fides web application allows a custom integration to be uploaded as a ZIP file containing configuration and dataset definitions in YAML format. It was discovered that specially crafted YAML dataset and config files allow a malicious user to perform arbitrary requests to internal systems and exfiltrate data outside the environment (also known as a Server-Side Request Forgery). The application does not perform proper validation to block attempts to connect to internal (including localhost) resources. The vulnerability has been patched in Fides version `2.22.1`.

umputun remark42 version 1.12.1 and before has a Blind Server-Side Request Forgery (SSRF) vulnerability.

Unsafe rego built-in allowed in Artifact Hub

Artifact Hub is a web-based application that enables finding, installing, and publishing packages and configurations for CNCF projects. During a security audit of Artifact Hub's code base a security researcher identified a bug in which a default unsafe rego built-in was allowed to be used when defining authorization policies. Artifact Hub includes a fine-grained authorization mechanism that allows organizations to define what actions can be performed by their members. It is based on customizable authorization policies that are enforced by the `Open Policy Agent`. Policies are written using `rego` and their data files are expected to be json documents. By default, `rego` allows policies to make HTTP requests, which can be abused to send requests to internal resources and forward the responses to an external entity. In the context of Artifact Hub, this capability should have been disabled. This issue has been resolved in version `1.16.0`. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Require strict cookies for image proxy requests in Nextcloud Mail

Nextcloud mail is an email app for the Nextcloud home server platform. In affected versions a missing check of origin, target and cookies allows for an attacker to abuse the proxy endpoint to denial of service a third server. It is recommended that the Nextcloud Mail is upgraded to 2.2.8 or 3.3.0. There are no known workarounds for this vulnerability.

Blind Server Side Request Forgery (SSRF) in remote schedule import feature in Engelsystem

Engelsystem is a shift planning system for chaos events. A Blind SSRF in the "Import schedule" functionality makes it possible to perform a port scan against the local environment. This vulnerability has been fixed in commit ee7d30b33. If a patch cannot be deployed, operators should ensure that no HTTP(s) services listen on localhost and/or systems only reachable from the host running the engelsystem software. If such services are necessary, they should utilize additional authentication.

A Server-Side Request Forgery issue in the OpenID Connect Issuer in LemonLDAP::NG before 2.17.1 allows authenticated remote attackers to send GET requests to arbitrary URLs through the request_uri authorization parameter. This is similar to CVE-2020-10770.

Discourse-Jira could make SSRF attack by setting Jira URL to an arbitrary location

Discourse-jira is a Discourse plugin allows Jira projects, issue types, fields and field options will be synced automatically. An administrator user can make an SSRF attack by setting the Jira URL to an arbitrary location and enabling the `discourse_jira_verbose_log` site setting. A moderator user could manipulate the request path to the Jira API, allowing them to perform arbitrary GET requests using the Jira API credentials, potentially with elevated permissions, used by the application.