ghsa

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.

### Impact The 1.4.0 release includes a regression on the filesystem scope check for dotfiles on Linux and macOS. Previously dotfiles (eg. `$HOME/.ssh/`) were not implicitly allowed by the glob wildcard scopes (eg. `$HOME/*`), but a regression was introduced when a configuration option for this behavior was implemented and dotfiles were implicitly allowed. Only Tauri applications using wildcard scopes in the `fs` endpoint are affected. Only macOS and Linux systems are affected. ### Patches The regression has been patched on `v1.4.1`. ### Workarounds There are no known workarounds at this time, users should update to `v1.4.1` immediately. ### References See the [original advisory](https://github.com/tauri-apps/tauri/security/advisories/GHSA-6mv3-wm7j-h4w5) for more information. ### For more Information If you have any questions or comments about this advisory: Open an issue in tauri Email us at [[email protected]](mailto:[email protected])

Broadleaf 5.x and 6.x (including 5.2.25-GA and 6.2.6-GA) was discovered to contain a cross-site scripting (XSS) vulnerability via a customer signup with a crafted email address. This is fixed in 6.2.7-GA.

A regression in the fix for bug 66512 in Apache Tomcat 11.0.0-M5, 10.1.8, 9.0.74 and 8.5.88 meant that, if a response did not include any HTTP headers no AJP SEND_HEADERS messare woudl be sent for the response which in turn meant that at least one AJP proxy (mod_proxy_ajp) would use the response headers from the previous request leading to an information leak.