Latest News

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.

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…

A vulnerability has been found that can be exploited through every browser as long as its running on a Windows system

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