Source
ghsa
Failing to sanitize content from editors, the link validator component is susceptible to Cross-Site Scripting. A valid editor account with access to content which is scanned by the link validator component is required to exploit this vulnerability.
Failing to properly encode editor input, several frontend components are susceptible to Cross-Site Scripting, allowing authenticated editors to inject arbitrary HTML.
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...