deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-pgvm-wxw2-hrv9
Package: github.com/labstack/echo/v5 (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 5.0.0, < 5.0.3
Patched in: 5.0.3

Summary: Echo has a Windows path traversal via backslash in middleware.Static default filesystem

Details:
### Summary
On Windows, Echo’s `middleware.Static` using the default filesystem allows path traversal via backslashes, enabling
unauthenticated remote file read outside the static root.

### Details  

  In `middleware/static.go`, the requested path is unescaped and normalized with `path.Clean` (URL semantics).
  `path.Clean` does **not** treat `\` as a path separator, so `..\` sequences remain in the cleaned path. The resulting
  path is then passed to `currentFS.Open(...)`. When the filesystem is left at the default (nil), Echo uses `defaultFS`
  which calls `os.Open` (`echo.go:792`). On Windows, `os.Open` treats `\` as a path separator and resolves `..\`,
  allowing traversal outside the static root.

  Relevant code:
  - `middleware/static.go` (path unescape + `path.Clean` + `currentFS.Open`)
  - `echo.go` `defaultFS.Open` → `os.Open`

  This is the same class as CVE-2020-36565 (fixed in v4 by switching to OS-aware cleaning), but in v5 the `path.Clean`
  + defaultFS combination reintroduces the Windows backslash traversal.


### PoC
 Windows only.

  **Sample code (main.go):**
  ```go
  package main

  import (
        "log"
        "net/http"

        "github.com/labstack/echo/v5"
        "github.com/labstack/echo/v5/middleware"
  )

  func main() {
        e := echo.New()

        // Important: use middleware.Static with default filesystem (nil)
        e.Use(middleware.Static("public"))

        e.GET("/healthz", func(c *echo.Context) error {
                return c.String(http.StatusOK, "ok")
        })

        addr := ":1323"
        log.Printf("listening on %s", addr)
        if err := e.Start(addr); err != nil && err != http.ErrServerClosed {
                log.Fatal(err)
        }
  }
 ```
  Static file:

  public/index.html

  (content can be any HTML)

  **Run:**
  go run .

  **Verify:**

  curl http://localhost:1323/index.html
  curl --path-as-is "http://localhost:1323/..%5c..%5cWindows%5cSystem32%5cdrivers%5cetc%5chosts"
  Expected: 404  

  **Screenshot:**
<img width="884" height="689" alt="image" src="https://github.com/user-attachments/assets/acb14d70-2a43-47c1-8927-2f3da491a853" />
<img width="1022" height="162" alt="image" src="https://github.com/user-attachments/assets/f2b92aa2-541e-461d-81a2-8a5907d7a447" />



  ### Impact
  Path traversal leading to arbitrary file read outside the static root. Any unauthenticated remote user can
  read local files that the Echo process has access to on Windows, if `middleware.Static` is used with the default
  filesystem.
GitHub Security Advisory: GHSA-jj5m-h57j-5gv7
Package: gogs.io/gogs (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: <= 0.13.4
Patched in: 0.14.0

Summary: Gogs Allows Cross-Repository Comment Deletion via DeleteComment

Details:
# IDOR: Cross-Repository Comment Deletion via DeleteComment

## Summary

The `POST /:owner/:repo/issues/comments/:id/delete` endpoint does not verify that the comment belongs to the repository specified in the URL. This allows a repository administrator to delete comments from any other repository by supplying arbitrary comment IDs, bypassing authorization controls.

## Vulnerability Details

| Field | Value |
|-------|-------|
| Affected File | `internal/route/repo/issue.go` |
| Affected Function | `DeleteComment` (lines 955-968) |
| Secondary File | `internal/database/comment.go` |
| Secondary Function | `DeleteCommentByID` (lines 505-520) |

## Root Cause

The vulnerability exists due to insufficient authorization validation in the comment deletion flow:

### 1. Missing Repository Ownership Check in DeleteComment

In `internal/route/repo/issue.go`, the function retrieves a comment by ID without verifying repository ownership:

```go
func DeleteComment(c *context.Context) {
    comment, err := database.GetCommentByID(c.ParamsInt64(":id"))
    if err != nil {
        c.NotFoundOrError(err, "get comment by ID")
        return
    }

    // Only checks if user is comment poster OR admin of the CURRENT repo (from URL)
    if c.UserID() != comment.PosterID && !c.Repo.IsAdmin() {
        c.NotFound()
        return
    } else if comment.Type != database.CommentTypeComment {
        c.Status(http.StatusNoContent)
        return
    }

    // No verification that comment.IssueID belongs to c.Repo.Repository.ID!
    if err = database.DeleteCommentByID(c.User, comment.ID); err != nil {
        c.Error(err, "delete comment by ID")
        return
    }

    c.Status(http.StatusOK)
}
```

### 2. Database Layer Performs No Authorization

In `internal/database/comment.go`, the deletion function performs no repository validation:

```go
func DeleteCommentByID(doer *User, id int64) error {
    comment, err := GetCommentByID(id)
    if err != nil {
        if IsErrCommentNotExist(err) {
            return nil
        }
        return err
    }

    // Directly deletes without checking repository ownership
    sess := x.NewSession()
    defer sess.Close()
    if err = sess.Begin(); err != nil {
        return err
    }

    if _, err = sess.ID(comment.ID).Delete(new(Comment)); err != nil {
        // ...
    }
    // ...
}
```

## Proof of Concept

### Prerequisites

1. Two users: **Alice** (attacker) and **Bob** (victim)
2. Alice is admin of `alice/attacker-repo`
3. Bob has created an issue with a comment on `bob/victim-repo`
4. Attacker needs to obtain the comment ID from victim's repository (e.g., ID: 42)

### HTTP Request

```http
POST /alice/attacker-repo/issues/comments/42/delete HTTP/1.1
Host: gogs.example.com
Cookie: i_like_gogs=<alice_session_token>

```
GitHub Security Advisory: GHSA-hr7j-63v7-vj7g
Package: github.com/pterodactyl/wings (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-284: Improper Access Control, CWE-613: Insufficient Session Expiration
Vulnerable versions: < 1.12.1
Patched in: 1.12.1

Summary: Pterodactyl Panel's SFTP sessions remain active after user account deletion or password change

Details:
### Summary
Deleting a user account with SFTP access or changing the user's password does not immediately terminate existing SFTP sessions, allowing continued filesystem access after credentials are revoked.
This can result in unintended and unauthorized access to server files even after administrators believe access has been fully invalidated.


### Details
When a user with SFTP access is deleted from the Pterodactyl Panel or when the user's password is changed while one or more SFTP connections are active, those existing connections remain fully functional.

Neither account deletion nor password change invalidates the authentication state of already-established SFTP sessions. As a result, the active SFTP connection pool continues to allow read and write operations until the client disconnects or the session times out.

This behavior occurs even when the password is changed by an administrator through the panel, meaning credential rotation does not revoke active access.

This suggests that active SFTP sessions are not tracked or forcefully terminated on credential revocation events. This effectively prevents administrators from responding to credential compromise incidents in real time.


### PoC
Scenario 1: Account deletion
1. Create a user with SFTP access to a server.
2. Connect to the server via SFTP using any SFTP client (e.g. sftp, FileZilla).
3. Keep the SFTP session open and active.
4. Delete the user account from the Pterodactyl Panel.
5. Continue performing file operations through the already-established SFTP connection.

Result:
The SFTP session remains active and usable despite the user account being deleted.

Scenario 2: Password change
1. Create a user with SFTP access to a server.
2. Establish an active SFTP connection.
3. Change the user's password (including via administrator panel).
4. Continue performing file operations using the existing SFTP connection.

Result:
The SFTP session remains active and usable even after the password has been changed.


### Impact
This issue prevents immediate revocation of compromised credentials. Vulnerability type: Access control / session invalidation issue

Impacted parties:

1. Server administrators
2. Hosting providers using Pterodactyl Panel

Security impact:

Deleted users may retain filesystem access longer than intended, which can lead to:

1. Unauthorized data access
2. Data modification or deletion
3. Compliance and security policy violations
GitHub Security Advisory: GHSA-9pj7-jh2r-87g8
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 10.11.0, <= 10.11.9
Patched in: 10.11.10

Summary: Mattermost doesn't validate user permissions when creating Jira issues from Mattermost posts

Details:
Mattermost versions 11.1.x <= 11.1.2, 10.11.x <= 10.11.9, 11.2.x <= 11.2.1 fail to validate user permissions when creating Jira issues from Mattermost posts, which allows an authenticated attacker with access to the Jira plugin to read post content and attachments from channels they do not have access to via the /create-issue API endpoint by providing the post ID of an inaccessible post.. Mattermost Advisory ID: MMSA-2025-00550
GitHub Security Advisory: GHSA-9pj7-jh2r-87g8
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 11.1.0, <= 11.1.2
Patched in: 11.1.3

Summary: Mattermost doesn't validate user permissions when creating Jira issues from Mattermost posts

Details:
Mattermost versions 11.1.x <= 11.1.2, 10.11.x <= 10.11.9, 11.2.x <= 11.2.1 fail to validate user permissions when creating Jira issues from Mattermost posts, which allows an authenticated attacker with access to the Jira plugin to read post content and attachments from channels they do not have access to via the /create-issue API endpoint by providing the post ID of an inaccessible post.. Mattermost Advisory ID: MMSA-2025-00550
GitHub Security Advisory: GHSA-9pj7-jh2r-87g8
Package: github.com/mattermost/mattermost-server (GO)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 11.2.0, <= 11.2.1
Patched in: 11.2.2

Summary: Mattermost doesn't validate user permissions when creating Jira issues from Mattermost posts

Details:
Mattermost versions 11.1.x <= 11.1.2, 10.11.x <= 10.11.9, 11.2.x <= 11.2.1 fail to validate user permissions when creating Jira issues from Mattermost posts, which allows an authenticated attacker with access to the Jira plugin to read post content and attachments from channels they do not have access to via the /create-issue API endpoint by providing the post ID of an inaccessible post.. Mattermost Advisory ID: MMSA-2025-00550
GitHub Security Advisory: GHSA-2xf7-hmf6-p64j
Package: github.com/mattermost/mattermost-server (GO)
Severity: LOW (CVSS 3.1)
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vulnerable versions: >= 10.11.0, <= 10.11.9
Patched in: 10.11.10

Summary: Mattermost doesn't properly validate channel membership at the time of data retrieval

Details:
Mattermost versions 10.11.x <= 10.11.9 fail to properly validate channel membership at the time of data retrieval which allows a deactivated user to learn team names they should not have access to via a race condition in the /common_teams API endpoint.. Mattermost Advisory ID: MMSA-2025-00549
GitHub Security Advisory: GHSA-9f3f-wv7r-qc8r
Package: github.com/pion/dtls/v3 (GO)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 3.0.11
Patched in: 3.0.11

Summary: Pion DTLS's usage of random nonce generation with AES GCM ciphers risks leaking the authentication key

Details:
### Impact
Pion DTLS versions v1.0.0 through v3.0.10 use random nonce generation with AES GCM ciphers, which makes it easier for remote attackers to obtain the authentication key and spoof data by leveraging the reuse of a nonce in a session and a "forbidden attack". 

### Patches
Upgrade to v3.1.1 or later. This version includes PR #796, which uses the 64-bit sequence number to populate the `nonce_explicit` part of the GCM nonce. This is according to best practice outlined in [RFC 9325 section 7.2.1](https://www.rfc-editor.org/rfc/rfc9325#section-7.2.1). 

v3.0.11 is a backport patch supporting Go v1.21

### Workarounds
There are no workarounds without upgrading to version v3.0.11, v3.1.1 or later.

### References
Commit fixing the bug: https://github.com/pion/dtls/commit/61762dee[PII_REDACTED]c5eb79856b9e7a73ee349f
Commit fixing the bug (backport): 90e241c
Pull request: #796
GitHub Security Advisory: GHSA-9f3f-wv7r-qc8r
Package: github.com/pion/dtls/v3 (GO)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: = 3.1.0
Patched in: 3.1.1

Summary: Pion DTLS's usage of random nonce generation with AES GCM ciphers risks leaking the authentication key

Details:
### Impact
Pion DTLS versions v1.0.0 through v3.0.10 use random nonce generation with AES GCM ciphers, which makes it easier for remote attackers to obtain the authentication key and spoof data by leveraging the reuse of a nonce in a session and a "forbidden attack". 

### Patches
Upgrade to v3.1.1 or later. This version includes PR #796, which uses the 64-bit sequence number to populate the `nonce_explicit` part of the GCM nonce. This is according to best practice outlined in [RFC 9325 section 7.2.1](https://www.rfc-editor.org/rfc/rfc9325#section-7.2.1). 

v3.0.11 is a backport patch supporting Go v1.21

### Workarounds
There are no workarounds without upgrading to version v3.0.11, v3.1.1 or later.

### References
Commit fixing the bug: https://github.com/pion/dtls/commit/61762dee[PII_REDACTED]c5eb79856b9e7a73ee349f
Commit fixing the bug (backport): 90e241c
Pull request: #796
GitHub Security Advisory: GHSA-3c9m-gq32-g4jx
Package: github.com/neuvector/scanner (GO)
Severity: LOW (CVSS 3.8)
CWE: CWE-522: Insufficiently Protected Credentials
Vulnerable versions: >= 4.0, < 4.072
Patched in: 4.072

Summary: NeuVector scanner insecurely handles passwords as command arguments

Details:
### Impact
A vulnerability has been identified in the NeuVector scanner where the scanner process accepts registry and controller credentials as command-line arguments, potentially exposing sensitive credentials to local users. This may allow unauthorized access to registries or the NeuVector controller, potentially enabling image manipulation, information disclosure, or further lateral movement within the environment.

**Important:**
- For the exposure of credentials not related to Rancher NeuVector, the final impact severity for confidentiality, integrity and availability is dependent on the permissions the leaked credentials have on their services.
- It is recommended to review for potentially leaked credentials in this scenario and to change them if deemed necessary.

Please consult the associated [MITRE ATT&CK – Technique – Credential Access and Unsecured Credentials](https://attack.mitre.org/techniques/T1552/) for further information about this category of attack.

### Patches
Patched versions include release `v4.072` and above.

Starting from version `v4.072`, the scanner monitor process does not pass credentials to the scanner anymore. Instead, scanner process gets credentials information from environment variables, preventing them from being exposed through `/proc/*/cmdline`.

### Workarounds
There is no workaround for this issue. Users are recommended to upgrade, as soon as possible, to a version of NeuVector scanner that contains the fix.

### References
If you have any questions or comments about this advisory:
- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
- Open an issue in the [NeuVector](https://github.com/neuvector/neuvector/issues/new/choose) repository.
- Verify with our [support matrix](https://www.suse.com/suse-neuvector/support-matrix/all-supported-versions/neuvector-v-all-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/#suse-security).
GitHub Security Advisory: GHSA-w4gw-w5jq-g9jh
Package: golang.org/x/net/html (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-407: Inefficient Algorithmic Complexity
Vulnerable versions: < 0.45.0
Patched in: 0.45.0

Summary: golang.org/x/net/html has a Quadratic Parsing Complexity issue

Details:
The html.Parse function in golang.org/x/net/html has quadratic parsing complexity when processing certain inputs, which can lead to Denial of Service (DoS) if an attacker provides specially crafted HTML content.
GitHub Security Advisory: GHSA-m2ch-x2q7-2284
Package: github.com/mattermost/mattermost-server (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 3.7.4-0[PII_REDACTED]1331-0b5c0794fdcb
Patched in: 3.7.4-0[PII_REDACTED]1331-0b5c0794fdcb

Summary: Mattermost Server allows an attacker to specify a full pathname of a log file

Details:
An issue was discovered in Mattermost Server before 3.7.5. It allows an attacker to specify a full pathname of a log file.
GitHub Security Advisory: GHSA-2f2x-8mwp-p2gc
Package: github.com/quic-go/webtransport-go (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-401: Missing Release of Memory after Effective Lifetime, CWE-459: Incomplete Cleanup
Vulnerable versions: <= 0.9.0
Patched in: 0.10.0

Summary: webtransport-go: Memory Exhaustion Attack due to Missing Cleanup of Streams Map

Details:
## Summary
An attacker can cause unbounded memory consumption repeatedly creating and closing many WebTransport streams. Closed streams were not removed from an internal session map, preventing garbage collection of their resources.

## Details
webtransport-go maintains an internal map tracking WebTransport streams (both unidirectional and bidirectional) belonging to a session. In affected versions, entries for closed streams were not removed from this map, causing the map to grow indefinitely as streams were created and closed.

A malicious peer can exploit this by opening large numbers of streams and closing them, leading to steady memory growth proportional to the number of closed streams.

## The Fix
webtransport-go now removes closed streams from the internal map upon closure. This allows the associated resources to be garbage collected, bounding memory usage to active streams only.
GitHub Security Advisory: GHSA-px4r-g4p3-hhqv
Package: github.com/quic-go/webtransport-go (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 0.9.0
Patched in: 0.10.0

Summary: webtransport-go: CloseWithError can block indefinitely

Details:
## Summary
An attacker can cause a denial of service in webtransport-go by preventing or indefinitely delaying WebTransport session closure. A malicious peer can withhold QUIC flow control credit on the CONNECT stream, blocking transmission of the WT_CLOSE_SESSION capsule and causing the close operation to hang.

## Details
WebTransport over HTTP/3 signals session termination by sending a WT_CLOSE_SESSION capsule on the CONNECT stream. The capsule is only needed to transmit a reason phrase and an error code to the peer. After the capsule is sent, the CONNECT stream is closed.
In affected versions, the closure procedure blocked indefinitely while waiting for sufficient QUIC flow control credit from the peer. A malicious peer can withhold this credit, preventing the capsule from being sent.

## The Fix
webtransport-go now attempts to send the WT_CLOSE_SESSION capsule with a short deadline. If the capsule cannot be sent within this deadline, the CONNECT stream is reset instead. This closes the WebTransport session promptly without transmitting the optional error details.
This prevents indefinite blocking on session closure.
GitHub Security Advisory: GHSA-g6x7-jq8p-6q9q
Package: github.com/quic-go/webtransport-go (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 0.3.0, <= 0.9.0
Patched in: 0.10.0

Summary: webtransport-go: Memory Exhaustion Attack due to Missing Length Check in WT_CLOSE_SESSION Capsule

Details:
## Summary
An attacker can cause excessive memory consumption in webtransport-go's session implementation by sending a WT_CLOSE_SESSION capsule containing an excessively large Application Error Message. The implementation does not enforce the draft-mandated limit of 1024 bytes on this field, allowing a peer to send an arbitrarily large message payload that is fully read and stored in memory.

This allows an attacker to consume an arbitrary amount of memory. The attacker must transmit the full payload to achieve the memory consumption, but the lack of any upper bound makes large-scale attacks feasible given sufficient bandwidth.

## Details
WebTransport over HTTP/3, as defined in draft-ietf-webtrans-http3, uses the WT_CLOSE_SESSION capsule to signal session termination with an optional detailed error. The draft specifies that the length of the Application Error Message in this capsule MUST NOT exceed 1024 bytes.
In affected versions of webtransport-go, the parser does not enforce this 1024-byte maximum when processing incoming WT_CLOSE_SESSION capsules. A peer can send a capsule with an excessively large payload, forcing the recipient to allocate and buffer the full amount of transmitted data without bound.

## The Fix
webtransport-go now limits the length of the parsed Application Error Message to 1024 bytes in WT_CLOSE_SESSION capsules by reading no more than this amount. This prevents excessive memory consumption.
GitHub Security Advisory: GHSA-m4g2-2q66-vc9v
Package: code.vikunja.io/api (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Vulnerable versions: <= 0.24.6
Patched in: unpatched

Summary: Vikunja Vulnerable to XSS Via Task Preview

Details:
### Summary
The task preview component creates a unparented div. The div's `innerHtml` is set to the unescaped description of the task

### Details
In the `TaskGlanceTooltip.vue` it temporarily creates a div and sets the `innerHtml` to the description [here](https://github.com/go-vikunja/vikunja/blob/cdca[PII_REDACTED]6cb248b72bddcf2a0f888c8a8f/frontend/src/components/tasks/partials/TaskGlanceTooltip.vue#L118). Since there is no escaping on either the server or client side, a malicious user can share a project, create a malicious task, and cause an XSS on hover.

### PoC
1. Create a project
2. Create a task with any description
3. Use the api to update the task with a description containing unescaped HTML (ex: `<img src=x onerror="alert(localStorage.getItem('token'))">`
4. Share the project with any permission level
5. Send malicious project to user and ask them to view task

### Impact
Any user on an instance can cause an XSS on another