ghsa

All versions of the package word-wrap are vulnerable to Regular Expression Denial of Service (ReDoS) due to the usage of an insecure regular expression within the result variable.

### Summary The current cryptography implementation in Sliver up to version 1.5.39 allows a MitM with access to the corresponding implant binary to execute arbitrary codes on implanted devices via intercepted and crafted responses. (Reserved CVE ID: CVE-2023-34758) ### Details Please see [the PoC repo](https://github.com/tangent65536/Slivjacker). ### PoC Please also see [the PoC repo](https://github.com/tangent65536/Slivjacker). To setup a simple PoC environment, 1. Generate an implant with its C2 set to the PoC server's address and copy the embedded private implant key and public server key into the config json. 2. Run the implant on a separate VM and a `notepad.exe` window should pop up on the implanted VM. ### Impact A successful attack grants the attacker permission to execute arbitrary code on the implanted device. ### References https://github.com/BishopFox/sliver/blob/master/implant/sliver/cryptography/implant.go https://github.com/BishopFox/sliver/blob/master/...

When this function was passed an empty string, `openssl` would attempt to call `strlen` on it, reading arbitrary memory until it reached a NUL byte.

On Windows, it is possible to open a `livebook://` link from a browser which opens Livebook Desktop and triggers arbitrary code execution on victim's machine. Any user using Livebook Desktop on Windows is potentially vulnerable to arbitrary code execution when they expect Livebook to be opened from browser.

memoffset allows attempt of reading data from address `0` with arbitrary type. This behavior is an undefined behavior because address `0` to `std::mem::size_of<T>` may not have valid bit-pattern with `T`. Old implementation dereferences uninitialized memory obtained from `std::mem::align_of`. Older implementation prior to it allows using uninitialized data obtained from `std::mem::uninitialized` with arbitrary type then compute offset by taking the address of field-projection. This may also result in an undefined behavior for "father" that includes (directly or transitively) type that [does not allow to be uninitialized](https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html). This flaw was corrected by using `std::ptr::addr_of` in <https://github.com/Gilnaa/memoffset/pull/50>.

## Information Please note that this is not a new disclosure, and is previously reported in our [SECURITY-NOTICE.md](https://github.com/auth0/passport-wsfed-saml2/commit/520b9fc0bb4249ce83bec47e30153419f086ab70 ) which we removed in favor of github advisory. # Overview A vulnerability was found in the validation of a SAML signature. The validation doesn't ensure that the "Signature" tag is at the proper location inside an "Assertion" tag. This leads to a signature relocation attack where the attacker can corrupt one field of data while maintaining the signature valid. This could allow an authenticated attacker to "remove" one group from the assertion or corrupt another field of an assertion. # Am I affected? You are affected if you are using the passport-wsfed-saml2 library to version < 3.0.10 # How do I fix it? You may fix this issue by upgrading passport-wsfed-saml2 library to version 3.0.10 or above. # Will the fix impact my users? This fix patches the library that your ap...

The Backstage scaffolder-backend plugin uses a templating library that requires a sandbox, as it by design allows for code injection. The library used for this sandbox so far has been `vm2`, but in light of several past vulnerabilities and existing vulnerabilities that may not have a fix, the plugin has switched to using a different sandbox library. ### Impact A malicious actor with write access to a registered scaffolder template could manipulate the template in a way that allows for remote code execution on the scaffolder-backend instance. This was only exploitable in the template YAML definition itself and not by user input data. ### Patches This is vulnerability is fixed in version 1.15.0 of `@backstage/plugin-scaffolder-backend`. ### Workarounds Note that the [Backstage Threat Model](https://backstage.io/docs/overview/threat-model) states that scaffolder templates are considered to be a sensitive area that with the recommendation that you control access and perform manual r...

## Information Please note that this is not a new disclosure, and is previously reported in our [SECURITY-NOTICE.md](https://github.com/auth0/passport-wsfed-saml2/commit/520b9fc0bb4249ce83bec47e30153419f086ab70 ) which we removed in favor of github advisory. # Overview This vulnerability allows an attacker to impersonate another user and potentially elevate their privileges if the SAML identity provider: - signs SAML response and signs assertion - does not sign SAML response and signs assertion # Am I affected? You may be affected if you use SAML2 protocol with passport-wsfed-saml2 versions below 3.0.5 and your SAML identity Provider: 1. signs SAML response and signs assertion; or 2. does not sign SAML response and signs assertion # How do I fix it? You may fix this vulnerability by upgrading your library to version 3.0.5 or above. # Will the fix impact my users? This fix patches the library that your application runs, but will not impact your users, their current state, ...

### Summary An unsanitized attachment filename allows any unauthenticated user to leverage a directory traversal vulnerability which results in a remote code execution vulnerability. ### Details An attacker can send an email with a malicious attachment to the inbox, which gets crawled with webklex/php-imap or webklex/laravel-imap. Prerequisite for the vulnerability is that the script stores the attachments without providing a `$filename`, or providing an unsanitized `$filename`, in `src/Attachment::save(string $path, string $filename = null)` (https://github.com/Webklex/php-imap/blob/5.2.0/src/Attachment.php#L251-L255). In this case, where no `$filename` gets passed into the `Attachment::save()` method, the package would use a series of unsanitized and insecure input values from the mail as fallback (https://github.com/Webklex/php-imap/blob/5.2.0/src/Attachment.php#L252). Even if a developer passes a `$filename` into the `Attachment::save()` method, e.g. by passing the name or filenam...

The urlnorm crate through 0.1.4 for Rust allows Regular Expression Denial of Service (ReDos) via a crafted URL to lib.rs.