ghsa

### 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...

### Impact A vulnerability exists in stripe-cli versions 1.11.1 and higher where a plugin package containing a manifest with a malformed plugin shortname installed using the --archive-url or --archive-path flags can overwrite arbitrary files. The update addresses the path traversal vulnerability by removing the ability to install plugins from an archive URL or path. There has been no evidence of exploitation of this vulnerability. ### Recommendation Upgrade to stripe-cli v1.21.3. ### For more information Email us at [[email protected]](mailto:[email protected])

### Summary DNS rebinding is a method of manipulating resolution of domain names to let the initial DNS query hits an address and the second hits another one. For instance the host `make-190.119.176.200-rebind-127.0.0.1-rr.1u.ms` would be initially resolved to `190.119.176.200` and the next DNS issue to `127.0.0.1`. Please notice the following in the latest codebase: ```python def is_private_url(url: str): """ Raises exception if url is private :param url: url to check """ hostname = urlparse(url).hostname if not hostname: # Unable to find hostname in url return True ip = socket.gethostbyname(hostname) return ipaddress.ip_address(ip).is_private ``` As you can see, during the call to `is_private_url()` the initial DNS query would be issued by `ip = socket.gethostbyname(hostname)` to an IP (public one) and then due to DNS Rebinding, the next GET request would goes to the private one. ### PoC ```python from flask import Flask, requ...

A vulnerability was found in Windmill 1.380.0. It has been classified as problematic. Affected is an unknown function of the file backend/windmill-api/src/users.rs of the component HTTP Request Handler. The manipulation leads to improper restriction of excessive authentication attempts. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. Upgrading to version 1.390.1 is able to address this issue. The patch is identified as acfe7786152f036f2476f93ab5536571514fa9e3. It is recommended to upgrade the affected component.

### Impact sigstore-go is susceptible to a denial of service attack when a verifier is provided a maliciously crafted Sigstore Bundle containing large amounts of verifiable data, in the form of signed transparency log entries, RFC 3161 timestamps, and attestation subjects. The verification of these data structures is computationally expensive. This can be used to consume excessive CPU resources, leading to a denial of service attack. TUF's security model labels this type of vulnerability an "Endless data attack," and can lead to verification failing to complete and disrupting services that rely on sigstore-go for verification. The vulnerable loops are in the verification functions in the package `github.com/sigstore/sigstore-go/pkg/verify`. The first is the DSSE envelope verification loop in `verifyEnvelopeWithArtifact`, which decodes all the digests in an attestation can be found here: https://github.com/sigstore/sigstore-go/blob/725e508ed4933e6f5b5206e32af4bbe76f587b54/pkg/verify/...

In Eclipse Vert.x version 4.3.0 to 4.5.9, the gRPC server does not limit the maximum length of message payload (Maven GAV: io.vertx:vertx-grpc-server and io.vertx:vertx-grpc-client).  This is fixed in the 4.5.10 version.  Note this does not affect the Vert.x gRPC server based grpc-java and Netty libraries (Maven GAV: io.vertx:vertx-grpc)

### Impact Auth DB login form default cache directives allows browser to locally store sensitive data. This can be an issue on environments using shared computer resources. ### Patches Upgrade flask-appbuilder to version 4.5.1 ### Workarounds If upgrading is not possible configure your web server to send the following HTTP headers for /login: "Cache-Control": "no-store, no-cache, must-revalidate, max-age=0" "Pragma": "no-cache" "Expires": "0"