ghsa

### Summary Unauthenticated user can access credentials of last authenticated user via OpenID or OAuth2 where the authentication URL did not include `redirect` query string. For example: - Project is configured with OpenID or OAuth2 - Project is configured with cache enabled - User tries to login via SSO link, but without `redirect` query string - After successful login, credentials are cached - If an unauthenticated user tries to login via SSO link, it will return the credentials of the other last user The SSO link is something like `https://directus.example.com/auth/login/openid/callback`, where `openid` is the name of the OpenID provider configured in Directus ### Details This happens because on that endpoint for both OpenId and Oauth2 Directus is using the `respond` middleware, which by default will try to cache GET requests that met some conditions. Although, those conditions do not include this scenario, when an unauthenticated request returns user credentials. For OpenID, thi...

### Impact Users hosting D-Tale publicly can be vulnerable to remote code execution allowing attackers to run malicious code on the server. ### Patches Users should upgrade to version 3.14.1 where the "Custom Filter" input is turned off by default. You can find out more information on how to turn it back on [here](https://github.com/man-group/dtale#custom-filter) ### Workarounds The only workaround for versions earlier than 3.14.1 is to only host D-Tale to trusted users. ### References See "Custom Filter" [documentation](https://github.com/man-group/dtale#custom-filter)

### Impact passing untrusted user input - even after sanitizing it - to `SendStream.redirect()` may execute untrusted code ### Patches this issue is patched in send 0.19.0 ### Workarounds users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist ### Details successful exploitation of this vector requires the following: 1. The attacker MUST control the input to response.redirect() 1. express MUST NOT redirect before the template appears 1. the browser MUST NOT complete redirection before: 1. the user MUST click on the link in the template

### Impact passing untrusted user input - even after sanitizing it - to `redirect()` may execute untrusted code ### Patches this issue is patched in serve-static 1.16.0 ### Workarounds users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist ### Details successful exploitation of this vector requires the following: 1. The attacker MUST control the input to response.redirect() 1. express MUST NOT redirect before the template appears 1. the browser MUST NOT complete redirection before: 1. the user MUST click on the link in the template

Ruby-SAML in <= 12.2 and 1.13.0 <= 1.16.0 does not properly verify the signature of the SAML Response. An unauthenticated attacker with access to any signed saml document (by the IdP) can thus forge a SAML Response/Assertion with arbitrary contents. This would allow the attacker to log in as arbitrary user within the vulnerable system. This vulnerability was reported by ahacker1 of SecureSAML ([email protected])

### Impact In express <4.20.0, passing untrusted user input - even after sanitizing it - to `response.redirect()` may execute untrusted code ### Patches this issue is patched in express 4.20.0 ### Workarounds users are encouraged to upgrade to the patched version of express, but otherwise can workaround this issue by making sure any untrusted inputs are safe, ideally by validating them against an explicit allowlist ### Details successful exploitation of this vector requires the following: 1. The attacker MUST control the input to response.redirect() 1. express MUST NOT redirect before the template appears 1. the browser MUST NOT complete redirection before: 1. the user MUST click on the link in the template

A denial of service vulnerability was found in keycloak where the amount of attributes per object is not limited,an attacker by sending repeated HTTP requests could cause a resource exhaustion when the application send back rows with long attribute values.

### Impact The REST API exposes the history of any page in XWiki of which the attacker knows the name. The exposed information includes for each modification of the page the time of the modification, the version number, the author of the modification (both username and displayed name) and the version comment. This information is exposed regardless of the rights setup, and even when the wiki is configured to be fully private. On a private wiki, this can be tested by accessing `/xwiki/rest/wikis/xwiki/spaces/Main/pages/WebHome/history`, if this shows the history of the main page then the installation is vulnerable. ### Patches This has been patched in XWiki 15.10.9 and XWiki 16.3.0RC1. ### Workarounds There aren't any known workarounds apart from upgrading to a fixed version. ### References * https://jira.xwiki.org/browse/XWIKI-22052 * https://github.com/xwiki/xwiki-platform/commit/9cbca9808300797c67779bb9a665d85cf9e3d4b8

### Summary Unescaped entity property enables Javascript injection. ### Details I think this is possible because %source_label% in twig macro is not escaped. Therefore script tags can be inserted and are executed. ### PoC - clone example project https://github.com/DamienHarper/auditor-bundle-demo - create author with FullName <script>alert()</script> - delete author - view audit of authors - alert is displayed ### Impact persistent XSS. JS can be injected and executed.

### Impact body-parser <1.20.3 is vulnerable to denial of service when url encoding is enabled. A malicious actor using a specially crafted payload could flood the server with a large number of requests, resulting in denial of service. ### Patches this issue is patched in 1.20.3 ### References