ghsa

### Impact Mautic allows you to track open rates by using tracking pixels. The tracking information is stored together with extra metadata of the tracking request. The output isn't sufficiently filtered when showing the metadata of the tracking information, which may lead to a vulnerable situation. ### Patches Please upgrade to 4.3.0 ### Workarounds None. ### References * Internally tracked under MST-38 ### For more information If you have any questions or comments about this advisory: * Email us at [security@mautic.org](mailto:security@mautic.org)

### Impact This weakness allows the force decryption of locked text by hackers. The issue is NOT critical for non-secure applications, however may be critical in a situation where the highest levels of security are required. This issue ONLY affects v1.6 and does not affect anything pre-1.6. Upgrading to 1.7 is advised. ### Patches The vulnerability has been patched in release 1.7. ### Workarounds Currently there is no way to fix the issue without upgrading. ### References [CWE-327](https://cwe.mitre.org/data/definitions/327.html) [CWE-328](https://cwe.mitre.org/data/definitions/328.html) ### For more information If you have any questions or comments about this advisory: * Open an issue in [our issue tracker](http://github.com/JavaEZLib/JavaEZ/issues) * Email us at [javaezlib@gmail.com](mailto:javaezlib@gmail.com)

### Impact PocketMine-MP caps maximum chat message length at 512 Unicode characters, or about 2048 bytes. No more than 2 chat messages may be sent per tick. However, due to legacy reasons, incoming chat message blobs are split by `\n`, and each part is treated as a separate message, the length of each part is individually checked. The length of the whole message is not checked. This leads to an exploitable performance issue, in which a malicious client may send a chat packet of several megabytes containing nothing but `\n` newline characters. The server will parse this into a very large array and spend a long time (several milliseconds) iterating over it for no reason. Furthermore, due to the lack of sufficient rate limit checks before parsing messages, malicious clients may bombard the server with many thousands of these malicious messages, causing lockups for a significant amount of time (seconds or minutes). ### Patches This bug was addressed in https://github.com/pmmp/PocketMine...

Prior to Opencast 10.14 and 11.7, users could pass along URLs for files belonging to organizations other than the user's own, which Opencast would then import into the current organization, bypassing organizational barriers. ### Impact The vulnerability allows attackers to bypass organizational barriers. Attackers must have full access to Opencast's ingest REST interface, and also know internal links to resources in another organization of the same Opencast cluster. If you do not run a multi-tenant cluster, you are not affected by this issue. ### Patches This issue is fixed in Opencast 10.14 and 11.7. ### References - [Patch fixing the issue](https://github.com/opencast/opencast/commit/8d5ec1614eed109b812bc27b0c6d3214e456d4e7) ### For more information If you have any questions or comments about this advisory: * Open an issue in [our issue tracker](https://github.com/opencast/opencast/issues) * Email us at [security@opencast.org](mailto:security@opencast.org)

### Impact Template authors could inject php code by choosing a malicous {block} name or {include} file name. Sites that cannot fully trust template authors should update asap. ### Patches Please upgrade to the most recent version of Smarty v3 or v4. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ ### References _Are there any links users can visit to find out more?_ ### For more information If you have any questions or comments about this advisory: * Open an issue in [the Smarty repo](https://github.com/smarty-php/smarty)

The notification module displaying flash messages unscapes HTML coming from the server, resulting in XSS vulnerabilities with various names and labels of entities (eg. workspace title or media title). This however means you must be a logged in user with respective rights in the first place to leverage the attack vector.

### Impact Unprivileged software in VMware VMs, including software running in unprivileged containers, can retrieve an Ignition config stored in a hypervisor guestinfo variable or OVF environment. If the Ignition config contains secrets, this can result in the compromise of sensitive information. ### Patches Ignition 2.14.0 and later [adds](https://github.com/coreos/ignition/pull/1350) a new systemd service, `ignition-delete-config.service`, that deletes the Ignition config from supported hypervisors (currently VMware and VirtualBox) during the first boot. This ensures that unprivileged software cannot retrieve the Ignition config from the hypervisor. If you have external tooling that requires the Ignition config to remain accessible in VM metadata after provisioning, and your Ignition config does not include sensitive information, you can prevent Ignition 2.14.0 and later from deleting the config by masking `ignition-delete-config.service`. For example: ```json { "ignition": {...

### Impact CaSS Library, (npm:cassproject) has a missing cryptographic step when storing cryptographic keys that can allow a server administrator access to an account’s cryptographic keys. This affects CaSS servers using standalone username/password authentication, which uses a method that expects e2e cryptographic security of authorization credentials. ### Patches The issue has been patched in 1.5.8, however, the vulnerable accounts are only resecured when the user next logs in using standalone authentication, as the data required to resecure the account is not available to the server. ### Workarounds The issue may be mitigated by using SSO or client side certificates to log in. Please note that SSO and client side certificate authentication does not have this expectation of no-knowledge credential access, and cryptographic keys are available to the server administrator. ### References There are no references at this time. ### For more information If you have any questions or comm...

### Impact The implementation of depthwise ops in TensorFlow is vulnerable to a denial of service via `CHECK`-failure (assertion failure) caused by overflowing the number of elements in a tensor: ```python import tensorflow as tf input = tf.constant(1, shape=[1, 4, 4, 3], dtype=tf.float32) filter_sizes = tf.constant(1879048192, shape=[13], dtype=tf.int32) out_backprop = tf.constant(1, shape=[1, 4, 4, 3], dtype=tf.float32) tf.raw_ops.DepthwiseConv2dNativeBackpropFilter( input=input, filter_sizes=filter_sizes, out_backprop=out_backprop, strides=[1, 1, 1, 1], padding="SAME") ``` This is another instance of [TFSA-2021-198](https://github.com/tensorflow/tensorflow/blob/master/tensorflow/security/advisory/tfsa-2021-198.md) (CVE-2021-41197). ### Patches We have patched the issue in GitHub commit [3796cc4fcd93ae55812a457abc96dcd55fbb854b](https://github.com/tensorflow/tensorflow/commit/3796cc4fcd93ae55812a457abc96dcd55fbb854b). The fix will be included in TensorFlow 2.9.0. We will...

### Impact A DTLS Client could provide a Certificate that it doesn't posses the private key for and Pion DTLS wouldn't reject it. This issue affects users that are using Client certificates only. The connection itself is still secure. The Certificate provided by clients can't be trusted when using a Pion DTLS server prior to v2.1.5 ### Patches Upgrade to Pion DTLS v2.1.5 ### Workarounds No workarounds available, upgrade to Pion DTLS v2.1.5 ### References Thank you to [Juho Nurminen](https://github.com/jupenur) and the Mattermost team for discovering and reporting this. ### For more information If you have any questions or comments about this advisory: * Open an issue in [Pion DTLS](http://github.com/pion/dtls) * Email us at [team@pion.ly](mailto:team@pion.ly)