ghsa

LavaLite CMS v 9.0.0 was discovered to be vulnerable to a host header injection attack.

An attacker that has gained access to certain private information can use this to act as other user. Vendor: The Apache Software Foundation Versions Affected: Apache OpenMeetings from 3.1.3 before 7.1.0

Mattermost fails to restrict a user with permissions to edit other users and to create personal access tokens from elevating their privileges to system admin

An attacker who has gained access to an admin account can perform RCE via null-byte injection Vendor: The Apache Software Foundation Versions Affected: Apache OpenMeetings from 2.0.0 before 7.1.0

A cross-site scripting (XSS) vulnerability in PrestaShop v1.7.7.4 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the message parameter in /contactform/contactform.php.

### Impact This security advisory lists multiple concerns about how in-toto uses PGP keys. The findings are aggregated here, because they are all eligible to the same mitigation strategy. Note that the findings are rated with different severities (see inline) and the highest score was chosen for this advisory: - **PGP Key Creation Time Not Validated** (severity: low) in-toto does not check, if the validity period of a PGP Key (starting with the key creation time) is in the future, when copying the key from GnuPG to a layout, or when verifying signatures. A validity period in the future is usually a sign of a wrong system clock, meaning it can’t be trusted for verifying the validity period. A MITM attacker who is able to manipulate delivered software products might also be able to control the system time by manipulating NTP. In a scenario where an attacker gained control over two expired subkeys with no overlapping validity period, the attacker could set the system time to a time be...

### Impact The in-toto configuration is read from various directories and allows users to configure the behavior of the framework. The files are from directories following the XDG base directory specification [1]. Among the files read is `.in_totorc` which is a hidden file in the directory in which in-toto is run. If an attacker controls the inputs to a supply chain step, they can mask their activities by also passing in an `.in_totorc` file that includes the necessary exclude patterns and settings. RC files are widely used in other systems [2] and security issues have been discovered in their implementations as well [3]. We found in our conversations with in-toto adopters that `in_totorc` is not their preferred way to configure in-toto. As none of the options supported in `in_totorc` is unique, and can be set elsewhere using API parameters or CLI arguments, we decided to drop support for `in_totorc`. ### Other Recommendations Sandbox functionary code as recommended in https://gith...

### Impact Execute Javascript code on victim browsers and potentially steal cookies to takeover their account. ### Patches Update to version 10.5.21 or apply this patches manually https://github.com/pimcore/pimcore/commit/7e32cc28145274ddfc30fb791012d26c1278bd38.patch ### Workarounds Apply patches manually: https://github.com/pimcore/pimcore/commit/7e32cc28145274ddfc30fb791012d26c1278bd38.patch ### References https://huntr.dev/bounties/e1001870-b8d8-4921-8b9c-bbdfb1a1491e/

### Impact The pimcore application is vulnerable to Formula Injection/CSV Injection via the Firstname, Lastname, Street, Zip & City input fields. These vulnerabilities allow unauthenticated attackers to execute arbitrary code via a crafted excel file. Successful exploitation can lead to impacts such as client-sided command injection, code execution, or remote ex-filtration of contained confidential data. ### Patches Update to version 3.3.9 or apply this patch manually https://github.com/pimcore/customer-data-framework/commit/4e0105c3a78d20686a0c010faef27d2297b98803.patch ### Workarounds Apply patch https://github.com/pimcore/customer-data-framework/commit/4e0105c3a78d20686a0c010faef27d2297b98803.patch manually. ### References https://huntr.dev/bounties/821ff465-4754-42d1-9376-813c17f16a01/

### Impact When sampling randomness for a shared secret, the implementation of Kyber and FrodoKEM, did not check whether `crypto/rand.Read()` returns an error. In rare deployment cases (error thrown by the `Read()` function), this could lead to a predictable shared secret. The tkn20 and blindrsa components did not check whether enough randomness was returned from the user provided randomness source. Typically the user provides `crypto/rand.Reader`, which in the vast majority of cases will always return the right number random bytes. In the cases where it does not, or the user provides a source that does not, the blinding for blindrsa is weak and integrity of the plaintext is not ensured in tkn20. ### Patches The fix was introduced in CIRCL v. 1.3.3