ghsa

qdrant/qdrant version 1.9.0-dev is vulnerable to path traversal due to improper input validation in the `/collections/{name}/snapshots/upload` endpoint. By manipulating the `name` parameter through URL encoding, an attacker can upload a file to an arbitrary location on the system, such as `/root/poc.txt`. This vulnerability allows for the writing and overwriting of arbitrary files on the server, potentially leading to a full takeover of the system. The issue is fixed in version 1.9.0.

### Summary All decompressor implementations of Aircompressor (LZ4, LZO, Snappy, Zstandard) can crash the JVM for certain input, and in some cases also leak the content of other memory of the Java process (which could contain sensitive information). ### Details When decompressing certain data, the decompressors try to access memory outside the bounds of the given byte arrays or byte buffers. Because Aircompressor uses the JDK class `sun.misc.Unsafe` to speed up memory access, no additional bounds checks are performed and this has similar security consequences as out-of-bounds access in C or C++, namely it can lead to non-deterministic behavior or crash the JVM. Users should update to Aircompressor 0.27 or newer where these issues have been fixed. ### Impact When decompressing data from untrusted users, this can be exploited for a denial-of-service attack by crashing the JVM, or to leak other sensitive information from the Java process.

The ip package through 2.0.1 for Node.js might allow SSRF because some IP addresses (such as 127.1, 01200034567, 012.1.2.3, 000:0:0000::01, and ::fFFf:127.0.0.1) are improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2023-42282.

### Impact Due to an improperly applied permission check in the `wagtail.contrib.settings` module, a user with access to the Wagtail admin and knowledge of the URL of the edit view for a settings model can access and update that setting, even when they have not been granted permission over the model. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin. ### Patches Patched versions have been released as Wagtail 6.0.5 and 6.1.2. Wagtail releases prior to 6.0 are unaffected. ### Workarounds No workaround is available. ### Acknowledgements Many thanks to Victor Miti for reporting this issue. ### For more information If you have any questions or comments about this advisory: * Visit Wagtail's [support channels](https://docs.wagtail.io/en/stable/support.html) * Email us at [[email protected]](mailto:[email protected]) (view our [security policy](https://github.com/wagtail/wagtail/security/policy) for more information).

### Impact Sentry's Slack integration incorrectly records the incoming request body in logs. This request data can contain sensitive information, including the [deprecated Slack verification token](https://api.slack.com/authentication/verifying-requests-from-slack#deprecation). With this verification token, it is possible under specific configurations, an attacker can forge requests and act as the Slack integration. The request body is leaked in log entries matching `event == "slack.*" && name == "sentry.integrations.slack" && request_data == *`. The deprecated slack verification token, will be found in the `request_data.token` key. Example event: ```json { "name": "sentry.integrations.slack", "level": "info", "event": "slack.event.message", # This could be any of the `slack.*` events "request_data": { # Other keys are omitted for brevity "token": "<MyDeprecatedSlackVerificationToken>", } } ``` ### Patches - **SaaS users** do not need to take any a...

The Fides webserver has a number of endpoints that retrieve `ConnectionConfiguration` records and their associated `secrets` which _can_ contain sensitive data (e.g. passwords, private keys, etc.). These `secrets` are stored encrypted at rest (in the application database), and the associated endpoints are not meant to expose that sensitive data in plaintext to API clients, as it could be compromising. Fides's developers have available to them a Pydantic field-attribute (`sensitive`) that they can annotate as `True` to indicate that a given secret field should not be exposed via the API. The application has an internal function that uses `sensitive` annotations to mask the sensitive fields with a `"**********"` placeholder value. This vulnerability is due to a bug in that function, which prevented `sensitive` API model fields that were _nested_ below the root-level of a `secrets` object from being masked appropriately. Only the `BigQuery` connection configuration secrets meets these ...

During the internal penetration testing of our product based on Yii2, we discovered an XSS vulnerability within the framework itself. This issue is relevant for the latest version of Yii2 (2.0.49.3). ### Conditions for vulnerability reproduction * The framework is in debug mode (YII_DEBUG set to true). * The php.ini setting zend.exception_ignore_args is set to Off (default value). * An attacker induces an exception in the application, leading to a stack trace page being displayed. ### Vulnerability description The issue lies in the mechanism for displaying function argument values in the stack trace. The vulnerability manifests when an argument's value exceeds 32 characters. For convenience, argument values exceeding this limit are truncated and displayed with an added "...". The full argument value becomes visible when hovering over it with the mouse, as it is displayed in the title attribute of a span tag. However, the use of a double quote (") allows an attacker to break out of ...

In a shared hosting environment that has been misconfigured to allow access to other users' content, a Moodle user with both access to restore workshop modules and direct access to the web server outside of the Moodle webroot could execute a local file include.

In a shared hosting environment that has been misconfigured to allow access to other users' content, a Moodle user with both access to restore database activity modules and direct access to the web server outside of the Moodle webroot could execute a local file include.

In a shared hosting environment that has been misconfigured to allow access to other users' content, a Moodle user with both access to restore wiki modules and direct access to the web server outside of the Moodle webroot could execute a local file include.