ghsa

### Impact Since [ydb-go-sdk/v3.48.6](https://github.com/ydb-platform/ydb-go-sdk/blob/v3.48.6/internal/balancer/balancer.go#L71) if you use a custom credentials object (implementation of interface [Credentials](https://github.com/ydb-platform/ydb-go-sdk/blob/master/credentials/credentials.go#L10)) it may leak into logs. This happens because this object could be serialized into an error message using `fmt.Errorf("something went wrong (credentials: %q)", credentials)` during connection to the YDB server. Printf func use placeholder `%q` for string representation of argument with quotes. If an argument implements interface `fmt.Stringer`, it will used through `String()` func. In other cases used fallback - serialization with reflection. If such logging occurred, a malicious user with access to logs could read sensitive information (i.e. credentials) information and use it to get access to the database. Who is impacted: applications with custom credentials object with an explicit token ...

### Impact During a security audit of Artifact Hub's code base, a security researcher at [OffSec](https://www.offsec.com/) identified a bug in which by using symbolic links in certain kinds of repositories loaded into Artifact Hub, it was possible to read internal files. Artifact Hub indexes content from a variety of sources, including git repositories. When processing git based repositories, Artifact Hub clones the repository and, depending on the artifact kind, reads some files from it. During this process, in some cases, no validation was done to check if the file was a symbolic link. This made possible to read arbitrary files in the system, potentially leaking sensitive information. ### Patches This issue has been resolved in version [1.16.0](https://artifacthub.io/packages/helm/artifact-hub/artifact-hub?modal=changelog&version=1.16.0).

### Impact During a security audit of Artifact Hub's code base, a security researcher at [OffSec](https://www.offsec.com/) identified a bug in which a default unsafe rego built-in was allowed to be used when defining authorization policies. Artifact Hub includes a fine-grained authorization mechanism that allows organizations to define what actions can be performed by their members. It is based on customizable authorization policies that are enforced by the [Open Policy Agent](https://www.openpolicyagent.org/). Policies are written using [rego](https://www.openpolicyagent.org/docs/latest/#rego) and their data files are expected to be json documents. By default, `rego` allows policies to make HTTP requests, which can be abused to send requests to internal resources and forward the responses to an external entity. In the context of Artifact Hub, this capability should have been disabled. ### Patches This issue has been resolved in version [1.16.0](https://artifacthub.io/packages/helm...

### Impact During a security audit of Artifact Hub's code base, a security researcher at [OffSec](https://www.offsec.com/) identified a bug in which the `registryIsDockerHub` function was only checking that the registry domain had the `docker.io` suffix. Artifact Hub allows providing some Docker credentials that are used to increase the rate limit applied when interacting with the Docker Hub registry API to read publicly available content. Due to the incorrect check described above, it'd be possible to hijack those credentials by purchasing a domain which ends with `docker.io` and deploying a fake OCI registry on it. <https://artifacthub.io/> uses some credentials that only have permissions to read public content available in the Docker Hub. However, even though credentials for private repositories (disabled on `artifacthub.io`) are handled in a different way, other Artifact Hub deployments could have been using them for a different purpose. ### Patches This issue has been resolve...

### Impact A [cross-site scripting (XSS)](https://owasp.org/www-community/attacks/xss/) vulnerability was discovered in TinyMCE’s Notification Manager API. The vulnerability exploits TinyMCE's unfiltered notification system, which is used in error handling. The conditions for this exploit requires carefully crafted malicious content to have been inserted into the editor and a notification to have been triggered. When a notification was opened, the HTML within the text argument was displayed unfiltered in the notification. The vulnerability allowed arbitrary JavaScript execution when an notification presented in the TinyMCE UI for the current user. This issue could also be exploited by any integration which uses a TinyMCE notification to display unfiltered HTML content. ### Patches This vulnerability has been patched in TinyMCE 5.10.8 and TinyMCE 6.7.1 by ensuring that the HTML displayed in the notification is sanitized, preventing the exploit. ### Fix To avoid this vulnerability...

