ghsa

## 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 [security@tauri.app](mailto:security@tauri.app)

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.

Improper Authentication vulnerability in Apache Software Foundation Apache Accumulo. This issue affects Apache Accumulo: 2.1.0. Accumulo 2.1.0 contains a defect in the user authentication process that may succeed when invalid credentials are provided. Users are advised to upgrade to 2.1.1.

Versions of the package semver before 7.5.2 are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.

### Impact It's possible to execute any wiki content with the right of the TipsPanel author by creating a tip UI extension. To reproduce: * Add an object of type UIExtensionClass * Set "Extension Point ID" to org.xwiki.platform.help.tipsPanel * Set "Extension ID" to org.xwiki.platform.user.test (needs to be unique but otherwise doesn't matter) * Set "Extension Parameters" to ``` tip={{async async="true" cached="false" context="doc.reference"}}{{groovy}}println("Hello " + "from groovy!"){{/groovy}}{{/async}} ``` * Set "Extension Scope" to "Current User". * Click "Save & View" * Open the "Help.TipsPanel" document at <xwiki-host>/xwiki/bin/view/Help/TipsPanel where <xwiki-host> is the URL of your XWiki installation and press refresh repeatedly. The groovy macro is executed, after the fix you get an error instead. ### Patches This has been patched in XWiki 15.1-rc-1 and 14.10.5. ### Workarounds There are no known workarounds for it. ### References * https://jira.xwiki....

### Impact If you used the [apiPrefilter](https://remult.dev/docs/ref_entity.html#apiprefilter) option of the `@Entity` decorator, by setting it to a function that returns a filter that prevents unauthorized access to data, an attacker who knows the `id` of an entity instance she is not authorized to access, can gain read, update and delete access to it. ### Patches The issue is fixed in version 0.20.6 ### Workarounds Set the `apiPrefilter` option to a filter object instead of a function. ### References If you're using a minor version < 0.20 and require a patch, please create an issue.