#git

Mattermost versions 10.5.x <= 10.5.5, 9.11.x <= 9.11.15, 10.8.x <= 10.8.0, 10.7.x <= 10.7.2, 10.6.x <= 10.6.5 fail to properly enforce channel member management permissions when adding participants to playbook runs. This allows authenticated users with member-level permissions to bypass system admin restrictions and add or remove users to/from private channels via the playbook run participants feature, even when the 'Manage Members' permission has been explicitly removed. This can lead to unauthorized access to sensitive channel content and allow guest users to gain channel management privileges.

Mattermost versions 10.5.x <= 10.5.5, 9.11.x <= 9.11.15, 10.8.x <= 10.8.0, 10.7.x <= 10.7.2, 10.6.x <= 10.6.5 fail to properly validate channel membership when retrieving playbook run metadata, allowing authenticated users who are playbook members but not channel members to access sensitive information about linked private channels including channel name, display name, and participant count through the run metadata API endpoint.

### Summary Sending transactions with fees different than native Babylon genesis denom (`ubbn`) leads to chain halt. ### Impact Denial of Service - Due to panic in the `x/distribution` module `BeginBlocker` triggered by a error when sending fees from `feeCollector` to `x/distribution` module - https://github.com/cosmos/cosmos-sdk/blob/main/x/distribution/keeper/allocation.go#L28 Babylon Genesis will halt

### Impact _What kind of vulnerability is it? Who is impacted?_ The configAPI is an internal service and hence should never be exposed to the internet. With that said, this is a serious vulnerability that has a large internal surface attack area that exposes all sorts of information from the IDP including clients, users, scripts ..etc. This affects all users of Janssen <1.8.0 and Gluu Flex <5.8.0 ### Patches _Has the problem been patched? What versions should users upgrade to?_ All users are advised to upgrade immediately to [1.8.0](https://github.com/JanssenProject/jans/releases/tag/v1.8.0) for Janssen users and [5.8.0](https://github.com/GluuFederation/flex/releases/tag/v5.8.0) For Flex users. ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ The user can potentially fork and build the config api and patch it in their system following the commit here https://github.com/JanssenProject/jans/commit/92eea4d4637f1cae16ad2f07b2c16378ff3f...

## Summary ## All user accounts authenticate towards a *File Browser* instance with a password. A missing password policy and brute-force protection makes it impossible for administrators to properly secure the authentication process. ## Impact ## Attackers can mount a brute-force attack against the passwords of all accounts of an instance. Since the application is lacking the ability to prevent users from choosing a weak password, the attack is likely to succeed. ## Vulnerability Description ## The application implement a classical authentication scheme using a username and password combination. While employed by many systems, this scheme is quite error-prone and a common cause for vulnerabilities. File Browser's implementation has multiple weak points: 1. Since the application is missing the capability for administrators to define a password policy, users are at liberty to set trivial and well-known passwords such as `secret` or even ones with only single digit like `1`. 2. New...

## Summary ## Files managed by the *File Browser* can be shared with a link to external persons. While the application allows protecting those links with a password, the implementation is error-prone, making an incidental unprotected sharing of a file possible. ## Impact ## File owners might rest in the assumption that their shared files are only accessible to persons knowing the defined password, giving them a false sense of security. Meanwhile, attackers gaining access to the unprotected link can use this information alone to download the possibly sensitive file. ## Vulnerability Description ## When sharing a file, the user is presented with a dialog asking for an optional password to protect the file share. The assumption of the user at this point would be, that the shared file won't be accessible without knowledge of the password. After clicking on `SHARE` the following dialog opens allowing the file's owner to copy the share-link: ![image](https://github.com/user-attachments...

## Summary ## The *Command Execution* feature of Filebrowser only allows the execution of shell command which have been predefined on a user-specific allowlist. The implementation of this allowlist is erroneous, allowing a user to execute additional commands not permitted. ## Impact ## A user can execute more shell commands than they are authorized for. The concrete impact of this vulnerability depends on the commands configured, and the binaries installed on the server or in the container image. Due to the missing separation of *scopes* on the OS-level, this could give an attacker access to all files managed the application, including the File Browser database. ## Vulnerability Description ## For a user to make use of the command execution feature, two things need to happen in advance: 1. An administrator needs to grant that account the `Execute commands` permission 2. The command to be executed needs to be listed in the `Commands` input field (also done by an administrator) If...

## Summary ## In the web application, all users have a *scope* assigned, and they only have access to the files within that *scope*. The *Command Execution* feature of Filebrowser allows the execution of shell commands which are not restricted to the scope, potentially giving an attacker read and write access to all files managed by the server. ## Impact ## Shell commands are executed with the *uid* of the server process without any further restrictions. This means, that they will have access to at least * all files managed by the application from all *scopes*, even those the user does not have access to in the GUI. * the Filebrowser database file containing the password hashes of all accounts. The concrete impact depends on the commands being granted to the attacker, but due to other vulnerabilities identified ("Bypass Command Execution Allowlist", "Shell Commands Can Spawn Other Commands", "Insecure File Permissions") it is likely, that full read- and write-access will exist. R...

## Summary URLs that are accessed by a user are commonly logged in many locations, both server- and client-side. It is thus good practice to never transmit any secret information as part of a URL. The *Filebrowser* violates this practice, since access tokens are used as GET parameters. ## Impact The *JSON Web Token (JWT)* which is used as a session identifier will get leaked to anyone having access to the URLs accessed by the user. This will give the attacker full access to the user's account and, in consequence, to all sensitive files the user has access to. ## Description Sensitive information in URLs is logged by several components (see the following examples), even if access is protected by TLS. * The browser history * The access logs on the affected web server * Proxy servers or reverse proxy servers * Third-party servers via the HTTP referrer header In case attackers can access certain logs, they could read the included sensitive data. ## Proof of Concept ## When a file ...

### Summary A malicious JSON-stringifyable message can be made passing on `verify()`, when global Buffer is [`buffer` package](https://www.npmjs.com/package/buffer) ### Details This affects only environments where `require('buffer')` is <https://npmjs.com/buffer> E.g.: browser bundles, React Native apps, etc. `Buffer.isBuffer` check can be bypassed, resulting in strange objects being accepted as `message`, and those messages could trick `verify()` into returning false-positive `true` values v2.x is unaffected as it verifies input to be an actual `Uint8Array` instance Such a message can be constructed for any already known message/signature pair There are some restrictions though (also depending on the known message/signature), but not very limiting, see PoC for example https://github.com/bitcoinjs/tiny-secp256k1/pull/140 is a subtle fix for this ### PoC This code deliberately doesn't provide `reencode` for now, could be updated later ```js import { randomBytes } from 'crypto'...