#git

## Summary When updating the root role, a TUF client must establish a trusted line of continuity to the latest set of keys. While sequentially downloading new versions of the root metadata file, tough will not check that the root object version it received was the next sequential version from the previously trusted root metadata. ## Impact The tough client will trust an outdated or rotated root role in the event that an actor with control of the storage medium of a trusted TUF repository inappropriately replaced the contents of one of the root metadata files with an adequately signed previous version. As a result, tough could trust content associated with a previous root role. 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. Cus...

### 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 recent analysis published by Infoblox reveals a sophisticated phishing operation, dubbed Morphing Meerkat, actively exploiting DNS vulnerabilities…

Let’s face it: Rolling out new software across an entire organization can feel like herding cats. Between data…

While inundated with ideas, you also need to consider how to present them effectively and structure the course…

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

The phishing campaign is highly sophisticated!