ghsa

Apache Airflow versions before 2.10.1 have a vulnerability that allows DAG authors to add local settings to the DAG folder and get it executed by the scheduler, where the scheduler is not supposed to execute code submitted by the DAG author. Users are advised to upgrade to version 2.10.1 or later, which has fixed the vulnerability.

### Impact Users running the Synthetic Monitoring agent in their local network are impacted. The authentication token used to communicate with the Synthetic Monitoring API is exposed thru a debugging endpoint. This token can be used to retrieve the Synthetic Monitoring checks created by the user and assigned to the agent identified with that token. The Synthetic Monitoring API will reject connections from already-connected agents, so access to the token does not guarantee access to the checks. ### Patches Fixed version is v0.12.0 Users are advised to rotate the agent tokens. After upgrading to version v0.12.0 or later, it's recommended that user's of distribution packages (e.g. Debian or RedHat and their derivatives) review the configuration stored in `/etc/synthetic-monitoring/synthetic-monitoring-agent.conf`, specifically the `API_TOKEN` variable which has been renamed to `SM_AGENT_API_TOKEN`. ### Workarounds With all previous versions, it's recommended that users review the a...

### Impact In distributed service mode, Pomerium's Authenticate service exposes pprof debug and prometheus metrics handlers to untrusted traffic. This can leak potentially sensitive environmental information or lead to limited denial of service conditions. ### Patches v0.17.1 ### Workarounds Block access to `/debug` and `/metrics` paths on the authenticate service. This can be done with any L7 proxy, including Pomerium's own proxy service. ### References https://github.com/pomerium/pomerium/pull/3212 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Pomerium](https://github.com/pomerium/pomerium) * Email us at [[email protected]](mailto:[email protected])

### Summary `gix-path` runs `git` to find the path of a configuration file associated with the `git` installation, but improperly resolves paths containing unusual or non-ASCII characters, in rare cases enabling a local attacker to inject configuration leading to code execution. ### Details In `gix_path::env`, the underlying implementation of the `installation_config` and `installation_config_prefix` functions calls `git config -l --show-origin` to find the path of a file to treat as belonging to the `git` installation. Affected versions of `gix-path` do not pass `-z`/`--null` to cause `git` to report literal paths (650a1b5cf25e086197cc55a68525a411e1c28031). Instead, to cover the occasional case that `git` outputs a quoted path, they attempt to parse the path by stripping the quotation marks: https://github.com/Byron/gitoxide/blob/1cfe577d461293879e91538dbc4bbfe01722e1e8/gix-path/src/env/git/mod.rs#L138-L142 The problem is that, when a path is quoted, it may change in substantial...

### Description The summary is that the proof of knowledge associated to a commitment is crucial to bind the commitment to the actual circuit variables that were supposed to be committed. However, the same σ is used for all proofs of knowledge for the commitments, which allows mixing between them, making it possible to fix the value of all but one commitment before choosing the circuit variable assignments. In more detail: To simplify notation, let us consider the case of two commitments, each to only a single variable. Let's say the basis elements for those commitments are `K_0` and `K_1`. Then the proving key will contain `K_0` and `K_1`, and also `σ*K_0` and `σ*K_1` for the proof of knowledge. The honest prover assigning a to the first circuit variable and b to the second will then produce commitments `D_0 = a*K_0` `D_1 = b*K_1` Out of the two D's, a challenge r for the commitment folding will be generated. The folded commitment will then be `D_folded = D_0 + r*D_1 = a*K_0 + r*b*K...

### Impact The vulnerability depends on user interaction by opening a malicious notebook with Markdown cells, or Markdown file using JupyterLab preview feature. A malicious user can access any data accessible from JupyterLite and perform arbitrary actions in JupyterLite environment. ### Patches JupyterLite 0.4.1 was patched. ### Workarounds There is no workaround for the underlying DOM Clobbering susceptibility. However, select plugins can be disabled on deployments which cannot update in a timely fashion to minimise the risk. These are: - `@jupyterlab/mathjax-extension:plugin` - users will loose ability to preview mathematical equations - `@jupyterlab/markdownviewer-extension:plugin` - users will loose ability to open Markdown previews - `@jupyterlab/mathjax2-extension:plugin` (if installed with optional `jupyterlab-mathjax2` package) - an older version of the mathjax plugin for JupyterLab 4.x To disable these extensions populate the `disabledExtensions` key in `jupyter-config...

### Impact XSLT transforms performed by various components are vulnerable to XML external entity injections. A processed XML file with a malicious DTD tag ( `<!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>` could produce XML containing data from the host system. This impacts use cases where org.hl7.fhir.core is being used to within a host where external clients can submit XML. ### Patches This issue has been patched in release 6.3.23 ### Workarounds None. ### References [MITRE CWE](https://cwe.mitre.org/data/definitions/611.html) [OWASP XML External Entity Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#transformerfactory)

This report concerns the Groth16 prover when used with commitments (as in `frontend.Committer`). To simplify exposition of the issue, I will focus on the case of a single commitment, to only private witnesses. But the issue should be present whenever commitments are used that include private witnesses. > The commitment to private witnesses `w_i` is computed as ``` c = sum_i w_i * b_i ``` where `b_i` would be `ProvingKey.CommitmentKeys[0].Basis[i]` in the code. While this is a binding commitment, it is not hiding. In practice, an adversary will know the points `b_i`, as they are part of the proving key, and can verify correctness of a guess for the values of `w_i` by computing `c'` as the right hand side of the above formula, and checking whether `c'` is equal to `c`. I attach a proof of concept that demonstrates this. This breaks the perfect zero-knowledge property of Groth16, so the Groth16 scheme using commitments to private witnesses as implemented by gnark fails to be a zk-SNARK...

### Context ICS has the following four messages that enable validators on the provider chain to perform different actions: - `MsgOptIn` -- adds a validator to the consumer chain’s active set - `MsgOptOut` -- removes a validator from the consumer chain’s active set - `MsgAssignConsumerKey` -- changes the consensus key used for a validator’s operations on a consumer chain - `MsgSetConsumerCommissionRate` -- sets a validator’s consumer-specific commission rate Normally, only the respective validators are allowed to perform these actions. ### Issue The upgrade to SDK 0.50, introduced a [signer](https://docs.cosmos.network/v0.50/build/building-modules/protobuf-annotations#signer) field to these messages. This field is used to authenticate the user sending the message to the system. However, there was no validation on the ICS side to check if the signer matches the provider address. As a result, any user could opt-in, opt-out, change the commission rate, or change what public key a...

When a canister method is called via `ic_cdk::call*`, a new Future `CallFuture` is created and can be awaited by the caller to get the execution result. Internally, the state of the Future is tracked and stored in a struct called `CallFutureState`. A bug in the polling implementation of the `CallFuture` allows multiple references to be held for this internal state and not all references were dropped before the `Future` is resolved. Since we have unaccounted references held, a copy of the internal state ended up being persisted in the canister's heap and thus causing a memory leak. ### Impact Canisters built in Rust with `ic_cdk` and `ic_cdk_timers` are affected. If these canisters call a canister method, use timers or heartbeat, they will likely leak a small amount of memory on every such operation. **In the worst case, this could lead to heap memory exhaustion triggered by an attacker.** Motoko based canisters are not affected by the bug. ### Patches The patch has been backporte...