deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-vw86-c94w-v3x4
Package: github.com/siyuan-note/siyuan/kernel (GO)
Severity: HIGH (CVSS 8.5)
CWE: CWE-24: Path Traversal: '../filedir'
Vulnerable versions: < 0.0.0[PII_REDACTED]5653-2f416e5253f1
Patched in: 3.6.40.0.0[PII_REDACTED]5653-2f416e5253f1

Summary: SiYuan: Publish Reader Path Traversal Delete via `removeUnusedAttributeView`

Details:
## Summary

The endpoint `/api/av/removeUnusedAttributeView` is vulnerable to a **path traversal (CWE-22)** that allows an attacker to delete arbitrary `.json` files on the server.

The issue arises because user-controlled input (`id`) is directly used in filesystem path construction without validation or restriction.

> Access to this endpoint (e.g., via a Reader-role or publish context) is considered a precondition and not part of the vulnerability. The root cause is unsafe path handling.

---

## Steps To Reproduce

1. Ensure the target instance has the publish service enabled (or any valid access to the endpoint).
2. Send the following request:

```http
POST /api/av/removeUnusedAttributeView HTTP/1.1
Host: <target>
Content-Type: application/json

{
  "id": "../../../conf/conf"
}
```

3. Observe that the request is accepted.
4. The server resolves the path outside the intended directory and deletes the target file.

---

## Impact

An attacker can delete arbitrary `.json` files within the workspace directory.

This may lead to:

* Deletion of global configuration files (e.g., `conf/conf.json`)
* Loss of user data and application state
* Corruption of workspace metadata
* Persistent application instability or forced recovery

This represents a **server-side arbitrary file deletion primitive**, which can have severe impact depending on the targeted files.

---

## Technical Details

The vulnerable code constructs file paths as follows:

```go
filepath.Join(util.DataDir, "storage", "av", id+".json")
```

Because `id` is not validated, attackers can inject path traversal sequences such as `../` to escape the intended directory.

### Example payloads

* `../local` → `data/storage/local.json`
* `../../storage/outline` → `data/storage/outline.json`
* `../../../conf/conf` → `conf/conf.json`

No validation or restriction is applied to:

* input format
* path normalization
* directory boundaries

---

## Root Cause

* Untrusted user input (`id`) is directly used in filesystem path construction
* No input validation or sanitization
* No enforcement that the resolved path stays within the intended directory

---

## Remediation

1. **Validate input strictly**

   * Only allow valid Attribute View IDs
   * Reject any input containing path traversal sequences

2. **Enforce directory boundaries**

```go
base := filepath.Join(util.DataDir, "storage", "av")
absPath := filepath.Join(base, id+".json")

if !util.IsSubPath(base, absPath) {
    return error
}
```

3. **Normalize paths before use**

   * Ensure canonical paths cannot escape the base directory

4. **Add additional logical checks**

   * Verify that the target object is valid and allowed to be deleted