### Impact A [mutation cross-site scripting](https://researchgate.net/publication/266654651_mXSS_attacks_Attacking_well-secured_web-applications_by_using_innerHTML_mutations) (mXSS) vulnerability was discovered in TinyMCE’s core undo and redo functionality. When a carefully-crafted HTML snippet passes the XSS sanitisation layer, it is manipulated as a string by internal trimming functions before being stored in the undo stack. If the HTML snippet is restored from the undo stack, the combination of the string manipulation and reparative parsing by either the browser's native [DOMParser API](https://developer.mozilla.org/en-US/docs/Web/API/DOMParser) (TinyMCE 6) or the [SaxParser API](https://www.tiny.cloud/docs/api/tinymce.html/tinymce.html.saxparser/) (TinyMCE 5) mutates the HTML maliciously, allowing an XSS payload to be executed. ​This vulnerability also impacts these related TinyMCE APIs and plugins:​ * [`tinymce.Editor.getContent({ format: 'raw' })`](https://tiny.cloud/docs/tinymce...

### Impact Any users who are using the `wget` extractor and view the content it outputs. The impact is potentially severe if you are logged in to the ArchiveBox admin site in the same browser session and view an archived malicious page designed to target your ArchiveBox instance. Malicious JS could potentially act using your logged-in admin credentials and add/remove/modify snapshots, add/remove/modify ArchiveBox users, and generally do anything an admin user could do. The impact is less severe for non-logged-in users, as malicious JS cannot *modify* any archives, but it can still *read* all the other archived content by fetching the snapshot index and iterating through it. Because all of ArchiveBox's archived content is served from the same host and port as the admin panel, when archived pages are viewed the JS executes in the same context as all the other archived pages (and the admin panel), defeating most of the browser's usual CORS/CSRF security protections and leading to th...

(This advisory is canonically <https://advisories.nats.io/CVE/secnote-2023-01.txt>) ## Background NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing. NATS users exist within accounts, and once using accounts, the old authorization block is not applicable. ## Problem Description Without any authorization rules in the nats-server, users can connect without authentication. Before nats-server 2.2.0, all authentication and authorization rules for a nats-server lived in an "authorization" block, defining users. With nats-server 2.2.0 all users live inside accounts. When using the authorization block, whose syntax predates this, those users will be placed into the implicit global account, "$G". Users inside accounts go into the newer "accounts" block. If an "accounts" block is defined, in simple deployment scenarios this is often used only to enable client access to the system account. Wh...

### Impact First, a little bit of background. So, in the beginning, Bunkum's `AuthenticationService` only supported injecting `IUser`s. However, as Refresh and SoundShapesServer implemented permissions systems support for injecting `IToken`s into endpoints was added. All was well until 4.0. Bunkum 4.0 then changed to enforce relations between `IToken`s and `IUser`s. This wasn't implemented in a very good way in the `AuthenticationService`, and ended up breaking caching in such a way that cached tokens would persist after the lifetime of the request - since we tried to cache both tokens and users. From that point until now, from what I understand, Bunkum was attempting to use that cached token at the start of the next request once cached. Naturally, when that token expired, downstream projects like Refresh would remove the object from Realm - and cause the object in the cache to be in a detached state, causing an exception from invalid use of `IToken.User`. So in other words, a use-af...

### Impact The Apollo Router is a configurable, high-performance graph router written in Rust to run a federated supergraph that uses Apollo Federation. Affected versions are subject to a Denial-of-Service (DoS) type vulnerability which causes the Router to panic and terminate when a multi-part response is sent. When users send queries to the router that uses the `@defer` or Subscriptions, the Router will panic. To be vulnerable, users of Router must have a coprocessor with `coprocessor.supergraph.response` configured in their `router.yaml` and also to support either `@defer` or Subscriptions. ### Patches Router version 1.33.0 has a fix for this vulnerability. https://github.com/apollographql/router/pull/4014 fixes the issue. ### Workarounds For affected versions, avoid using the coprocessor supergraph response: ```yml # do not use this stage in your coprocessor configuration coprocessor: supergraph: response: ``` Or you can disable defer and subscriptions support: ```y...