ghsa

## Summary Dragging a file whose filename contains HTML is reflected verbatim into the page via the drag-and-drop helper, so any user who drops a crafted file on PrivateBin will execute arbitrary JavaScript within their own session (self-XSS). This allows an attacker who can entice a victim to drag or otherwise attach such a file to exfiltrate plaintext, encryption keys, or stored pastes before they are encrypted or sent. **Note 1:** as the malicious filename must contain the `>` character, the victim must not be using Windows for this to work, since this OS simply forbids this character in filenames. **Note 2:** most PrivateBin instances use the Content-Security-Policy header to prevent most use-cases of this vulnerability. This report will describe the impact as if this header had been disabled by the PrivateBin instance owner. ## Affected versions PrivateBin versions since 1.7.7. ## Conditions * Only macIOS or Linux users are affected, due to the way the `>` character is trea...

## Summary An unauthenticated Local File Inclusion exists in the template-switching feature: if `templateselection` is enabled in the configuration, the server trusts the `template` cookie and includes the referenced PHP file. An attacker can read sensitive data or, if they manage to drop a PHP file elsewhere, gain RCE. ## Affected versions PrivateBin versions since 1.7.7. ## Conditions - `templateselection` got enabled in `cfg/conf.php` - Visitor sets a cookie `template` pointing to an existing PHP file without it's suffix, using a path relative to the `tpl` folder. Absolute paths do not work. ## Impact The constructed path of the template file is checked for existence, then included. For PrivateBin project files this does not leak any secrets due to data files being created with PHP code that prevents execution, but if a configuration file without that line got created or the visitor figures out the relative path to a PHP script that directly performs an action without appropr...

# Summary A vulnerability in Apollo Federation's composition logic allowed some queries to Apollo Router to improperly bypass access controls on types/fields. Apollo Federation incorrectly allowed user-defined access control directives on interface types/fields, which could be bypassed by instead querying the implementing object types/fields in Apollo Router via inline or named fragments. A fix to composition logic in Federation now disallows interfaces types and fields to contain user-defined access control directives. ## Details Apollo Federation allows users to specify access control directives ([`@authenticated`, `@requiresScopes`, and `@policy`](https://www.apollographql.com/docs/graphos/routing/security/authorization#authorization-directives)) to protect object and interface types and fields. However, the GraphQL specification does not define inheritance rules for directives from interfaces to their implementations. When querying object or interface types/fields, Apollo Router w...

### Impact In js-yaml 4.1.0 and below, it's possible for an attacker to modify the prototype of the result of a parsed yaml document via prototype pollution (`__proto__`). All users who parse untrusted yaml documents may be impacted. ### Patches Problem is patched in js-yaml 4.1.1. ### Workarounds You can protect against this kind of attack on the server by using `node --disable-proto=delete` or `deno` (in Deno, pollution protection is on by default). ### References https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html

Mattermost versions < 11 fail to properly restrict access to archived channel search API which allows guest users to discover archived public channels via the `/api/v4/teams/{team_id}/channels/search_archived` endpoint

### Summary: An observable difference in error messaging was found in the Directus REST API. The `/items/{collection}` API returns different error messages for these two cases: 1. A user tries to access an existing collection which they are not authorized to access. 2. A user tries to access a non-existing collection. The two differing error messages leak the existence of collections to users which are not authorized to access these collections. ### Details: The following response returns an error message, when requesting a collection the user is not authorized to access. ``` GET /items/no-access { "errors": [ { "message": "You don't have permission to access collection \"no-access\" or it does not exist. Queried in root.", "extensions": { "reason": "You don't have permission to access collection \"no-access\" or it does not exist. Queried in root.", "code": "FORBIDDEN" } } ] } ``` The following response returns a different error mess...

## Summary A vulnerability allows authenticated users to search concealed/sensitive fields when they have read permissions. While actual values remain masked (`****`), successful matches can be detected through returned records, enabling enumeration attacks on sensitive data. ## Details The system permits search operations on concealed fields in the `directus_users` collection, including `token`, `tfa_secret`, `password`. Matching records are returned with masked values, but their presence confirms the searched value exists. The "Recommended Defaults" for "App Access" grant users full read permissions to their role/user records, inadvertently enabling them to search for any user's tokens, TFA secrets, and password hashes. Attackers can leverage known password hashes from breach databases to identify accounts with compromised passwords. # Impact This vulnerability enables: - **Token enumeration** - Verification of valid authentication tokens - **Password hash matching** - Identifi...

**Impact** This affects any LXD user in an environment where an unprivileged user may have root access to a container with an attached custom storage volume that has the `security.shifted` property set to `true` as well as access to the host as an unprivileged user. The most common case for this would be systems using `lxd-user` with the less privileged lxd group to provide unprivileged users with an isolated restricted access to LXD. Such users may be able to create a custom storage volume with the necessary property (depending on kernel and filesystem support) and can then write a setuid binary from within the container which can be executed as an unprivileged user on the host to gain root privileges. **Patches** Patches for this issue are available: - LXD 6 series: https://github.com/canonical/lxd/pull/16904 - LXD 5.21 LTS series: https://github.com/canonical/lxd/pull/16922 - LXD 5.0 LTS series: https://github.com/canonical/lxd/pull/16923 - LXD 4.0 LTS series: https://github.c...

### Impact The prosemirror_to_html gem is vulnerable to Cross-Site Scripting (XSS) attacks through malicious HTML attribute values. While tag content is properly escaped, attribute values are not, allowing attackers to inject arbitrary JavaScript code. **Who is impacted:** - Any application using prosemirror_to_html to convert ProseMirror documents to HTML - Applications that process user-generated ProseMirror content are at highest risk - End users viewing the rendered HTML output could have malicious JavaScript executed in their browsers **Attack vectors include:** - `href` attributes with `javascript:` protocol: `<a href="javascript:alert(document.cookie)">` - Event handlers: `<div onclick="maliciousCode()">` - `onerror` attributes on images: `<img src=x onerror="alert('XSS')">` - Other HTML attributes that can execute JavaScript ### Patches A fix is currently in development. Users should upgrade to version **0.2.1** or later once released. The patch escapes all HTML attrib...

### Impact Users who: 1. Use the exclusion operator somewhere in their authorization schema. 1. Have configured their SpiceDB server such that `--write-relationships-max-updates-per-call` is bigger than 6500. 1. Issue calls to WriteRelationships with a large enough number of updates that cause the payload to be bigger than what their datastore allows. Users will: 1. Receive a successful response from their `WriteRelationships` call, when in reality that call failed. 2. Receive incorrect permission check results, if those relationships had to be read to resolve the relation involving the exclusion. ### Patches Upgrade to v.145.2. ### Workarounds Set `--write-relationships-max-updates-per-call` to `1000`.