ghsa

### Summary The polymorphic field type stores the classes to operate on when updating a record with user input, and does not validate them in the back end. This can lead to unexpected behavior, remote code execution, or application crashes when viewing a manipulated record. ### Details After reviewing the polymorphic field implementation and performing some black box approaches, we identified a potential security issue related to the use of safe_constantize / constantize. This Rails functionality is capable of searching for classes within the Rails context and returning the class for further use. Because Avo does not validate user input when updating or creating a new polymorphic resource, it is possible to create database entries with completely different or invalid class names than the preselected ones. Avo assumes that the class specified by the user request is a valid one and attempts to work with it, which may result in dangerous behavior and code execution. ### PoC ![image](ht...

### Impact Kiwi TCMS allows users to upload attachments to test plans, test cases, etc. Earlier versions of Kiwi TCMS had introduced upload validators in order to prevent potentially dangerous files from being uploaded and Content-Security-Policy definition to prevent cross-site-scripting attacks. The upload validation checks were not 100% robust which left the possibility to circumvent them and upload a potentially dangerous file which allows execution of arbitrary JavaScript in the browser. Additionally we've discovered that Nginx's `proxy_pass` directive will strip some headers negating protections built into Kiwi TCMS when served behind a reverse proxy. ### Patches - Improved file upload validation code - Updated Nginx reverse proxy configuration for ***.tenant.kiwitcms.org** ### Workarounds If serving Kiwi TCMS behind a reverse proxy make sure that additional header values are still passed to the client browser. If they aren't redefine them inside the proxy configuration. S...

### Impact An attacker who controls or compromises a registry can lead a user to verify the wrong artifact. ### Patches The problem has been fixed in the release [v1.0.0-rc.6](https://github.com/notaryproject/notation-go/releases/tag/v1.0.0-rc.6). Users should upgrade their notation-go library to [v1.0.0-rc.6](https://github.com/notaryproject/notation-go/releases/tag/v1.0.0-rc.6) or above. ### Workarounds User should use secure and trusted container registries. ### Credits The `notation` project would like to thank Adam Korczynski (@AdamKorcz) for responsibly disclosing the issue found during an security audit (facilitated by OSTIF and sponsored by CNCF) and Shiwei Zhang (@shizhMSFT), Pritesh Bandi (@priteshbandi) for root cause analysis.

### Impact An attacker who controls or compromises a registry can make the registry serve an infinite number of signatures for the artifact, causing a denial of service to the host machine running `notation verify`. ### Patches The problem has been fixed in the release [v1.0.0-rc.6](https://github.com/notaryproject/notation/releases/tag/v1.0.0-rc.6). Users should upgrade their notation packages to [v1.0.0-rc.6](https://github.com/notaryproject/notation/releases/tag/v1.0.0-rc.6) or above. ### Workarounds User should use secure and trusted container registries ### Credits The `notation` project would like to thank Adam Korczynski (@AdamKorcz) for responsibly disclosing the issue found during an security audit (facilitated by OSTIF and sponsored by CNCF) and Shiwei Zhang (@shizhMSFT) for root cause analysis.

### Impact An attacker who controls or compromises a registry can make the registry serve an infinite number of signatures for the artifact, causing a denial of service to the host machine running `notation verify`. ### Patches The problem has been fixed in the release [v1.0.0-rc.6](https://github.com/notaryproject/notation/releases/tag/v1.0.0-rc.6). Users should upgrade their notation packages to [v1.0.0-rc.6](https://github.com/notaryproject/notation/releases/tag/v1.0.0-rc.6) or above. ### Workarounds User should use secure and trusted container registries. ### Credits The `notation` project would like to thank Adam Korczynski (@AdamKorcz) for responsibly disclosing the issue found during an security audit (facilitated by OSTIF and sponsored by CNCF) and Shiwei Zhang (@shizhMSFT) for root cause analysis.

### Impact A discovered oEmbed or image URL can bypass the `url_preview_url_blacklist` setting potentially allowing server side request forgery or bypassing network policies. Impact is limited to IP addresses allowed by the `url_preview_ip_range_blacklist` setting (by default this only allows public IPs) and by the limited information returned to the client: * For discovered oEmbed URLs, any non-JSON response or a JSON response which includes non-oEmbed information is discarded. * For discovered image URLs, any non-image response is discarded. Systems which have URL preview disabled (via the `url_preview_enabled` setting) or have not configured a `url_preview_url_blacklist` are not affected. Because of the uncommon configuration required, the limited information a malicious user, and the amount of guesses/time the attack would need; the severity is rated as low. ### Patches The issue is fixed by #15601. ### Workarounds The default configuration of the `url_preview_ip_range_black...

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