ghsa

### Impact A bug in Wagtail's [`parse_query_string`](https://docs.wagtail.org/en/stable/topics/search/searching.html#wagtailsearch-query-string-parsing) would result in it taking a long time to process suitably crafted inputs. When used to parse sufficiently long strings of characters without a space, `parse_query_string` would take an unexpectedly large amount of time to process, resulting in a denial of service. In an initial Wagtail installation, the vulnerability can be exploited by any Wagtail admin user. It cannot be exploited by end users. If your Wagtail site has a custom search implementation which uses `parse_query_string`, it may be exploitable by other users (e.g. unauthenticated users). ### Patches Patched versions have been released as Wagtail 5.2.6, 6.0.6 and 6.1.3. This vulnerability affects all unpatched versions from Wagtail 2.0 onwards. ### Workarounds Site owners who are unable to upgrade to a patched version can limit the length of search terms passed to `pa...

Authentication would not be properly validated when an already authenticated scope user would use the `use` method or `USE` clause to switch working databases in a session. If there was a user record in the new database with identical record identifier as the original record that the user authenticated with in the original database, this could result in the user being able to perform actions under the identity of the unrelated user in the new database. This issue does not affect system users at any level. By default, record identifiers are randomly generated with sufficient complexity to prevent the identifier collision required to trigger this issue. However, the issue may trigger in situations where multiple databases in the same SurrealDB instance are using explicitly defined or incremental record identifiers to identify users on an identically named table. ### Impact Under the circumstances described above, a user who has an authenticated session as a scope user in a database co...

### Summary An issue in the OpenSearch observability plugins allows unintended access to private tenant resources like notebooks. The system did not properly check if the user was the resource author when accessing resources in a private tenant, leading to potential data being revealed. ### Impact The lack of proper access control validation for private tenant resources in the OpenSearch observability and reporting plugins can lead to unintended data access. If an authorized user with observability or reporting roles is aware of another user's private tenant resource ID, such as a notebook, they can potentially read, modify, or take ownership of that resource, despite not being the original author, thus impacting the confidentiality and integrity of private tenant resources. The impact is confined to private tenant resources, where authorized users may gain inappropriate visibility into data intended to be private from other users within the same OpenSearch instance, potentially vio...

### Impact A Denial of Service (DoS) condition was identified in Next.js. Exploitation of the bug can trigger a crash, affecting the availability of the server. **This vulnerability can affect all Next.js deployments on the affected versions.** ### Patches This vulnerability was resolved in Next.js 13.5 and later. We recommend that users upgrade to a safe version. ### Workarounds There are no official workarounds for this vulnerability. #### Credit We'd like to thank Thai Vu of [flyseccorp.com](http://flyseccorp.com/) for responsible disclosure of this vulnerability.

### Impact The admin panel is subject to potential XSS attach in case the attacker manages to modify some records being uploaded to the server. The attacker is able to change e.g. to `<svg onload=alert('XSS')>` if they know how to craft these requests themselves. And then enter the returned blob ID to the form inputs manually by modifying the edit page source. ### Patches Available in versions 0.27.6 and 0.28.1. ### Workarounds Review the user accounts that have access to the admin panel (i.e. general Administrators, and participatory space's Administrators) and remove access to them if they don't need it. ### References OWASP ASVS v4.0.3-5.1.3

### Impact The pagination feature used in searches and filters is subject to potential XSS attack through a malformed URL using the GET parameter `per_page`. ### Patches Patched in version 0.27.6 and 0.28.1 ### References OWASP ASVS v4.0.3-5.1.3 ### Credits This issue was discovered in a security audit organized by the [mitgestalten Partizipationsbüro](https://partizipationsbuero.at/) and funded by [netidee](https://www.netidee.at/) against Decidim done during April 2024. The security audit was implemented by [AIT Austrian Institute of Technology GmbH](https://www.ait.ac.at/),

### Impact If an attacker can infer the slug or URL of an unpublished or private resource, and this resource can be embedded (such as a Participatory Process, an Assembly, a Proposal, a Result, etc), then some data of this resource could be accessed. ### Patches version 0.27.6 https://github.com/decidim/decidim/commit/1756fa639ef393ca8e8bb16221cab2e2e7875705 ### Workarounds Disallow access through your web server to the URLs finished with `/embed.html`

In [v1.5](https://github.com/PrivateBin/PrivateBin/blob/master/CHANGELOG.md#15-2022-12-11) we introduced the YOURLS server-side proxy. The idea was to allow using the YOURLs URL shortener without running the YOURLs instance without authentication and/or exposing the authentication token to the public, allowing anyone to shorten any URL. With the proxy mechanism, anyone can shorten any URL pointing to the configured PrivateBin instance. The vulnerability allowed other URLs to be shortened, as long as they contain the PrivateBin instance, defeating the limit imposed by the proxy. Neither the confidentially of existing pastes on the server nor the configuration options including the YOURLs token are affected. ### Impact This issue only affects non-standard configurations of PrivateBin. Instances are affected if all of the following conditions are met: 1. The PrivateBin instance enables URL shortening. 2. A YOURLs URL shortener is used and it is configured not to be public and require a...

### Summary This advisory board aims to describe two vulnerabilities found in the Evmos codebase: - _Authorization check on the fundVestingAccount_: unauthorized spend of funds. ### Details #### Authorization check on the fundVestingAccount With the current implementation, a user can create a vesting account with a 3rd party account (EOA or contract) as funder. Then, this user can create an authorization for the contract.CallerAddress, this is the authorization checked in the code. But the funds are taken from the funder address provided in the message. Consequently, the user can fund a vesting account with a 3rd party account without its permission. The funder address can be any address, so this vulnerability can be used to drain all the accounts in the chain. ### Severity Based on [ImmuneFi Severity Classification System](https://immunefisupport.zendesk.com/hc/en-us/articles/13332717597585-Severity-Classification-System) the severity was evaluated to Critical since the attack c...

## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-x6p7-44rh-m3rr. This link has been maintained to preserve external references. ## Original Description The Login by Auth0 plugin for WordPress is vulnerable to Reflected Cross-Site Scripting via the ‘wle’ parameter in all versions up to, and including, 4.6.0 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that execute if they can successfully trick a user into performing an action such as clicking on a link.