ghsa

### Impact Users settings their active admin form legends dynamically may be vulnerable to stored XSS, as long as its value can be injected directly by a malicious user. For example: * A public web application allows users to create entities with arbitrary names. * Active Admin is used to administrate these entities through a private backend. * The form to edit these entities in the private backend has the following shape (note the dynamic `name` value dependent on an attribute of the `resource`): ```ruby form do |f| f.inputs name: resource.name do f.input :name f.input :description end f.actions end ``` Then a malicious user could create an entity with a payload that would get executed in the active admin administrator's browser. Both `form` blocks with an implicit or explicit name (i.e., both `form resource.name` or `form name: resource.name` would suffer from the problem), where the value of the name can be arbitrarily set by non admin users. ### ...

Users registering via the `user:register_form` tag will have their password confirmation stored in plain text in their user file. ### Impact This only affects sites matching **all** of the following conditions: - Running Statamic versions between 5.3.0 and 5.6.1. (This version range represents only one calendar week) - Using the `user:register_form` tag. - Using file-based user accounts. (Does not affect users stored in a database.) - Has users that have registered during that time period. (Existing users are not affected.) The password is only visible to users that have access to read user yaml files, typically developers of the application itself. ### Patches The issue has been patched in 5.6.2, however any users registered during that time period and using the affected version range will still have the the `password_confirmation` value in their yaml files. We recommend that affected users have their password reset. The following query can be entered into `php artisan tinker` and...

Yii2 supports attaching Behaviors to Components by setting properties having the format `'as <behaviour-name>'`. Internally this is done using the `__set()` magic method. If the value passed to this method is not an instance of the `Behavior` class, a new object is instantiated using `Yii::createObject($value)`. However, there is no validation check that verifies that `$value` is a valid `Behavior` class name or configuration. An attacker that can control the content of the $value variable can then instantiate arbitrary classes, passing parameters to their constructors and then invoking setter methods. ### Impact With some effort malicious code can be injected executed which might be anything ranging from deleting files to dropping database tables ### Patches Not yet patched. ### Workarounds No Work around available ### References Reported [Here](https://huntr.com/bounties/4fbdd965-02b6-42e4-b57b-f98f93415b8f?token=3bcfc5266870680af19a26170b8dbf3750e3b593ce192da8eaa6a03f96b99b52c4...

A path traversal vulnerability was identified in the parisneo/lollms-webui repository, specifically within version 9.6. The vulnerability arises due to improper handling of user-supplied input in the 'list_personalities' endpoint. By crafting a malicious HTTP request, an attacker can traverse the directory structure and view the contents of any folder, albeit limited to subfolder names only. This issue was demonstrated via a specific HTTP request that manipulated the 'category' parameter to access arbitrary directories. The vulnerability is present in the code located at the 'endpoints/lollms_advanced.py' file.

A code injection vulnerability exists in the huggingface/text-generation-inference repository, specifically within the `autodocs.yml` workflow file. The vulnerability arises from the insecure handling of the `github.head_ref` user input, which is used to dynamically construct a command for installing a software package. An attacker can exploit this by forking the repository, creating a branch with a malicious payload as the name, and then opening a pull request to the base repository. Successful exploitation could lead to arbitrary code execution within the context of the GitHub Actions runner. This issue affects versions up to and including v2.0.0 and was fixed in version 2.0.0.

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...