---
GitHub Security Advisory: GHSA-99j8-wv67-4c72
Package: github.com/aiven/aiven-operator (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-269: Improper Privilege Management, CWE-441: Unintended Proxy or Intermediary ('Confused Deputy')
Vulnerable versions: >= 0.31.0, < 0.37.0
Patched in: 0.37.0

Summary: Aiven Operator has cross-namespace secret exfiltration via ClickhouseUser connInfoSecretSource

Details:
### Impact
A developer with create permission on ClickhouseUser CRDs in their own namespace can exfiltrate secrets from any other namespace — production database credentials, API keys, service tokens — with a single kubectl apply. The operator reads the victim's secret using its ClusterRole and writes the password into a new secret in the attacker's namespace.

The operator acts as a confused deputy: its ServiceAccount has cluster-wide secret read/write (aiven-operator-role ClusterRole), and it trusts user-supplied namespace values in spec.connInfoSecretSource.namespace without validation. No admission webhook enforces this boundary — the ServiceUser webhook returns nil, and no ClickhouseUser webhook exists.

### Patches

This vulnerability is resolved in version 0.37.0. We recommend all users update as soon as possible.

### Credits

Credits to Andrés Cruciani for finding and reporting the bug through our [bug bounty program](https://bugcrowd.com/aiven-mbb-og)
GitHub Security Advisory: GHSA-v479-vf79-mg83
Package: code.vikunja.io/api (GO)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-836: Use of Password Hash Instead of Password for Authentication, CWE-863: Incorrect Authorization
Vulnerable versions: < 2.3.0
Patched in: 2.3.0

Summary: Vikunja: Scoped API tokens with projects.background permission can delete project backgrounds

Details:
### Summary

Vikunja's scoped API token enforcement for custom project background routes is method-confused. A token with only `projects.background` can successfully delete a project background, while a token with only `projects.background_delete` is rejected.

This is a scoped-token authorization bypass.

### Details

I verified this locally on commit `c5450fb55f[PII_REDACTED]cbb3a[PII_REDACTED]a712e`.

Relevant code paths:
* `pkg/models/api_routes.go`
* `pkg/routes/routes.go`
* `pkg/modules/background/handler/background.go`

Route registration exposes separate permissions for the same path:
* `GET /api/v1/projects/:project/background` -> `projects.background`
* `DELETE /api/v1/projects/:project/background` -> `projects.background_delete`

At enforcement time, `CanDoAPIRoute()` falls back to the parent group and reconstructs the child permission from the path segments only. For the DELETE request, that becomes `background`, so the matcher accepts any token containing `projects.background` without re-checking the HTTP method or matching the stored route detail.

This matters because `RemoveProjectBackground()` is a real destructive operation:
* It checks project update rights.
* It deletes the background file if present.
* It clears the project's `BackgroundFileID`.

### PoC

1. Log in as a user who can update a project that already has a background.
2. Create an API token with only:
   `{"projects":["background"]}`
3. Send:
   `DELETE /api/v1/projects/<project_id>/background`
   `Authorization: Bearer <token>`
4. Observe that the request succeeds and the project background is removed.

**For comparison:**
1. Create an API token with only:
   `{"projects":["background_delete"]}`
2. Repeat the same DELETE request.
3. Observe that the request is rejected with `401 Unauthorized`.

I confirmed this locally with three validations:
1. `/api/v1/routes` advertises both `background` and `background_delete`.
2. The matcher unit test proves `CanDoAPIRoute()` accepts DELETE for `background`.
3. The webtest proves a real API token with only `background` successfully deletes the background.

### Impact

Scoped API tokens can exceed their intended capability. A token intended for project background access can delete project backgrounds, which weakens the trust model for automation and third-party integrations that rely on narrowly scoped tokens.

The attacker needs a valid API token created by a user who has update rights on the target project, but the token itself only needs the weaker `projects.background` permission.
GitHub Security Advisory: GHSA-w799-7525-rpr6
Package: github.com/casdoor/casdoor (GO)
Severity: LOW (CVSS 3.5)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 1.1000.0
Patched in: unpatched

Summary: Casdoor vulnerable to Stored XSS via Application formCss / formSideHtml

Details:
A security flaw has been discovered in Casdoor 2.356.0. This affects the function dangerouslySetInnerHTML. Performing a manipulation of the argument formCss/formCssMobile/formSideHtml results in cross site scripting. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.
GitHub Security Advisory: GHSA-mj24-pqx2-6788
Package: github.com/casdoor/casdoor (GO)
Severity: LOW (CVSS 4.3)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: <= 1.1000.0
Patched in: unpatched

Summary: Casdoor vulnerable to Open Redirect

Details:
A vulnerability was identified in Casdoor 2.356.0. Affected by this issue is some unknown functionality of the component OAuth Authorization Request Handler. Such manipulation of the argument redirect_uri leads to open redirect. It is possible to launch the attack remotely. The exploit is publicly available and might be used. The vendor was contacted early about this disclosure but did not respond in any way.
GitHub Security Advisory: GHSA-p8c7-hjc4-gwf8
Package: github.com/casdoor/casdoor (GO)
Severity: MODERATE (CVSS 4.7)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 1.1000.0
Patched in: unpatched

Summary: Casdoor vulnerable to SSRF via crafted Webhook URL

Details:
A weakness has been identified in Casdoor 2.356.0. This vulnerability affects unknown code of the component Webhook URL Handler. Executing a manipulation can lead to server-side request forgery. The attack can be launched remotely. The vendor was contacted early about this disclosure but did not respond in any way.
GitHub Security Advisory: GHSA-2vq4-854f-5c72
Package: code.vikunja.io/api (GO)
Severity: HIGH (CVSS 8.3)
CWE: CWE-269: Improper Privilege Management
Vulnerable versions: <= 2.2.2
Patched in: 2.3.0

Summary: Vikunja vulnerable to Privilege Escalation via Project Reparenting

Details:
## Summary

A user with Write-level access to a project can escalate their permissions to Admin by moving the project under a project they own. After reparenting, the recursive permission CTE resolves ownership of the new parent as Admin on the moved project. The attacker can then delete the project, manage shares, and remove other users' access.

## Details

The `CanUpdate` check at `pkg/models/project_permissions.go:139-148` only requires `CanWrite` on the new parent project when changing `parent_project_id`. However, Vikunja's permission model uses a recursive CTE that walks up the project hierarchy to compute permissions. Moving a project under a different parent changes the permission inheritance chain.

When a user has inherited Write access (from a parent project share) and reparents the child project under their own project tree, the CTE resolves their ownership of the new parent as Admin (permission level 2) on the moved project.

```go
if p.ParentProjectID != 0 && p.ParentProjectID != ol.ParentProjectID {
    newProject := &Project{ID: p.ParentProjectID}
    can, err := newProject.CanWrite(s, a)  // Only checks Write, not Admin
    if err != nil {
        return false, err
    }
    if !can {
        return false, ErrGenericForbidden{}
    }
}
```

## Proof of Concept

Tested on Vikunja v2.2.2.

```
1. victim creates "Parent Project" (id=3)
2. victim creates "Secret Child" (id=4) under Parent Project
3. victim shares Parent Project with attacker at Write level (permission=1)
   -> attacker inherits Write on Secret Child (no direct share)
4. attacker creates own "Attacker Root" project (id=5)
5. attacker verifies: DELETE /api/v1/projects/4 -> 403 Forbidden
6. attacker sends: POST /api/v1/projects/4 {"title":"Secret Child","parent_project_id":5}
   -> 200 OK (reparenting succeeds, only requires Write)
7. attacker sends: DELETE /api/v1/projects/4 -> 200 OK
   -> Project deleted. victim gets 404.
```

```python                                                                                                                                                                                                                                                                                                        
import requests                                                                                                                                                                                                                                                                                                    
                                                                                                                                                                                                                                                                                                                
TARGET = "http://localhost:3456"
GitHub Security Advisory: GHSA-hr2v-4r36-88hr
Package: helm.sh/helm/v3 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 3.20.1
Patched in: 3.20.2

Summary: Helm Chart extraction output directory collapse via `Chart.yaml` name dot-segment

Details:
Helm is a package manager for Charts for Kubernetes. In Helm versions <=3.20.1 and <=4.1.3, a specially crafted Chart will cause `helm pull --untar  [chart URL | repo/chartname]` to write the Chart's contents to the immediate output directory (as defaulted to the current working directory; or as given by the `--destination` and `--untardir` flags), rather than the expected output directory suffixed by the chart's name.

### Impact

The bug enables writing the Chart's contents (unpackaged/untar'ed) to the output directory `<output dir>/`, instead of the expected `<output dir>/<chart name>/`, potentially overwriting the contents of the targeted directory.

Note: a chart name containing POSIX dot-dot, or dot-dot and slashes (as if to refer to parent directories) do not resolve beyond the output directory as designed.

### Patches

This issue has been resolved in Helm v3.20.2 and v4.1.3

A Chart with an unexpected name (those specified to be "." or ".."), or a Chart name which results in a non-unique directory will be rejected.

### Workarounds

Ensure the the name of the Chart does not comprise/contain POSIX pathname special directory references ie. dot-dot ("..") or dot ("."). In addition, ensuring that the `pull --untar` flag (or equivalent SDK option) refers to a unique/empty output directory prevents chart extraction from inadvertently overwriting existing files within the specified directory.

### Credits

Oleh Konko
@1seal
GitHub Security Advisory: GHSA-hr2v-4r36-88hr
Package: helm.sh/helm/v4 (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 4.1.3
Patched in: 4.1.4

Summary: Helm Chart extraction output directory collapse via `Chart.yaml` name dot-segment

Details:
Helm is a package manager for Charts for Kubernetes. In Helm versions <=3.20.1 and <=4.1.3, a specially crafted Chart will cause `helm pull --untar  [chart URL | repo/chartname]` to write the Chart's contents to the immediate output directory (as defaulted to the current working directory; or as given by the `--destination` and `--untardir` flags), rather than the expected output directory suffixed by the chart's name.

### Impact

The bug enables writing the Chart's contents (unpackaged/untar'ed) to the output directory `<output dir>/`, instead of the expected `<output dir>/<chart name>/`, potentially overwriting the contents of the targeted directory.

Note: a chart name containing POSIX dot-dot, or dot-dot and slashes (as if to refer to parent directories) do not resolve beyond the output directory as designed.

### Patches

This issue has been resolved in Helm v3.20.2 and v4.1.3

A Chart with an unexpected name (those specified to be "." or ".."), or a Chart name which results in a non-unique directory will be rejected.

### Workarounds

Ensure the the name of the Chart does not comprise/contain POSIX pathname special directory references ie. dot-dot ("..") or dot ("."). In addition, ensuring that the `pull --untar` flag (or equivalent SDK option) refers to a unique/empty output directory prevents chart extraction from inadvertently overwriting existing files within the specified directory.

### Credits

Oleh Konko
@1seal
GitHub Security Advisory: GHSA-q5jf-9vfq-h4h7
Package: helm.sh/helm/v4 (GO)
Severity: HIGH (CVSS 7.8)
CWE: CWE-636: Not Failing Securely ('Failing Open')
Vulnerable versions: >= 4.0.0, <= 4.1.3
Patched in: 4.1.4

Summary: Helm's plugin verification fails open when .prov is missing, allowing unsigned plugin install

Details:
Helm is a package manager for Charts for Kubernetes. In Helm versions >=4.0.0 and <=4.1.3, Helm will install plugins missing provenance (`.prov` file) when signature verification is required.

### Impact

The bug allows plugin authors to omit provenance (signing) data from plugins, bypassing plugin signature verification upon plugin install/update.

Notably, plugin hooks will be executed as designed on the installed plugin, enabling a malicious plugin to execute arbitrary code.

### Patches

This issue has been patched in Helm v4.1.4

Installing/updating a plugin with missing provenance will error if signature verification is required.

### Workarounds

Users may manually validate that a plugin archive is not missing provenance data (`.prov` file) before installation.
GitHub Security Advisory: GHSA-vmx8-mqv2-9gmg
Package: helm.sh/helm/v4 (GO)
Severity: HIGH (CVSS 8.6)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 4.0.0, <= 4.1.3
Patched in: 4.1.4

Summary: Helm has a path traversal in plugin metadata version enables arbitrary file write outside Helm plugin directory

Details:
Helm is a package manager for Charts for Kubernetes. In Helm versions >=4.0.0 and <=4.1.3, a specially crafted Helm plugin, when installed or updated, will cause Helm to write the contents of the plugin to an arbitrary filesystem location.

### Impact

A Helm user who installs or updates a plugin that is specially crafted can cause Helm to attempt to write the content of the affected plugin to an arbitrary location on the user's filesystem. Impacted users risk potentially overwriting user and system files which may further compromise the integrity of a system.

### Patches

This issue has been patched in Helm v4.1.4

Installing/updating a plugin with a non-SemVer version (which excludes path traversal patterns) will result in an error.

### Workarounds

Validate that the `plugin.yaml` of the Helm plugin does not include a `version:` field containing POSIX dot-dot path separators ie. "`/../`".
GitHub Security Advisory: GHSA-hqxq-hwqf-wg83
Package: github.com/monetr/monetr (GO)
Severity: MODERATE (CVSS 5.7)
CWE: CWE-285: Improper Authorization
Vulnerable versions: <= 1.12.2
Patched in: 1.12.3

Summary: monetr: Protected Transactions Deletable via PUT

Details:
### Summary
A transaction integrity flaw allows an authenticated tenant user to soft-delete synced non-manual transactions through the transaction update endpoint, despite the application explicitly blocking deletion of those transactions via the normal `DELETE` path. This bypass undermines the intended protection for imported transaction records and allows protected transactions to be hidden from normal views.

### Details
The issue affects the transaction update path for synced transactions associated with non-manual links. The intended policy is clearly enforced in the `DELETE` handler: deletion of synced transactions for non-manual links is rejected with an error indicating that such transactions cannot be deleted.

However, the `PUT` update path still accepts a client-controlled full `Transaction` object and persists fields that should be server-managed, including `deletedAt`. The update logic appears to restrict only selected fields, which leaves `deletedAt` attacker-controllable.

Verified behavior on the same synced transaction showed:

- `DELETE` was denied with the expected protection error for non-manual links
- `PUT` with a user-supplied `deletedAt` value succeeded and returned `200 OK`
- a subsequent transaction list no longer showed the transaction
- `GET` by transaction ID still returned the record with `deletedAt` populated

This demonstrates a policy bypass: although the server explicitly defines synced transactions on non-manual links as non-deletable through the dedicated delete route, the same outcome can still be achieved through the update route by setting the soft-delete field directly.

The vulnerability is therefore not a simple UI inconsistency. It is a server-side authorization and integrity flaw caused by trusting a client-supplied full transaction object and failing to protect sensitive server-managed fields from modification.

### PoC
The issue can be reproduced by identifying a synced transaction on a non-manual link, confirming that the normal `DELETE` route rejects deletion, then submitting an update request that sets the transaction’s `deletedAt` field. The transaction will then disappear from normal listing views even though direct retrieval still shows the record as soft-deleted.

### Impact
- **Type:** Authorization bypass / integrity violation
- **Who is impacted:** Authenticated tenant users and any deployment relying on synced transaction immutability for non-manual links
- **Security impact:** Attackers can hide or effectively delete protected imported transactions that should not be deletable, compromising transaction history, bookkeeping integrity, and trust in audit-relevant server-managed fields
- **Attack preconditions:** The attacker must be authenticated and able to access a synced transaction within their own tenant/account scope
GitHub Security Advisory: GHSA-92mm-2pjq-r785
Package: github.com/hashicorp/go-getter (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 1.8.6
Patched in: 1.8.6

Summary: HashiCorp's go-getter library may allow arbitrary file reads

Details:
HashiCorp's go-getter library up to v1.8.5 may allow arbitrary file reads on the file system during certain git operations through a maliciously crafted URL. This is fixed in go-getter v1.8.6. This vulnerability does not affect the go-getter/v2 branch and package.
GitHub Security Advisory: GHSA-68m9-983m-f3v5
Package: github.com/openfga/openfga (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 0.1.4, <= 1.13.1
Patched in: 1.14.0

Summary: OpenFGA: Unauthenticated playground endpoint discloses preshared API key in HTML response

Details:
### Description
When OpenFGA is configured to use preshared-key authentication with the built-in playground enabled, the local server includes the preshared API key in the HTML response of the /playground endpoint. The /playground endpoint is enabled by default and does not require authentication. It is intended for local development and debugging and is not designed to be exposed to production environments.


### Am I Affected?
You are affected if you meet each of the following preconditions:
* You are running OpenFGA with --authn-method preshared, and
* The playground is enabled, and
* The playground endpoint is accessible beyond localhost or trusted networks.

### Fix
Upgrade to OpenFGA v1.14.0, or disable the playground by running `./openfga run --playground-enabled=false.`