ghsa

### 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 [[email protected]](mailto:[email protected])

A vulnerability has been detected in HyperLedger Fabric v1.4.0, v2.0.0, v2.1.0. This bug can be leveraged by constructing a message whose payload is nil and sending this message with the method 'forwardToLeader'. This bug has been admitted and fixed by the developers of Fabric. If leveraged, any leader node will crash.

A flaw was found in the Ansible Engine 2.9.18, where sensitive info is not masked by default and is not protected by the no_log feature when using the sub-option feature of the basic.py module. This flaw allows an attacker to obtain sensitive information. The highest threat from this vulnerability is to confidentiality.

jsonparser before 1.1.1 allows attackers to cause a denial of service via a GET call.

In JFinal cos before 2019-08-13, as used in JFinal 4.4, there is a vulnerability that can bypass the isSafeFile() function: one can upload any type of file. For example, a .jsp file may be stored and almost immediately deleted, but this deletion step does not occur for certain exceptions.

### Impact Previous version of Guzzle contain a vulnerability with the cookie middleware. The vulnerability is that it is not checked if the cookie domain equals the domain of the server which sets the cookie via the `Set-Cookie` header, allowing a malicious server to set cookies for unrelated domains. For example an attacker at `www.example.com` might set a session cookie for `api.example.net`, logging the Guzzle client into their account and retrieving private API requests from the security log of their account. Note that our cookie middleware is disabled by default, so most library consumers will not be affected by this issue. Only those who manually add the cookie middleware to the handler stack or construct the client with `['cookies' => true]` are affected. Moreover, those who do not use the same Guzzle client to call multiple domains and have disabled redirect forwarding are not affected by this vulnerability. ### Patches Affected Guzzle 7 users should upgrade to Guzzle 7.5.0...

Path Traversal in GitHub repository filegator/filegator prior to 7.8.0 for non-admin users. Files created with `..\` as part of their name will be interpreted as a path. Users are thus able to add filesystem entries outside the scope of their user to their dashboard and subsequently are able to modify those files.