#git

Mattermost versions 10.11.x <= 10.11.3, 10.5.x <= 10.5.11, 10.12.x <= 10.12.0 fail to sanitize user data which allows system administrators to access password hashes and MFA secrets via the POST /api/v4/users/{user_id}/email/verify/member endpoint

Apple's Digital ID makes travel smoother and saves you from digging for documents, but it comes with privacy and security trade-offs. We break down the pros and cons.

Mattermost versions < 11 fail to properly restrict access to archived channel search API which allows guest users to discover archived public channels via the `/api/v4/teams/{team_id}/channels/search_archived` endpoint

Mattermost versions < 11 fail to enforce multi-factor authentication on WebSocket connections which allows unauthenticated users to access sensitive information via WebSocket events.

Mattermost versions 10.11.x <= 10.11.3, 10.5.x <= 10.5.11, 10.12.x <= 10.12.0 fail to validate the relationship between the post being updated and the MSTeams plugin OAuth flow which allows an attacker to edit arbitrary posts via a crafted MSTeams plugin OAuth redirect URL.

Mattermost versions < 11.0 fail to properly enforce the "Allow users to view archived channels" setting which allows regular users to access archived channel content and files via the "Open in Channel" functionality from followed threads

**Impact** This affects any LXD user in an environment where an unprivileged user may have root access to a container with an attached custom storage volume that has the `security.shifted` property set to `true` as well as access to the host as an unprivileged user. The most common case for this would be systems using `lxd-user` with the less privileged lxd group to provide unprivileged users with an isolated restricted access to LXD. Such users may be able to create a custom storage volume with the necessary property (depending on kernel and filesystem support) and can then write a setuid binary from within the container which can be executed as an unprivileged user on the host to gain root privileges. **Patches** Patches for this issue are available: - LXD 6 series: https://github.com/canonical/lxd/pull/16904 - LXD 5.21 LTS series: https://github.com/canonical/lxd/pull/16922 - LXD 5.0 LTS series: https://github.com/canonical/lxd/pull/16923 - LXD 4.0 LTS series: https://github.c...

### Impact The prosemirror_to_html gem is vulnerable to Cross-Site Scripting (XSS) attacks through malicious HTML attribute values. While tag content is properly escaped, attribute values are not, allowing attackers to inject arbitrary JavaScript code. **Who is impacted:** - Any application using prosemirror_to_html to convert ProseMirror documents to HTML - Applications that process user-generated ProseMirror content are at highest risk - End users viewing the rendered HTML output could have malicious JavaScript executed in their browsers **Attack vectors include:** - `href` attributes with `javascript:` protocol: `<a href="javascript:alert(document.cookie)">` - Event handlers: `<div onclick="maliciousCode()">` - `onerror` attributes on images: `<img src=x onerror="alert('XSS')">` - Other HTML attributes that can execute JavaScript ### Patches A fix is currently in development. Users should upgrade to version **0.2.1** or later once released. The patch escapes all HTML attrib...

### Impact Users who: 1. Use the exclusion operator somewhere in their authorization schema. 1. Have configured their SpiceDB server such that `--write-relationships-max-updates-per-call` is bigger than 6500. 1. Issue calls to WriteRelationships with a large enough number of updates that cause the payload to be bigger than what their datastore allows. Users will: 1. Receive a successful response from their `WriteRelationships` call, when in reality that call failed. 2. Receive incorrect permission check results, if those relationships had to be read to resolve the relation involving the exclusion. ### Patches Upgrade to v.145.2. ### Workarounds Set `--write-relationships-max-updates-per-call` to `1000`.

## Summary In impacted versions of Astro using [on-demand rendering](https://docs.astro.build/en/guides/on-demand-rendering/), request headers `x-forwarded-proto` and `x-forwarded-port` are insecurely used, without sanitization, to build the URL. This has several consequences the most important of which are: - Middleware-based protected route bypass (only via `x-forwarded-proto`) - DoS via cache poisoning (if a CDN is present) - SSRF (only via `x-forwarded-proto`) - URL pollution (potential SXSS, if a CDN is present) - WAF bypass ## Details The `x-forwarded-proto` and `x-forwarded-port` headers are used without sanitization in two parts of the Astro server code. The most important is in the `createRequest()` function. Any configuration, including the default one, is affected: [https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/packages/astro/src/core/app/node.ts#L97](https://github.com/withastro/astro/blob/970ac0f51172e1e6bff4440516a851e725ac3097/pa...