Source
ghsa
### Impact It may be possible for a deactivated user to login when using uncommon configurations. This only applies if any of the following are true: * [JSON Web Tokens are enabled for login](https://matrix-org.github.io/synapse/latest/jwt.html) via the `jwt_config.enabled` configuration setting * The [local password database is enabled](https://matrix-org.github.io/synapse/latest/usage/configuration/config_documentation.html#password_config) via the `password_config.enabled` and `password_config.localdb_enabled` configuration settings *and* a user's password is [updated via an admin API](https://matrix-org.github.io/synapse/latest/admin_api/user_admin_api.html#create-or-modify-account) after a user is deactivated. **Note that the local password database is enabled by default**, but it is uncommon to set a user's password after they've been deactivated. Installations that are configured to only allow login via Single Sign-On (SSO) via CAS, SAML or OpenID Connect (OIDC); or via an e...
## Impact 1. A compromised instance with shared folders could sync malicious files which contain arbitrary HTML and JavaScript in the name. If the owner of another device looks over the shared folder settings and moves the mouse over the latest sync, a script could be executed to change settings for shared folders or add devices automatically. 2. Adding a new device with a malicious name could embed HTML or JavaScript inside parts of the page. ## Risk As long as trusted devices are used, the risk is low. Additionally, the web GUI is not used that often in daily use which reduces the likelihood of exploitation. ## Details ### 1. Field "Latest Change" * Open the web GUI at [http://127.0.0.1:8384/](http://127.0.0.1:8384/). * Create/Delete a file named ```<img src=a onerror=alert(123)>``` and sync it to the other instance. * Move your mouse over the latest change to trigger the tooltip. <img width="834" alt="latest-change" src="https://user-images.githubusercontent.com/9484134/2050...
### Summary Some avo fields are vulnerable to XSS when rendering html based content. ### Details During the analysis of the web application, a rendered field was discovered that did not filter JS / HTML tags in a safe way and can be abused to execute js code on a client side. The trix field uses the trix editor in the backend to edit rich text data which basically operates with html tags. To display the stored data in a rendered view, the HasHTMLAttributes concern is used. This can be exploited by an attacker to store javascript code in any trix field by intercepting the request and modifying the post data, as the trix editor does not allow adding custom html or js tags on the frontend. ### PoC ![image](https://user-images.githubusercontent.com/26464774/243434868-47857054-9b20-437f-842f-0750d53c9b0e.png) _Adding javascript in the post request which is used when editing a "post" resource (body is declared as a trix field)_ ![image](https://user-images.githubusercontent.com/26464774/2...
trust-dns and trust-dns-server are vulnerable to remotely triggered denial-of-service attacks, consuming both network and CPU resources. DNS messages with the QR=1 bit set are responded to with a `FormErr` response. This allows creating a traffic loop, in which these `FormErr` responses are sent nonstop between vulnerable servers. There are two scenarios how this can be exploited: 1) Create a loop between two instances of trust-dns, consuming network resources, or 2) consuming the CPU of a single instance. With two instances *A* and *B* an attacker sends a DNS query with a spoofed source IP address to *A*. *A* replies with a `FormErr` to *B*. Now both servers with ping-pong the message back and forth until by chance the packet is dropped in the network. Multiple spoofed packets can be sent by the attacker, increasing resource consumption. A single server can get locked up replying to itself. Same setup as above, but now *A* sends the reply to itself. The packet is sent out as fast a...
### Summary Vite Server Options (`server.fs.deny`) can be bypassed using double forward-slash (//) allows any unauthenticated user to read file from the Vite root-path of the application including the default [`fs.deny` settings](https://vitejs.dev/config/server-options.html#server-fs-deny) (`['.env', '.env.*', '*.{crt,pem}']`) ### Impact Only users explicitly exposing the Vite dev server to the network (using `--host` or [`server.host` config option](https://vitejs.dev/config/server-options.html#server-host)) are affected, and only files in the immediate Vite project root folder could be exposed. ### Patches Fixed in [email protected], [email protected], [email protected], [email protected] And in the latest minors of the previous two majors: [email protected], [email protected] ### Details Vite serve the application with under the root-path of the project while running on the dev mode. By default, vite using server options fs.deny to protected the sensitive information of the file. But, with simply double forward-slash, ...
### Impact A vulnerability has been identified which enables [Standard users](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions) or above to elevate their permissions to Administrator in the `local` cluster. The `local` cluster means the cluster where Rancher is installed. It is named `local` inside the list of clusters in the Rancher UI. Standard users could leverage their existing permissions to manipulate Kubernetes secrets in the `local` cluster, resulting in the secret being deleted, but their read-level permissions to the secret being preserved. When this operation was followed-up by other specially crafted commands, it could result in the user gaining access to tokens belonging to service accounts in the `local` cluster. Users that have custom global roles which grant `create` and `delete` permissions on `secrets` would also be able to exploit this...
### Impact Multiple Cross-Site Scripting (XSS) vulnerabilities have been identified in the Rancher UI. Cross-Site scripting allows a malicious user to inject code that is executed within another user's browser, allowing the attacker to steal sensitive information, manipulate web content, or perform other malicious activities on behalf of the victims. This could result in a user with write access to the affected areas being able to act on behalf of an administrator, once an administrator opens the affected web page. The affected areas include the Projects/Namespaces and Auth Provider sections. The attacker needs to be authenticated and have write access to those features in order to exploit the vulnerabilities. Some of the permissions (roles) required are: - Project Owner. - Restricted Admin. - Configure Authentication. - Administrator. - Custom RBAC Role that provides write access on Projects or External Authentication Providers. For users that suspect this vulnerability may have t...
### Impact A vulnerability was identified in which users with update privileges on a namespace, can move that namespace into a project they don't have access to. After the namespace transfer is completed, their previous permissions are still preserved, which enables them to gain access to project-specific resources (such as [project secrets](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/secrets#creating-secrets-in-projects)). In addition, resources in the namespace will now count toward the [quota limit](https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas/about-project-resource-quotas) of the new project, potentially causing availability issues. User with roles `Project Owner` and `Project Member` on the source project can exploit this vulnerability; however, this would also apply to custom roles with similar privileges. The patched version include an improved RBA...
Affected versions of the crate have a bug where attacker-controlled input can result in the use of an out-of-bound array index. Rust detects the use of the out-of-bound index and causes the application to panic. An attacker may be able to use this to cause a denial-of-service. However, it is not possible for an attacker to read from or write to the application's address space.
Affected versions of the crate have several bugs where attacker-controlled input can result in the use of an out-of-bound array index. Rust detects the use of the out-of-bound index and causes the application to panic. An attacker may be able to use this to cause a denial-of-service. However, it is not possible for an attacker to read from or write to the application's address space.