deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-7vf8-2cr6-54mf
Package: github.com/argoproj/argo-workflows/v4 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-522: Insufficiently Protected Credentials
Vulnerable versions: >= 4.0.0, < 4.0.5
Patched in: 4.0.5

Summary: Argo vulnerable to exposure of artifact repository credentials

Details:
### Summary
The workflow executor logs all artifact repository credentials (S3 access keys, secret keys, GCS service account keys, Azure account keys, Git passwords, etc.) in plaintext on artifact operation. Any user with read access to workflow pod logs can extract these credentials.

**Note:** This is an incomplete fix of [CVE-2025-62157](https://github.com/argoproj/argo-workflows/security/advisories/GHSA-c2hv-4pfj-mm2r)
### Details
The logging driver passes the entire ArtifactDriver struct to the structured logger, for example:
https://github.com/argoproj/argo-workflows/blob/59f1089b9875723ddffd524513e6bd5cb37e5e31/workflow/artifacts/logging/driver.go#L24

Exposed credential fields:
- S3 (workflow/artifacts/s3/s3.go): AccessKey, SecretKey, SessionToken, ServerSideCustomerKey
- OSS (workflow/artifacts/oss/oss.go): AccessKey, SecretKey, SecurityToken
- GCS (workflow/artifacts/gcs/gcs.go): ServiceAccountKey

### PoC
1. Create template
```yml
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  name: cred-leak-test
  namespace: argo
spec:
  entrypoint: main
  templates:
  - name: main
    container:
      image: alpine:3.13
      command: [sh, -c]
      args: ["echo 'hello' > /tmp/output.txt"]
    outputs:
      artifacts:
      - name: output
        path: /tmp/output.txt
        s3:
          endpoint: minio:9000
          insecure: true
          bucket: my-bucket
          key: test-output.txt
          accessKeySecret:
            name: my-minio-cred
            key: accesskey
          secretKeySecret:
            name: my-minio-cred
            key: secretkey
```

2. Then check the logs
`kubectl -n argo logs "cred-leak-test" -c wait`
<img width="1248" height="322" alt="image" src="https://github.com/user-attachments/assets/a5cf6d66-7d67-408d-8583-27d11ecf1507" />


### Impact
Any user with Kubernetes RBAC permissions to read pod logs in the workflow namespace can extract artifact repository credentials.
GitHub Security Advisory: GHSA-jcc8-g2q4-9fxq
Package: github.com/argoproj/argo-workflows/v4 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 4.0.0, < 4.0.5
Patched in: 4.0.5

Summary: Argo Vulnerable to Unauthenticated Memory Exhaustion (DoS) in Webhook Interceptor

Details:
**Severity:** Medium
**Component:** Webhook Interceptor (`server/auth/webhook`)
**Vulnerability Type:** Denial of Service (DoS)

## Description
The Webhook Interceptor loads the entire request body into memory before authenticating the request or verifying its signature. This occurs on the `/api/v1/events/` endpoint, which is publicly accessible (albeit intended for webhooks). An attacker can send a request with an extremely large body (e.g., multiple gigabytes), causing the Argo Server to allocate excessive memory, potentially leading to an Out-Of-Memory (OOM) crash and denial of service.

## Vulnerable Code
In `server/auth/webhook/interceptor.go`:
```go
func (i *WebhookInterceptor) addWebhookAuthorization(r *http.Request, kube kubernetes.Interface) error {
    // ... basic checks ...
    
    // Vulnerability: Reads entire body into memory unconditionally
    buf, _ := io.ReadAll(r.Body)
    defer func() { r.Body = io.NopCloser(bytes.NewBuffer(buf)) }()
    
    // ... subsequent logic finds correct service account and secret ...
    // ... verification happens later ...
}
```
The `io.ReadAll` call happens before the signature verification loop.

## Impact
- **Service Availability:** An attacker can crash the Argo Server, disrupting workflow execution and API access for all users.

## PoC (Conceptual)
1.  Target the webhook endpoint: `POST /api/v1/events/some-namespace`
2.  Send a `Content-Length:[PII_REDACTED]` (1GB) header.
3.  Stream 1GB of random data.
4.  Monitor server memory usage. It will spike until 1GB is allocated or the process crashes.

## Recommendation
1.  **Limit Body Size:** Enforce a strict limit on webhook body size (e.g., 10MB) using `http.MaxBytesReader`.
2.  **Streaming Verification:** If possible, verify the signature in a streaming fashion or use a temporary file for large payloads (though typically webhooks are small).
GitHub Security Advisory: GHSA-jcc8-g2q4-9fxq
Package: github.com/argoproj/argo-workflows/v3 (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 3.7.14
Patched in: 3.7.14

Summary: Argo Vulnerable to Unauthenticated Memory Exhaustion (DoS) in Webhook Interceptor

Details:
**Severity:** Medium
**Component:** Webhook Interceptor (`server/auth/webhook`)
**Vulnerability Type:** Denial of Service (DoS)

## Description
The Webhook Interceptor loads the entire request body into memory before authenticating the request or verifying its signature. This occurs on the `/api/v1/events/` endpoint, which is publicly accessible (albeit intended for webhooks). An attacker can send a request with an extremely large body (e.g., multiple gigabytes), causing the Argo Server to allocate excessive memory, potentially leading to an Out-Of-Memory (OOM) crash and denial of service.

## Vulnerable Code
In `server/auth/webhook/interceptor.go`:
```go
func (i *WebhookInterceptor) addWebhookAuthorization(r *http.Request, kube kubernetes.Interface) error {
    // ... basic checks ...
    
    // Vulnerability: Reads entire body into memory unconditionally
    buf, _ := io.ReadAll(r.Body)
    defer func() { r.Body = io.NopCloser(bytes.NewBuffer(buf)) }()
    
    // ... subsequent logic finds correct service account and secret ...
    // ... verification happens later ...
}
```
The `io.ReadAll` call happens before the signature verification loop.

## Impact
- **Service Availability:** An attacker can crash the Argo Server, disrupting workflow execution and API access for all users.

## PoC (Conceptual)
1.  Target the webhook endpoint: `POST /api/v1/events/some-namespace`
2.  Send a `Content-Length:[PII_REDACTED]` (1GB) header.
3.  Stream 1GB of random data.
4.  Monitor server memory usage. It will spike until 1GB is allocated or the process crashes.

## Recommendation
1.  **Limit Body Size:** Enforce a strict limit on webhook body size (e.g., 10MB) using `http.MaxBytesReader`.
2.  **Streaming Verification:** If possible, verify the signature in a streaming fashion or use a temporary file for large payloads (though typically webhooks are small).
GitHub Security Advisory: GHSA-p4gq-3vxj-f4jq
Package: github.com/argoproj/argo-workflows/v4 (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: >= 4.0.0, <= 4.0.4
Patched in: 4.0.5

Summary: Argo Affected by SSO RBAC Delegation Nil Pointer Dereference DoS (gatekeeper.go)

Details:
### Summary
A nil pointer dereference in `server/auth/gatekeeper.go` `rbacAuthorization()` causes a panic (denial of service) for SSO users whose claims match a namespace-level RBAC rule but not an SSO-namespace rule, when `SSO_DELEGATE_RBAC_TO_NAMESPACE=true`.

### Details
When `getServiceAccount(claims, ssoNamespace)` returns nil (no matching rule), the error is suppressed and `loginAccount` remains nil. If RBAC delegation finds a matching `namespaceAccount`, line 304 calls `precedence(loginAccount)` which unconditionally accesses `serviceAccount.Annotations` — nil pointer dereference.

**Affected code (v4.0.4):**

```go
// gatekeeper.go:304
} else if precedence(namespaceAccount) > precedence(loginAccount) {
    // loginAccount is nil here -> precedence(nil) -> PANIC

// gatekeeper.go:232-234
func precedence(serviceAccount *corev1.ServiceAccount) int {
    i, _ := strconv.Atoi(serviceAccount.Annotations[common.AnnotationKeyRBACRulePrecedence])
    return i
}
```

### PoC
**Live-tested 2026-04-17:** kind cluster, Argo Workflows v4.0.4, Dex v2.43.1 OIDC provider.

1. Deploy Argo Workflows with `--auth-mode=sso --auth-mode=client`, SSO pointing to Dex, RBAC enabled.
2. Set `SSO_DELEGATE_RBAC_TO_NAMESPACE=true` on the argo-server deployment.
3. Create an RBAC ServiceAccount with `workflows.argoproj.io/rbac-rule: "true"` annotation in a target namespace (e.g., `target-ns`).
4. Do **not** create a matching RBAC rule in the SSO namespace (`argo`).
5. Authenticate via the Dex SSO flow.
6. Request `GET /api/v1/workflows/target-ns` with the SSO session cookie.
7. Server returns HTTP 500: `{"code":13,"message":"runtime error: invalid memory address or nil pointer dereference"}`
8. Server logs: `Recovered from panic` with stack trace at `gatekeeper.go:233` (`precedence()`) called from `gatekeeper.go:304`.

Every subsequent API request from affected SSO users triggers the same panic.

### Impact
Permanent denial of service for any SSO user whose claims don't match SSO-namespace RBAC but do match a target namespace rule. Realistic in multi-tenant deployments with per-namespace RBAC. The gRPC recovery interceptor catches the panic so the server process survives, but the affected user gets HTTP 500 on every request.

### Suggested Fix
Add nil check: `if loginAccount == nil || precedence(namespaceAccount) > precedence(loginAccount)`

### AI Disclosure
This advisory was prepared with AI assistance (Claude Code, Anthropic).
GitHub Security Advisory: GHSA-fwj8-62r8-8p8m
Package: github.com/lxc/incus/v6/cmd/incusd (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-476: NULL Pointer Dereference
Vulnerable versions: <= 6.23.0
Patched in: unpatched

Summary: Incus has Nil-Pointer Dereference via S3 Bucket Import

Details:
### Summary
Missing error handling could lead an authenticated Incus user to cause a daemon crash through the import of a truncated storage bucket backup file.

### Details
It was found that TransferManager.UploadAllFiles iterates over tar entries but only checks for io.EOF from tr.Next(). When tr.Next() returns a non-EOF error, such as unexpected EOF from a truncated archive, the header hdr is nil and the code continues to access hdr.Name, causing a nil-pointer dereference that panics the daemon.

This may allow the Incus daemon to be crashed during S3 bucket restore if a truncated or corrupted backup archive is provided. A panic can occur when a malformed archive produces a non-EOF tar read error after the first entry. Any caller of UploadAllFiles that processes attacker-controlled archive content may be affected.

Affected File:
[https://github.com/lxc/incus/blob/v6.22.0/…server/storage/s3/transfer_manager.go#L127](https://github.com/lxc/incus/blob/v6.22.0/internal/server/storage/s3/transfer_manager.go#L127) 

The tar-iteration loop only checks for EOF:

Affected Code:
```
for {
    hdr, err := tr.Next()
    if err == io.EOF {
        break // End of archive.
    }

    // Skip index.yaml file
    if hdr.Name == "backup/index.yaml" {
```

When tr.Next() returns a non-EOF error, hdr is nil. The code does not check for this case and immediately dereferences hdr.Name.

This was confirmed as follows:

Command:
```
go test ./test/fuzz -run='FuzzS3BucketUploadTarParsing/s3_nil_deref_truncated_tar' -count=1 -v
```

Output:
```
=== RUN   FuzzS3BucketUploadTarParsing
=== RUN   FuzzS3BucketUploadTarParsing/s3_nil_deref_truncated_tar
   s3_bucket_upload_fuzz_test.go:82: UploadAllFiles panicked: runtime error: invalid memory address
       or nil pointer dereference
--- FAIL: FuzzS3BucketUploadTarParsing/s3_nil_deref_truncated_tar (0.00s)
FAIL
```

It is recommended to add a non-EOF error check after tr.Next().

Proposed Fix:
```
hdr, err := tr.Next()
if err == io.EOF {
    break
}

if err != nil {
    return fmt.Errorf("Error reading backup archive: %w", err)
}
```

A patch is available at https://github.com/lxc/incus/releases/tag/v7.0.0.

### Credits
This issue was discovered and reported by the team at 7asecurity (https://7asecurity.com/)
GitHub Security Advisory: GHSA-rh99-wc69-c255
Package: github.com/edgelesssys/contrast (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: < 1.19.1
Patched in: 1.19.1

Summary: Contras Affected by CopyFile Policy Subversion via Symlinks

Details:
### Impact

The [Kata agent policies](https://docs.edgeless.systems/contrast/architecture/components/policies) generated by the Contrast CLI had an issue in the `CopyFile` verification, which allowed arbitrary writes to the guest root filesytem. A malicious process on the host with the capability to connect to the Kata agent VSOCK could connect to the agent and issue a series of `CopyFile` requests to overwrite security-critical files or trick the workload into disclosing sensitive data, which effectively amounts to a full guest takeover.

### Patches

This issue has been patched in Contrast v1.19.1.

Note that this fix does not change the fact that host-provided content is generally not trustworthy, as documented.

### Workarounds

If upgrading is not possible, users can implement the fix in rego and pass it to `contrast generate --policy`. The rego-only fix is a bit trickier than the patch, because the data to check is binary. See the references for details.

### Resources

* Upstream GHSA: https://github.com/kata-containers/kata-containers/security/advisories/GHSA-q49m-57vm-c8cc
* Alternative policy-only fix: https://gist.github.com/burgerdev/304dd0ab0fff1665b7c27e18a30cf96e
GitHub Security Advisory: GHSA-28xx-pppm-vqff
Package: github.com/ydb-platform/ydb-go-sdk/v3 (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-670: Always-Incorrect Control Flow Implementation
Vulnerable versions: >= 3.104.6, <= 3.134.1
Patched in: 3.134.2

Summary: ydb-go-sdk's transactions are not committed using the `options.WithCommit()` option on last call `table.Transaction.Execute` in transaction

Details:
### Impact
Transactions were NOT committed despite the explicit `options.WithCommit` flag using table service client. Because of this, clients did not commit changes to the transaction, relying on the fact that the transaction commit was successful. This led (in rare cases) to a loss of data consistency.

### Patches
`ydb-go-sdk` contains this problem in versions from [v3.104.6](https://github.com/ydb-platform/ydb-go-sdk/releases/tag/v3.104.6) to [v3.134.1](https://github.com/ydb-platform/ydb-go-sdk/releases/tag/v3.134.1). The fix for this problem has been released in version [v3.134.2](https://github.com/ydb-platform/ydb-go-sdk/releases/tag/v3.134.2) (https://github.com/ydb-platform/ydb-go-sdk/pull/2091).

### Workarounds
1) Use explicit `table.Transaction.CommitTx(ctx)` instead use `options.WithCommit()`.
2) Use transaction retrier `db.Table().DoTx(ctx, lambda)` instead explicit start transaction on session.
3) Use query client `db.Query().Do(ctx, lambda)` with the same logic in `lambda`

### Resources
Commit with bug https://github.com/ydb-platform/ydb-go-sdk/commit/251128a64763555d9a79ee7a131dd154c9000eb9
Commit with fix https://github.com/ydb-platform/ydb-go-sdk/commit/25dcff4c41153f1f9413512ba12999b40bf7154d
GitHub Security Advisory: GHSA-vjgj-42f6-7997
Package: github.com/tinfoil-factory/netfoil (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-791: Incomplete Filtering of Special Elements
Vulnerable versions: < 0.2.1
Patched in: 0.2.1

Summary: netfoil's optional seccomp sandboxing was not applied

Details:
### Summary
The optional flag `--filter-system-calls` was not applied even if specified.

### Details
This is a defense in depth feature to apply additional seccomp filters after the binary has started. The example config also sandboxes the binary with systemd.

### Impact
Reduced sandboxing of the netfoil binary.
GitHub Security Advisory: GHSA-84g5-x8j3-7235
Package: github.com/tinfoil-factory/netfoil (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-183: Permissive List of Allowed Inputs, CWE-193: Off-by-one Error
Vulnerable versions: < 0.2.1
Patched in: 0.2.1

Summary: Netfoil has incorrect allowlist enforcement

Details:
### Summary
Rules could be bypassed by changing the first character: `example.com` could be be bypassed by e.g. `fxample.com`.

### Details
Off-by-one error in the suffixtrie implementation.

### Impact
The domain filter could be bypassed. Please note that DNS filtering alone is not enough to block malicious traffic.
GitHub Security Advisory: GHSA-x274-8qfc-hrgf
Package: github.com/mattermost/mattermost-plugin-msteams (GO)
Severity: LOW (CVSS 3.7)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.15.1-0[PII_REDACTED]0728-6fe4d295592e
Patched in: 1.15.1-0[PII_REDACTED]0728-6fe4d295592e

Summary: Mattermost MS Teams plugin doesn't limit the request body size on the /lifecycle webhook endpoint 

Details:
Mattermost Plugins versions <=2.3.1 fail to limit the request body size on the {{/lifecycle}} webhook endpoint which allows an authenticated attacker to cause memory exhaustion and denial of service via sending an oversized JSON payload. Mattermost Advisory ID: MMSA-2026-00610.
GitHub Security Advisory: GHSA-5rfv-h47g-xj42
Package: github.com/mattermost/mattermost-plugin-msteams (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 1.15.1-0[PII_REDACTED]0728-6fe4d295592e
Patched in: 1.15.1-0[PII_REDACTED]0728-6fe4d295592e

Summary: Mattermost MS Teams plugin doesn't limit the request body size on the /changes webhook endpoint

Details:
Mattermost Plugins versions <=2.1.3.0 fail to limit the request body size on the {{/changes}} webhook endpoint which allows an authenticated attacker to cause memory exhaustion and denial of service via sending an oversized JSON payload. Mattermost Advisory ID: MMSA-2026-00611.
GitHub Security Advisory: GHSA-m7cf-4gh2-v4qg
Package: github.com/mattermost/mattermost/server/v8 (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: >= 11.3.0-rc1, < 11.3.3
Patched in: 11.3.3

Summary: Mattermost doesn't validate CSRF tokens on an authentication endpoint

Details:
Mattermost versions 10.11.x <= 10.11.12, 11.5.x <= 11.5.0, 11.4.x <= 11.4.2, 11.3.x <= 11.3.2 fail to validate CSRF tokens on an authentication endpoint which allows an attacker to update a user's authentication method via a CSRF attack by tricking a user into visiting a malicious page. Mattermost Advisory ID: MMSA-2026-00625.
GitHub Security Advisory: GHSA-m7cf-4gh2-v4qg
Package: github.com/mattermost/mattermost/server/v8 (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: >= 11.4.0-rc1, < 11.4.3
Patched in: 11.4.3

Summary: Mattermost doesn't validate CSRF tokens on an authentication endpoint

Details:
Mattermost versions 10.11.x <= 10.11.12, 11.5.x <= 11.5.0, 11.4.x <= 11.4.2, 11.3.x <= 11.3.2 fail to validate CSRF tokens on an authentication endpoint which allows an attacker to update a user's authentication method via a CSRF attack by tricking a user into visiting a malicious page. Mattermost Advisory ID: MMSA-2026-00625.
GitHub Security Advisory: GHSA-m7cf-4gh2-v4qg
Package: github.com/mattermost/mattermost/server/v8 (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: = 11.5.0-rc1
Patched in: 11.5.0

Summary: Mattermost doesn't validate CSRF tokens on an authentication endpoint

Details:
Mattermost versions 10.11.x <= 10.11.12, 11.5.x <= 11.5.0, 11.4.x <= 11.4.2, 11.3.x <= 11.3.2 fail to validate CSRF tokens on an authentication endpoint which allows an attacker to update a user's authentication method via a CSRF attack by tricking a user into visiting a malicious page. Mattermost Advisory ID: MMSA-2026-00625.
GitHub Security Advisory: GHSA-m7cf-4gh2-v4qg
Package: github.com/mattermost/mattermost/server/v8 (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: >= 8.0.0[PII_REDACTED]2209-4952acea88ce, < 8.0.0[PII_REDACTED]3927-c29cf05d40f8
Patched in: 8.0.0[PII_REDACTED]3927-c29cf05d40f8

Summary: Mattermost doesn't validate CSRF tokens on an authentication endpoint

Details:
Mattermost versions 10.11.x <= 10.11.12, 11.5.x <= 11.5.0, 11.4.x <= 11.4.2, 11.3.x <= 11.3.2 fail to validate CSRF tokens on an authentication endpoint which allows an attacker to update a user's authentication method via a CSRF attack by tricking a user into visiting a malicious page. Mattermost Advisory ID: MMSA-2026-00625.
GitHub Security Advisory: GHSA-gqp3-hfc3-8q54
Package: github.com/usememos/memos (GO)
Severity: LOW (CVSS 6.3)
CWE: CWE-266: Incorrect Privilege Assignment
Vulnerable versions: <= 0.22.1
Patched in: unpatched

Summary: Memos has an Incorrect Privilege Assignment issue

Details:
A weakness has been identified in usememos memos up to 0.22.1. This affects the function memos_access_token of the file src/App.tsx of the component UpdateInstanceSetting. This manipulation of the argument additionalStyle/additionalScript causes improper authorization. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
GitHub Security Advisory: GHSA-mxxh-fmjq-j6x4
Package: github.com/mattermost/mattermost-server (GO)
Severity: LOW (CVSS 2.7)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 8.0.0[PII_REDACTED]2209-4952acea88ce, < 8.0.0[PII_REDACTED]0126-bc1a2b34b1f9
Patched in: 8.0.0[PII_REDACTED]0126-bc1a2b34b1f9

Summary: Mattermost doesn't validate whether users were correctly owned by the correct Connected Workspace

Details:
Mattermost versions 10.11.x <= 10.11.12 fail to validate whether users were correctly owned by the correct Connected Workspace which allows a malicious remote server connected using the Conntexted Workspaces feature to change the displayed status of local users via the Connected Workspaces API. Mattermost Advisory ID: MMSA-2026-00603.
GitHub Security Advisory: GHSA-mh4x-rmrx-3hp4
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: >= 11.3.0-rc1, < 11.3.3
Patched in: 11.3.3

Summary: Mattermost has session spoofing due to lack of single-use consumption of guest magic link tokens enforcement

Details:
Mattermost versions 10.11.x <= 10.11.12, 11.5.x <= 11.5.0, 11.4.x <= 11.4.2, 11.3.x <= 11.3.2 fail to enforce atomic single-use consumption of guest magic link tokens, which allows an attacker with access to a valid magic link to establish multiple independent authenticated sessions via concurrent requests. Mattermost Advisory ID: MMSA-2026-00624.
GitHub Security Advisory: GHSA-mh4x-rmrx-3hp4
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: >= 11.4.0-rc1, < 11.4.3
Patched in: 11.4.3

Summary: Mattermost has session spoofing due to lack of single-use consumption of guest magic link tokens enforcement

Details:
Mattermost versions 10.11.x <= 10.11.12, 11.5.x <= 11.5.0, 11.4.x <= 11.4.2, 11.3.x <= 11.3.2 fail to enforce atomic single-use consumption of guest magic link tokens, which allows an attacker with access to a valid magic link to establish multiple independent authenticated sessions via concurrent requests. Mattermost Advisory ID: MMSA-2026-00624.
GitHub Security Advisory: GHSA-mh4x-rmrx-3hp4
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: = 11.5.0-rc1
Patched in: 11.5.0

Summary: Mattermost has session spoofing due to lack of single-use consumption of guest magic link tokens enforcement

Details:
Mattermost versions 10.11.x <= 10.11.12, 11.5.x <= 11.5.0, 11.4.x <= 11.4.2, 11.3.x <= 11.3.2 fail to enforce atomic single-use consumption of guest magic link tokens, which allows an attacker with access to a valid magic link to establish multiple independent authenticated sessions via concurrent requests. Mattermost Advisory ID: MMSA-2026-00624.