ghsa

### Summary As of quinn-proto 0.11, it is possible for a server to `accept()`, `retry()`, `refuse()`, or `ignore()` an `Incoming` connection. However, calling `retry()` on an unvalidated connection exposes the server to a likely panic in the following situations: - Calling `refuse` or `ignore` on the resulting validated connection, if a duplicate initial packet is received - This issue can go undetected until a server's `refuse()`/`ignore()` code path is exercised, such as to stop a denial of service attack. - Accepting when the initial packet for the resulting validated connection fails to decrypt or exhausts connection IDs, if a similar initial packet that successfully decrypts and doesn't exhaust connection IDs is received. - This issue can go undetected if clients are well-behaved. The former situation was observed in a real application, while the latter is only theoretical. ### Details Location of panic: https://github.com/quinn-rs/quinn/blob/bb02a12a8435a7732a1d762783eea...

### Summary `gix-path` executes `git` to find the path of a configuration file that belongs to the `git` installation itself, but mistakenly treats the local repository's configuration as system-wide if no higher scoped configuration is found. In rare cases, this causes a less trusted repository to be treated as more trusted, or leaks sensitive information from one repository to another, such as sending credentials to another repository's remote. ### Details In `gix_path::env`, the underlying implementation of the `installation_config` and `installation_config_prefix` functions calls `git config -l --show-origin` and parses the first line of the output to extract the path to the configuration file holding the configuration variable of highest [scope](https://git-scm.com/docs/git-config#SCOPES): https://github.com/Byron/gitoxide/blob/12251eb052df30105538fa831e641eea557f13d8/gix-path/src/env/git/mod.rs#L91 https://github.com/Byron/gitoxide/blob/12251eb052df30105538fa831e641eea557f13...

### Impact The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. The `BareMetalHost` (BMH) CRD allows the `userData`, `metaData`, and `networkData` for the provisioned host to be specified as links to Kubernetes Secrets. There are fields for both the `Name` and `Namespace` of the Secret, meaning that the baremetal-operator will read a `Secret` from any namespace. A user with access to create or edit a `BareMetalHost` can thus exfiltrate a `Secret` from another namespace by using it as e.g. the `userData` for provisioning some host (note that this need not be a real host, it could be a VM somewhere). ### Limiting factors BMO will only read a key with the name `value` (or `userData`, `metaData`, or `networkData`), so that limits the exposure somewhat. `value` is probably a pretty common key though. Secrets used by _other_ `BareMetalHost`s in different namespaces are always vulnerable. It is probably relatively unusual for anyone other than c...

### Impact Versions of `actions/artifact` before 2.1.7 are vulnerable to arbitrary file write when using `downloadArtifactInternal`, `downloadArtifactPublic`, or `streamExtractExternal` for extracting a specifically crafted artifact that contains path traversal filenames. ### Patches Upgrade to version 2.1.7 or higher. ### References - https://snyk.io/research/zip-slip-vulnerability - https://github.com/actions/toolkit/pull/1724 ### CVE CVE-2024-42471 ### Credits Justin Taft from Google

**Name**: ASA-2024-009: State syncing validator from malicious node may lead to a chain split **Component**: CometBFT **Criticality**: Medium ([ACMv1.2](https://github.com/interchainio/security/blob/main/resources/CLASSIFICATION_MATRIX.md): I:Moderate; L: Possible) **Affected versions**: >= 0.34.0, <= 0.34.33, >=0.37.0, <= 0.37.10, >= 0.38.0, <= 0.38.11 ### Summary The state sync protocol retrieves a snapshot of the application and installs it in a fresh node. In order for this node to be ready to run consensus and block sync from the installed snapshot height, we also need to install a valid `State` in the node, which is the starting state from which it is able to validate new blocks and append them to the blockchain. The `State` object used by state sync is computed using the light client protocol, which retrieves information about committed blocks from at least two RPC endpoints. The light client protocol performs several state validations and, in particular, compares the state p...

### Impact runc 1.1.13 and earlier as well as 1.2.0-rc2 and earlier can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with os.MkdirAll. While this can be used to create empty files, existing files **will not** be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack's scope but the exact scope of protection hasn't been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The CVSS score for this vulnerability is CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N (Low severity, 3....

### Summary Pimcore 10.6.x and Enterprise 10.6.x versions currently depend on PHPOffice/PhpSpreadsheet version 1.x, which has recently been identified with a security vulnerability (CVE-2024-45048). To mitigate this issue, it is recommended to update to the latest version 2.2.2. For more details, please refer to the official advisory: [GHSA-ghg6-32f9-2jp7](https://github.com/advisories/GHSA-ghg6-32f9-2jp7).

### Impact It is possible to inject and run code within the template if the attacker has access to write the template name. ```js const { template } = require('@blakeembrey/template'); template("Hello {{name}}!", "exploit() {} && ((()=>{ console.log('success'); })()) && function pwned"); ``` ### Patches Upgrade to 1.2.0. ### Workarounds Don't pass untrusted input as the template display name, or don't use the display name feature. ### References Fixed by removing in https://github.com/blakeembrey/js-template/commit/b8d9aa999e464816c6cfb14acd1ad0f5d1e335aa.

### Impact Tina search token leaked via lock file (tina-lock.json) in TinaCMS. Sites building with @tinacms/cli < 1.6.2 that use a search token are impacted. If your Tina-enabled website has search setup, you should rotate that key immediately. ### Patches This issue has been patched in @tinacms/[email protected] ### Workarounds Upgrading, and rotating search token is required for the proper fix. ### References https://github.com/tinacms/tinacms/pull/4758

Pagefind initializes its dynamic JavaScript and WebAssembly files relative to the location of the first script you load. This information is gathered by looking up the value of `document.currentScript.src`. It is possible to "clobber" this lookup with otherwise benign HTML on the page, for example: ```html <img name="currentScript" src="blob:https://xxx.xxx.xxx/ui.js"></img> ``` This will cause `document.currentScript.src` to resolve as an external domain, which will then be used by Pagefind to load dependencies. This exploit would only work in the case that an attacker could inject HTML to your live, hosted, website. In these cases, this would act as a way to escalate the privilege available to an attacker. This assumes they have the ability to add some elements to the page (for example, `img` tags with a `name` attribute), but not others, as adding a `script` to the page would itself be the XSS vector. Pagefind has tightened this resolution by ensuring the source is loaded from a...