ghsa

Insufficient capability checks made it possible to disable badges a user does not have permission to access.

The drag-and-drop onto image (ddimageortext) question type required additional sanitizing to prevent a stored XSS risk.

### Summary A bypass was found for the security feature **trustedOrigins**. This works for wild card or absolute URLs trustedOrigins configs and opens the victims website to a **Open Redirect** vulnerability, where it can be used to steal the **reset password token** of a victims account by changing the "callbackURL" parameter value to a website owned by the attacker. ### Details #### Absolute URLs The issue here appears in the **middleware**, [specifically](https://github.com/better-auth/better-auth/blob/ddebd0358d74376ea64541512d0167dd4377f182/packages/better-auth/src/api/middlewares/origin-check.ts#L53). This protection is not sufficiente and it allows attackers to get a open redirect, by using the payload `/\/example.com`. We can check this is a valid URL ( or it will be a valid URL because the URL parser fix it for us ), by checking the image bellow:  ```typescript // trustedOrigins = [ ...

The http parser in Phusion Passenger 6.0.21 through 6.0.25 before 6.0.26 allows a denial of service during parsing of a request with an invalid HTTP method.

### Summary The application is vulnerable to an open redirect due to improper validation of the callbackURL parameter in the email verification endpoint and any other endpoint that accepts callback url. While the server blocks fully qualified URLs (e.g., https://evil.com), it incorrectly allows scheme-less URLs (e.g., //malicious-site.com). This results in the browser interpreting the URL as https://malicious-site.com, leading to unintended redirection. bypass for : https://github.com/better-auth/better-auth/security/advisories/GHSA-8jhw-6pjj-8723 ### Affected Versions All versions prior to 1.1.19 ### Details The application’s email verification endpoint (/auth/verify-email) accepts a callbackURL parameter intended to redirect users after successful email verification. While the server correctly blocks fully qualified external URLs (e.g., https://evil.com), it improperly allows scheme-less URLs (e.g., //malicious-site.com). This issue occurs because browsers interpret //malicious-si...

OpenH264 recently reported a [heap overflow](https://github.com/cisco/openh264/security/advisories/GHSA-m99q-5j7x-7m9x) that was fixed in upstream [63db555](https://github.com/cisco/openh264/commit/63db555e30986e3a5f07871368dc90ae78c27449) and [integrated into](https://github.com/ralfbiedert/openh264-rs/commit/3a822fff0b4c9a984622ca2b179fe8898ac54b14) our 0.6.6 release. For users relying on Cisco's pre-compiled DLL, we also published 0.8.0, which is compatible with their latest fixed DLL version 2.6.0. In other words: - if you rely on our `source` feature only, >=0.6.6 should be safe, - if you rely on `libloading`, you must upgrade to 0.8.0 _and_ use their latest DLL >=2.6.0. Users handling untrusted video files should update immediately.

Mattermost versions 10.4.x <= 10.4.1, 9.11.x <= 9.11.7, 10.3.x <= 10.3.2, 10.2.x <= 10.2.2 fail to properly validate board blocks when importing boards which allows an attacker could read any arbitrary file on the system via importing and exporting a specially crafted import archive in Boards.

Mattermost versions 10.1.x <= 10.1.3, 10.4.x <= 10.4.1, 9.11.x <= 9.11.7, 10.3.x <= 10.3.2, 10.2.x <= 10.2.2 fail to restrict channel export of archived channels when the "Allow users to view archived channels" is disabled which allows a user to export channel contents when they shouldn't have access to it

Mattermost versions 10.4.x <= 10.4.1, 9.11.x <= 9.11.7, 10.3.x <= 10.3.2, 10.2.x <= 10.2.2 fail to properly validate input when patching and duplicating a board, which allows a user to read any arbitrary file on the system via duplicating a specially crafted block in Boards.

Mattermost versions 9.11.x <= 9.11.6, 10.4.x <= 10.4.1 fail to invalidate all active sessions when converting a user to a bot, with allows the converted user to escalate their privileges depending on the permissions granted to the bot.