ghsa

Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a `ThirdPartyBlock` request can be sent, providing only the necessary info to generate a third-party block and to sign it: - the public key of the previous block (used in the signature) - the public keys part of the token symbol table (for public key interning in datalog expressions) A third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair. Consider the following example (nominal case) - Authority `A` emits the following token: `check if thirdparty("b") trusting ${pubkeyB}` - The well-behaving holder then generates a third-party block request based on the token and sends it to third-party authority `B` - Third-party `B` generates the following third-party block `thirdparty("b"); check if thirdparty("c") trusting ${pubkeyC}` - The token holder now must obtain a third-party block from third ...

### Impact The issue is that the map of encoding/decoding languages are visible in code. ### Patches The problem was patched in 0.2.4. ### Workarounds The only known workaround is apply the fix to the code manually.

### Impact ZITADEL administrators can enable a setting called "Ignoring unknown usernames" which helps mitigate attacks that try to guess/enumerate usernames. If enabled, ZITADEL will show the password prompt even if the user doesn't exist and report "Username or Password invalid". Due to a implementation change to prevent deadlocks calling the database, the flag would not be correctly respected in all cases and an attacker would gain information if an account exist within ZITADEL, since the error message shows "object not found" instead of the generic error message. ### Patches 2.x versions are fixed on >= [2.58.1](https://github.com/zitadel/zitadel/releases/tag/v2.58.1) 2.57.x versions are fixed on >= [2.57.1](https://github.com/zitadel/zitadel/releases/tag/v2.57.1) 2.56.x versions are fixed on >= [2.56.2](https://github.com/zitadel/zitadel/releases/tag/v2.56.2) 2.55.x versions are fixed on >= [2.55.5](https://github.com/zitadel/zitadel/releases/tag/v2.55.5) 2.54.x versions are fi...

### Impact ZITADEL uses HTML for emails and renders certain information such as usernames dynamically. That information can be entered by users or administrators. Due to a missing output sanitization, these emails could include malicious code. This may potentially lead to a threat where an attacker, without privileges, could send out altered notifications that are part of the registration processes. An attacker could create a malicious link, where the injected code would be rendered as part of the email. During investigation of this issue a related issue was found and mitigated, where on the user's detail page the username was not sanitized and would also render HTML, giving an attacker the same vulnerability. While it was possible to inject HTML including javascript, the execution of such scripts would be prevented by most email clients and the Content Security Policy in Console UI. ### Patches 2.x versions are fixed on >= [2.58.1](https://github.com/zitadel/zitadel/releases/tag/...

### Impact An open redirect vulnerability exist in MobSF authentication view. PoC 1. Go to http://127.0.0.1:8000/login/?next=//afine.com in a web browser. 2. Enter credentials and press "Sign In". 3. You will be redirected to [afine.com](http://afine.com/) Users who are not using authentication are not impacted. ### Patches Update to MobSF v4.0.5 ### Workarounds Disable Authentication ### References Fix: https://github.com/MobSF/Mobile-Security-Framework-MobSF/commit/fdaad81314f393d324c1ede79627e9d47986c8c8 ### Reporter Marcin Węgłowski

### Impact It is possible for an attacker to craft malicious Urls that certain functions in IdentityServer will incorrectly treat as local and trusted. If such a Url is returned as a redirect, some browsers will follow it to a third-party, untrusted site. ### Affected Methods - In the `DefaultIdentityServerInteractionService`, the `GetAuthorizationContextAsync` method may return non-null and the `IsValidReturnUrl` method may return true for malicious Urls, indicating incorrectly that they can be safely redirected to. _UI code calling these two methods is the most commonly used code path that will expose the vulnerability. The default UI templates rely on this behavior in the Login, Challenge, and Consent pages. Customized user interface code might also rely on this behavior. The following uncommonly used APIs are also vulnerable:_ - The `ServerUrlExtensions.GetIdentityServerRelativeUrl`, `ReturnUrlParser.ParseAsync` and `OidcReturnUrlParser.ParseAsync` methods may incorrectly re...

### Impact Haystack clients that let their users create and run Pipelines from scratch are vulnerable to remote code executions. Certain Components in Haystack use Jinja2 templates, if anyone can create and render that template on the client machine they run any code. ### Patches The problem has been fixed with PRs deepset-ai/haystack#8095 and deepset-ai/haystack#8096. Both have been released with Haystack `2.3.1`. ### Workarounds Prevent users from running the affected Components, or only let users use preselected templates. ### References The list of impacted Components can be found in the release notes for `2.3.1`. https://github.com/deepset-ai/haystack/releases/tag/v2.3.1

### Impact Tokens with third-party blocks containing trusted annotations generated through a third party block request. Due to implementation issues in biscuit-java, third party block support in published versions is inoperating. Nevertheless, to synchronize with other implementations, we publish this advisory and the related fix. ### Description Third-party blocks can be generated without transferring the whole token to the third-party authority. Instead, a `ThirdPartyBlock` request can be sent, providing only the necessary info to generate a third-party block and to sign it: the public key of the previous block (used in the signature) the public keys part of the token symbol table (for public key interning in datalog expressions) A third-part block request forged by a malicious user can trick the third-party authority into generating datalog trusting the wrong keypair. Consider the following example (nominal case) * Authority A emits the following token: `check if thirdparty("b")...

It was discovered by Elastic engineering that when elasticsearch-certutil CLI tool is used with the csr option in order to create a new Certificate Signing Requests, the associated private key that is generated is stored on disk unencrypted even if the `--pass` parameter is passed in the command invocation.

### Impact The file upload widget is vulnerable to XSS payloads in filenames. Access permission to upload files is required. As such, in most cases only authenticated editors and administrators will have the required permission. It is not persistent, i.e. the payload is only executed during the upload. In effect, an attacker will have to trick an editor/administrator into uploading a strangely named file. The fix ensures XSS is escaped. ### Patches See "Patched versions". Commit: https://github.com/ezsystems/ezplatform-admin-ui/commit/7a9f991b200fa5a03d49cd07f50577c8bc90a30b ### Workarounds None. ### References - https://developers.ibexa.co/security-advisories/ibexa-sa-2024-004-dom-based-xss-in-file-upload - https://github.com/ezsystems/ezplatform-admin-ui/commit/7a9f991b200fa5a03d49cd07f50577c8bc90a30b - https://github.com/ibexa/admin-ui/security/advisories/GHSA-qm44-wjm2-pr59 ### Credit This vulnerability was discovered and reported to Ibexa by Alec Romano: https://github.com/4rd...