ghsa

A flaw in the database escaping API results in a SQL injection vulnerability when extension dbal is enabled and configured for MySQL passthrough mode in its extension configuration. All queries which use the DatabaseConnection::sql_query are vulnerable, even if arguments were properly escaped with DatabaseConnection::quoteStr beforehand.

Failing to properly encode editor input, the search result view of indexed_search is susceptible to Cross-Site Scripting, allowing authenticated editors to inject arbitrary HTML.

The flashplayer misses to validate flash and image files. Therefore it is possible to embed flash videos from external domains.

Failing to properly encode user input, several backend components are susceptible to Cross-Site Scripting, allowing authenticated editors to inject arbitrary HTML or JavaScript.

qdrant/qdrant version 1.9.0-dev is vulnerable to arbitrary file read and write during the snapshot recovery process. Attackers can exploit this vulnerability by manipulating snapshot files to include symlinks, leading to arbitrary file read by adding a symlink that points to a desired file on the filesystem and arbitrary file write by including a symlink and a payload file in the snapshot's directory structure. This vulnerability allows for the reading and writing of arbitrary files on the server, which could potentially lead to a full takeover of the system. The issue is fixed in version v1.9.0.

Silverpeas before 6.3.5 allows authentication bypass by omitting the Password field to AuthenticationServlet, often providing an unauthenticated user with superadmin access.

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