ghsa

### Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-95j3-435g-vjcp. This link is maintained to preserve external references. ### Original Description Cross Site Scripting vulnerability in Leantime v3.2.1 and before allows an authenticated attacker to execute arbitrary code and obtain sensitive information via the first name field in processMentions().

A vulnerability was found in the Infinispan component in Red Hat Data Grid. The REST compare API may have a buffer leak and an out of memory error can occur when sending continual requests with large POST data to the REST API.

janryWang products depath v1.0.6 and cool-path v1.1.2 were discovered to contain a prototype pollution via the set() method at setIn (lib/index.js:90). This vulnerability allows attackers to execute arbitrary code or cause a Denial of Service (DoS) via injecting arbitrary properties.

alizeait unflatto <= 1.0.2 was discovered to contain a prototype pollution via the method exports.unflatto at /dist/index.js. This vulnerability allows attackers to execute arbitrary code or cause a Denial of Service (DoS) via injecting arbitrary properties.

### Summary A publisher on a `publify` application is able to perform a cross-site scripting attack on an administrator using the redirect functionality. ### Details A publisher on a `publify` application is able to perform a cross-site scripting attack on an administrator using the redirect functionality. The exploitation of this XSS vulnerability requires the administrator to click a malicious link. We can create a redirect to a `javascript:alert()` URL. Whilst the redirect itself doesn't work, on the administrative panel, an a tag is created with the payload as the URI. Upon clicking this link, the XSS is triggered. An attack could attempt to hide their payload by using HTML, or other encodings, as to not make it obvious to an administrator that this is a malicious link. ### PoC A publisher can create a new redirect as shown below. The payload used is `javascript:alert()`. ![image](https://user-images.githubusercontent.com/44903767/295206083-3cf432c6-1f58-49a2-b09c-777e9707e0ff...

## Summary TUF repositories use the timestamp role to protect against rollback events by enabling an automated process to periodically sign the role's metadata. While tough will ensure that the version of snapshot metadata in new timestamp metadata files was always greater than or equal to the previously trusted version, it will only do so after persisting the timestamp metadata to its cache. ## Impact If the tough client successfully detects a rollback event in which timestamp metadata contains outdated snapshot metadata, the invalid timestamp metadata will still be persisted to cache as trusted. tough may then subsequently incorrectly identify valid timestamp metadata as being rolled back, preventing the client from consuming valid updates. Impacted versions: < v0.20.0 ## Patches A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the n...

## Summary When updating the snapshot role, TUF clients should ensure that any previously encountered targets or delegated targets metadata files continue to be present in new snapshot metadata files. Likewise, the new targets and delegated targets metadata versions must be greater than or equal to the previously encountered versions. While tough will perform this check for targets metadata files, it did not perform this check for delegated targets files. ## Impact tough could fail to detect cases where delegated targets metadata was removed or rolled back to a previous version. As a result, tough could trust and download outdated targets that it should reject. Impacted versions: < v0.20.0 ## Patches A fix for this issue is available in tough version 0.20.0 and later. Customers are advised to upgrade to version 0.20.0 or later and ensure any forked or derivative code is patched to incorporate the new fixes. ## Workarounds There is no recommended work around. Customers are advis...

### Impact A malicious user could feed a specially crafted archive to this library causing RCE, modification of files or other bad things in the context of whatever user is running this library as, through the program that imports it. The severity highly depends on the user's permissions and environment it is being ran in (e.g., non root, read only root container would likely have no impact vs running something as root on a production system). The severity is also dependent on **arbitrary archives** being passed or not. Based on the above, severity high was picked to be safe. ### Patches Patched with the help of snyk and gosec in v1.0.1 ### Workarounds The only workaround is to manually validate archives before submitting them to this library, however that is not recommended vs upgrading to unaffected versions. ### References https://security.snyk.io/research/zip-slip-vulnerability

An Improper Link Resolution Before File Access ("Link Following") and Improper Limitation of a Pathname to a Restricted Directory ("Path Traversal"). This vulnerability occurs when extracting a maliciously crafted tar file, which can result in unauthorized file writes or overwrites outside the intended extraction directory. The issue is associated with index.js in the tar-fs package. This issue affects tar-fs: from 0.0.0 before 1.16.4, from 2.0.0 before 2.1.2, from 3.0.0 before 3.0.7.

An integer overflow in Nethermind Juno before v0.12.5 within the Sierra bytecode decompression logic within the "cairo-lang-starknet-classes" library could allow remote attackers to trigger an infinite loop (and high CPU usage) by submitting a malicious Declare v2/v3 transaction. This results in a denial-of-service condition for affected Starknet full-node implementations.