Security
Headlines
HeadlinesLatestCVEs

Source

ghsa

GHSA-8rc9-vxjh-qjf2: Vega's validators able to submit duplicate transactions

A vulnerability exists that allows a malicious validator to trick the Vega network into re-processing past Ethereum events from Vega’s Ethereum bridge. For example, a deposit to the collateral bridge for 100USDT that credits a party’s general account on Vega, can be re-processed 50 times resulting in 5000USDT in that party’s general account. This is without depositing any more than the original 100USDT on the bridge. Despite this exploit requiring access to a validator's Vega key, a validator key can be obtained at the small cost of 3000VEGA, the amount needed to announce a new node onto the network. The steps to carry out this exploit are as follows: 1. Cause an Ethereum event on one of the bridge contracts e.g a deposit to the collateral bridge, or the staking bridge 2. This will result in the Ethereum-event-forwarder of each node to submit a ChainEvent transaction to the Vega network corresponding to that event 3. Scrape the valid chain event transaction from the Tendermint block ...

ghsa
#vulnerability#git
GHSA-6mjq-h674-j845: netty-handler SniHandler 16MB allocation

### Summary The `SniHandler` can allocate up to 16MB of heap for each channel during the TLS handshake. When the handler or the channel does not have an idle timeout, it can be used to make a TCP server using the `SniHandler` to allocate 16MB of heap. ### Details The `SniHandler` class is a handler that waits for the TLS handshake to configure a `SslHandler` according to the indicated server name by the `ClientHello` record. For this matter it allocates a `ByteBuf` using the value defined in the `ClientHello` record. Normally the value of the packet should be smaller than the handshake packet but there are not checks done here and the way the code is written, it is possible to craft a packet that makes the `SslClientHelloHandler` 1/ allocate a 16MB `ByteBuf` 2/ not fail `decode` method `in` buffer 3/ get out of the loop without an exception The combination of this without the use of a timeout makes easy to connect to a TCP server and allocate 16MB of heap memory per connection. ...

GHSA-298m-hvgh-x9cw: Alluxio Cross Site Scripting vulnerability

Cross Site Scripting vulnerability in Alluxio v.1.8.1 allows a remote attacker to executea arbitrary code via the path parameter in the browse board component.

GHSA-6643-h7h5-x9wh: Langchain vulnerable to arbitrary code execution

Langchain 0.0.171 is vulnerable to Arbitrary code execution in `load_prompt`.

GHSA-6vf2-mfmr-qqqw: Liufee CMS File Upload vulnerability

File Upload vulnerability in Liufee CMS, AKA Feehicms v.2.0.8 allows a remote attacker to execute arbitrary code via the `/admin/index.php?r=admin-user%2Fupdate-self` component.

GHSA-4cw3-rhqx-vqwr: GilaCMS Cross Site Request Forgery vulnerability

Cross Site Request Forgery vulnerability in Gila GilaCMS v.1.11.4 allows a remote attacker to execute arbitrary code via the `cm/update_rows/user` parameter.

GHSA-m3v5-gjj9-rg24: Craft CMS vulnerable to HTML injection

Craft CMS through 4.4.9 is vulnerable to HTML Injection.

GHSA-7xqx-xwg9-jx34: NodCMS Cross Site Scripting vulnerability

Cross Site Scripting vulnerability in khodakhah NodCMS v.3.0 allows an attacker with administrative privileges to execute arbitrary code and gain access to sensitive information via a crafted script to the address parameter.

GHSA-gqr4-cvf4-3957: YiiCMS Cross Site Scripting vulnerability

Cross Site Scripting vulnerability in YiiCMS v.1.2.0 and prior allows a remote attacker to execute arbitrary code via the news function. A fix is available at commit 4a9d68564eb78d9f64e3f5dd77186a154093615b.

GHSA-q3q5-qvh5-cmw5: liufee CMS File Upload vulnerability

File Upload vulnerability in liufee CMS v.2.0.7.1 allows a remote attacker to execute arbitrary code via the image suffix function.