ghsa

### Impact Prior to version v1.20230419.0, the FormData API implementation was subject to an integer overflow. If a FormData instance contained more than 2^31 elements, the `forEach()` method could end up reading from the wrong location in memory while iterating over elements. This would most likely lead to a segmentation fault, but could theoretically allow arbitrary undefined behavior. In order for the bug to be exploitable, the process would need to be able to allocate 160GB of RAM. Due to this, the bug was never exploitable on the Cloudflare Workers platform, but could theoretically be exploitable on deployments of workerd running on machines with a huge amount of memory. Moreover, in order to be remotely exploited, an attacker would have to upload a single form-encoded HTTP request of at least tens of gigabytes in size. The application code would then have to use `request.formData()` to parse the request and `formData.forEach()` to iterate over this data. Due to these limitations...

An issue found in CraftCMS v.3.8.1 allows a remote attacker to execute arbitrary code via a crafted script to the Section parameter.

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

LavaLite CMS v 9.0.0 was discovered to be vulnerable to web cache poisoning.

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

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