ghsa

### Impact A user with an administrator, project_admin, or project_maintainer role could utilize and exploit SQL Injection to allow the execution of any Postgres function or the extraction of sensitive information from the database through this API: ``` GET /api/v2.0/projects/{project_name}/repositories/{repository_name}/artifacts/{reference}/scan/{report_id}/log ``` The SQL injection might happen in the code: https://github.com/goharbor/harbor/blob/9b7c1a2274fbc5ea16e19a484532f86c08926577/src/pkg/task/task.go#L241 Because raw SQL executed in ormer.Raw(Sql).QueryRows() is PrepareStatement. In the driver of Postgres, one PrepareStatement must contain only ONE SQL command, see https://www.postgresql.org/docs/15/libpq-exec.html#LIBPQ-PQPREPARE. The SQL should start with: ``` SELECT * FROM task WHERE extra_attrs::jsonb->'report_uuids' @> ``` Adding a delete/update operation by appending malicious content to the current SQL is impossible. Furthermore, the query result of the task is ju...

### Description Under OIDC authentication mode, there is a redirect_url parameter exposed in the URL which is used to redirect the current user to the defined location after the successful OIDC login, This redirect_url can be an ambiguous URL and can be used to embed a phishing URL. For example: if a user clicks the URL with a malicious redirect_url: ``` https://<harbor_hostnmae>/c/oidc/login?redirect_url=https://<redirect_domain> ``` It might redirect the current user without their knowledge to a malicious site, posing a potential risk. To avoid this issue, the redirect_url should be checked if it is a local path when reading it from the original request URL. ``` //src/core/controllers/oidc.go ... redirectURL := oc.Ctx.Request.URL.Query().Get("redirect_url") if !utils.IsLocalPath(redirectURL) { log.Errorf("invalid redirect url: %v", redirectURL) oc.SendBadRequestError(fmt.Errorf("cannot redirect to other site")) return } if err := oc.SetSession(redirectURLKey, redirectURL...

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