ghsa

### Impact [`tf.raw_ops.DynamicStitch`](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/kernels/dynamic_stitch_op.cc) specifies input sizes when it is [registered](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/core/ops/data_flow_ops.cc). ```cpp REGISTER_OP("DynamicStitch") .Input("indices: N * int32") .Input("data: N * T") .Output("merged: T") .Attr("N : int >= 1") .Attr("T : type") .SetShapeFn(DynamicStitchShapeFunction); ``` When it receives a differing number of inputs, such as when it is called with an `indices` size 1 and a `data` size 2, it will crash. ```python import tensorflow as tf # indices = 1*[tf.random.uniform([1,2], dtype=tf.dtypes.int32, maxval=100)] indices = [tf.constant([[0, 1]]),] # data = 2*[tf.random.uniform([1,2], dtype=tf.dtypes.float32, maxval=100)] data = [tf.constant([[5, 6]]), tf.constant([[7, 8]])] tf.raw_ops.DynamicStitch( indices=indices, data=data) ``` ### Patches We have patch...

### Impact Users of this library will be affected when using this library, the incoming secret will be disclosed unintentionally ### Patches This have already been solved. ### Workarounds No, It cannot be patched without upgrading ### References No ### For more information If you have any questions or comments about this advisory: * Email us at [email address](mailto:[email protected])

### Impact immudb client SDKs use server's UUID to distinguish between different server instance so that the client can connect to different immudb instances and keep the state for multiple servers. SDK does not validate this uuid and can accept any value reported by the server. A malicious server can change the reported UUID tricking the client to treat it as a different server thus accepting a state completely irrelevant to the one previously retrieved from the server. ### Patches The following Go SDK versions are not vulnerable | **SDK** | **Version** | |-------|------------| | [go](pkg.go.dev/github.com/codenotary/immudb/pkg/client) | 1.4.1 | ### Workarounds When initializing an immudb client object, a custom state handler can be used to store the state. Providing custom implementation that ignores the server UUID can be used to ensure that even if the server changes the UUID, client will still consider it to be the same server. ### For more information If you have any ques...

### Impact In certain scenario a malicious immudb server can provide a falsified proof that will be accepted by the client SDK signing a falsified transaction replacing the genuine one. This situation can not be triggered by a genuine immudb server and requires the client to perform a specific list of verified operations resulting in acceptance of an invalid state value. This vulnerability only affects immudb client SDKs, the immudb server itself is not affected by this vulnerability. ### Detailed description immudb uses Merkle Tree enhanced with additional linear part to perform consistency proofs between two transactions. The linear part is built from the last leaf node of the Merkle Tree compensating for transactions that were not yet consumed by the Merkle Tree calculation. The Merkle Tree part is then used to perform proofs for things that are in transaction range covered by the Merkle Tree where the linear part is used to check those that are not yet in the Merkle Tree. Whe...

### Impact All lnd nodes before version `v0.15.4` are vulnerable to a block parsing bug that can cause a node to enter a degraded state once encountered. In this degraded state, nodes can continue to make payments and forward HTLCs, and close out channels. Opening channels is prohibited, and also on chain transaction events will be undetected. This can cause loss of funds if a CSV expiry is researched during a breach attempt or a CLTV delta expires forgetting the funds in the HTLC. ### Patches A patch is available starting with lnd `v0.15.4`. ### Workarounds Nodes can use the `lncli updatechanpolicy` RPC call to increase their CLTV value to a very high amount or increase their fee policies. This will prevent nodes from routing through your node, meaning that no pending HTLCs can be present. ### References https://github.com/lightningnetwork/lnd/issues/7096 https://github.com/lightningnetwork/lnd/releases/tag/v0.15.4-beta

### Impact Users using the VelaUX APIServer could be affected by this vulnerability. When using Helm Chart as the component delivery method, the request address of the warehouse is not restricted, and there is a blind SSRF vulnerability. ### Patches For users who're using v1.6, please update the v1.6.1. For users who're using v1.5, please update the v1.5.8. ### References Fix by: #5000 ### For more information If you have any questions or comments about this advisory: * Open an issue in [KubeVela repo](https://github.com/kubevela/kubevela) * Email us at [here](https://github.com/kubevela/kubevela#contact-us)

Zenario CMS 9.3.57186 is vulnerable to Cross Site Scripting (XSS) via the Nest library module.

Zenario CMS 9.3.57186 is is vulnerable to Cross Site Scripting (XSS) via profile.

Zenario CMS 9.3.57186 is vulnerable to Cross Site Scripting (XSS) via svg,Users & Contacts.

Zenario CMS 9.3.57186 is vulnerable to Cross Site Scripting (XSS) via News articles.