ghsa

Reflected cross-site scripting (XSS) vulnerability in the instance settings for Accounts in Liferay Portal 7.4.3.44 through 7.4.3.97, and Liferay DXP 2023.Q3 before patch 6, and 7.4 update 44 through 92 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into the “Blocked Email Domains” text field

## Impact The library offers a function to generate an ed25519 key pair via `Ed25519KeyIdentity.generate` with an optional param to provide a 32 byte seed value, which will then be used as the secret key. **When no seed value is provided, it is expected that the library generates the secret key using secure randomness**. However, a recent change **broke this guarantee** and **uses an insecure seed for key pair generation**. Since the private key of this identity (`535yc-uxytb-gfk7h-tny7p-vjkoe-i4krp-3qmcl-uqfgr-cpgej-yqtjq-rqe`) is compromised, one could lose funds associated with the principal on ledgers or lose access to a canister where this principal is the controller. Users are asked to take proactive measures mentioned below in Workarounds:Users to protect their assets. ## Patches Patch for the vulnerability is **available in v1.0.1** for all the packages listed in the advisory. Please upgrade and deploy your canisters immediately. ## Workarounds ### Developers The recomm...

### Impact A maliciously crafted xAPI statement could be used to perform script or other tag injection in the LRS Statement Browser. ### Patches The problem is patched in version 1.2.17 of the LRS library and [version 0.7.5 of SQL LRS](https://github.com/yetanalytics/lrsql/releases/tag/v0.7.5). ### Workarounds No workarounds exist, we recommend upgrading to version 1.2.17 of the library or version 0.7.5 of SQL LRS immediately. ### References * [LRS Tag](https://github.com/yetanalytics/lrs/releases/tag/v1.2.17) * [LRS lib on Clojars](https://clojars.org/com.yetanalytics/lrs/versions/1.2.17) * [SQL LRS 0.7.5 Release](https://github.com/yetanalytics/lrsql/releases/tag/v0.7.5)

## ASA-2024-002: Default `PrepareProposalHandler` may produce invalid proposals when used with default `SenderNonceMempool` **Component**: Cosmos SDK **Criticality**: Medium **Affected** Versions: Cosmos SDK versions <= 0.50.3; <= 0.47.8 **Affected** Users: Chain developers, Validator and Node operators **Impact**: Denial of Service ## Summary When using the default `PrepareProposalHandler` and the default `SenderNonceMempool`, an issue was identified which may allow invalid blocks to be proposed when a single sender includes multiple transactions with non-sequential sequence numbers in certain conditions. If this state is reached, it can lead to a reduction in block production for a network. ## Next Steps for Impacted Parties If you are a chain developer on an affected version of the Cosmos SDK, it is advised to update to the latest available version of the Cosmos SDK for your project. Once a patched version is available, it is recommended that network operators upgrade. A Gith...

## ASA-2024-003: Missing `BlockedAddressed` Validation in Vesting Module **Component**: Cosmos SDK **Criticality**: Low **Affected Versions**: Cosmos SDK versions <= 0.50.3; <= 0.47.8 **Affected Users**: Chain developers, Validator and Node operators **Impact**: Denial of Service ## Description A vulnerability was identified in the `x/auth/vesting` module, which can allow a user to create a periodic vesting account on a blocked address, for example a non-initialized module account. Additional validation was added to prevent creation of a periodic vesting account in this scenario. If this case is triggered, there is the potential for a chain halt if the uninitialized account in question is called by `GetModuleAccount` in `Begin`/`EndBlock` of a module. This combination of an uninitialized blocked module account is not common. ## Next Steps for Impacted Parties If your chain has uninitialized blocked module accounts, it is recommended to proactively initialize them, as they are o...

We have identified a cross-site websocket hijacking (CSWSH) vulnerability within the control.ashx endpoint of MeshCentral. This component is the primary mechanism used within MeshCentral to perform administrative actions on the server. To demonstrate the impact of the vulnerability we developed a proof-of-concept which leveraged the cross-site websocket hijacking vulnerability to read the server configuration file to leak the sessionKey variable, generating login tokens, and generating an authentication cookie. The vulnerability is exploitable when an attacker is able to convince a victim end-user to click on a malicious link to a page hosting an attacker-controlled site. The attacker can then originate a cross-site websocket connection using client-side JavaScript code to connect to “control.ashx” as the victim user within MeshCentral. There are some caveats to exploiting this issue however as MeshCentral configures `SameSite=Lax` security setting on cookies which introduces some add...

### Summary Ever since https://github.com/agronholm/cbor2/pull/204 (or specifically https://github.com/agronholm/cbor2/commit/387755eacf0be35591a478d3c67fe10618a6d542) was merged, I can create a reproducible crash when running the snippet under PoC on a current Debian bullseye aarm64 on a Raspberry Pi 3 (I was **not** able to reproduce this on my x86_64 Laptop with Python 3.11; I suspect because there is enough memory to allocate still) ## Details ### PoC ```py import json import concurrent.futures import cbor2 def test(): obj = "x" * 131128 cbor_enc = cbor2.dumps(obj) return cbor2.loads(cbor_enc) with concurrent.futures.ProcessPoolExecutor() as executor: future = executor.submit(test) print(future.result()) ``` ``` malloc(): unsorted double linked list corrupted Traceback (most recent call last): File "test.py", line 14, in <module> print(future.result()) File "/usr/lib/python3.9/concurrent/futures/_base.py", line 440, in result return self.__get_...

### Impact Path disclosure in JavaScript variable ### Patches Patch in PrestaShop 8.1.4 ### References https://owasp.org/www-community/attacks/Full_Path_Disclosure Thanks to https://github.com/hugo-fasone

The `rquickjs` crate used by SurrealDB implements Rust bindings to the QuickJS C library and is used to execute SurrealDB scripting functions. The `rquickjs` function `Exception::throw_type` takes a string and returns an error object. Prior to version `0.4.2` of the crate, this string would be fed directly into `printf`, which will receive the error string as a format string with no additional arguments, leading to undefined behavior. This issue triggers when a SurrealDB scripting function returns an error and its input contains a format string such as `%s` or `%d`. This vulnerability can only affect SurrealDB servers explicitly enabling the scripting capability with `--allow-scripting` or `--allow-all` and equivalent environment variables `SURREAL_CAPS_ALLOW_SCRIPT=true` and `SURREAL_CAPS_ALLOW_ALL=true`. ### Impact An attacker with privileges to execute scripting functions with arbitrary inputs may be able to exploit this format string vulnerability in order read arbitrary memory...

The query executor would panic when executing a query containing a call to a built-in SurrealDB function that did not exist. This could occur accidentally in situations where the version of the SurrealDB client was newer than the SurrealDB server or when a pre-parsed query was provided to the server via a newer version of the SurrealDB SDK. ### Impact A client that is authorized to run queries in a SurrealDB server is able to craft and execute a pre-parsed query invoking a nonexistent built-in function, which will cause a panic. This will crash the server, leading to denial of service. ### Patches - Version 1.2.0 and later are not affected by this issue. ### Workarounds Concerned users unable to update may want to limit the ability of untrusted users to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automati...