deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-gx3x-vq4p-mhhv
Package: github.com/cert-manager/cert-manager (GO)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-129: Improper Validation of Array Index, CWE-704: Incorrect Type Conversion or Cast
Vulnerable versions: >= 1.18.0, < 1.18.5
Patched in: 1.18.5

Summary: cert-manager-controller DoS via Specially Crafted DNS Response

Details:
### Impact

The cert-manager-controller performs DNS lookups during ACME DNS-01 processing (for zone discovery and propagation self-checks). By default, these lookups use standard unencrypted DNS.

An attacker who can intercept and modify DNS traffic from the cert-manager-controller pod can insert a crafted entry into cert-manager's DNS cache. Accessing this entry will trigger a panic, resulting in Denial of Service (DoS) of the cert-manager controller.

The issue can also be exploited if the authoritative DNS server for the domain being validated is controlled by a malicious actor.

### Patches

The vulnerability was introduced in cert-manager v1.18.0 and has been patched in cert-manager v1.19.3 and v1.18.5, which are the supported minor releases at the time of publishing.

cert-manager versions prior to v1.18.0 are unaffected.

### Workarounds

- Using DNS-over-HTTPS reduces the risk of DNS traffic being intercepted and modified.
    - Note that DNS-over-HTTPS does *not* prevent the risk of an attacker-controlled authoritative DNS server.

### Resources

- Fix for cert-manager 1.18: https://github.com/cert-manager/cert-manager/pull/8467
- Fix for cert-manager 1.19: https://github.com/cert-manager/cert-manager/pull/8468
- Fix for master branch: https://github.com/cert-manager/cert-manager/pull/8469

### Credits

Huge thanks to Oleh Konko (@1seal) for reporting the issue, providing a detailed PoC and an initial patch!
GitHub Security Advisory: GHSA-grh9-37g7-53mj
Package: github.com/h44z/wg-portal (GO)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: <= 2.1.1
Patched in: 2.1.2

Summary: WireGuard Portal v2 has Open Redirect Vulnerability in OAuth Authentication Flow

Details:
### Summary
An Open Redirect vulnerability exists in the OAuth authentication flow that allows attackers to redirect users to external malicious websites after authentication. The vulnerability is caused by insufficient validation of the return parameter in the OAuth login initialization endpoint.

### Patches
The problem was fixed in the latest release, v2.1.2. The [docker images](https://hub.docker.com/r/wgportal/wg-portal) for the tag 'latest' built from the master branch also include the fix.
GitHub Security Advisory: GHSA-gwch-7m8v-7544
Package: github.com/bpg/terraform-provider-proxmox (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-1188: Initialization of a Resource with an Insecure Default
Vulnerable versions: < 0.93.1
Patched in: 0.93.1

Summary: terraform-provider-proxmox has insecure sudo recommendation in the documentation

Details:
> Note: It is uncertain whether this constitutes a vulnerability or should be filed as an issue instead.

### Summary

In the SSH configuration documentation, the sudoer line that was suggested can be escalated to edit any files in the system.

### Details

The following line were suggested for addition in the sudoers file:

```bash
terraform ALL=(root) NOPASSWD: /usr/bin/tee /var/lib/vz/*
```

But this is highly insecure as  the folder can be escaped using `../` and any files can be edited on the system.

### PoC

Using a `terraform` user with the previously mentioned line in the `/etc/sudoers` file, a `/etc/sudoers.d/sudo` file can be added using this command:

`echo "ALL=(ALL) NOPASSWD:ALL" | tee /var/lib/vz/../../../etc/sudoers.d/sudo`

This grants access to the full root of the node.

### Impact

This breaches the access limits of the Terraform user.

### Suggested workaround

Use a strict regex on the command to allow only the names that should be pushed by this user.

Example for cloudinit yaml files:

```bash
terraform ALL=(root) NOPASSWD: /usr/bin/tee /var/lib/vz/snippets/[A-Za-z0-9-]*\\.yaml
```
GitHub Security Advisory: GHSA-mc24-7m59-4q5p
Package: github.com/rancher/rancher (GO)
Severity: HIGH (CVSS 8.3)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 2.10.0, < 2.10.11
Patched in: 2.10.11

Summary: Rancher CLI skips TLS verification on Rancher CLI login command

Details:
### Impact
A vulnerability has been identified within Rancher Manager, where using self-signed CA certificates and passing the `-skip-verify` flag to the Rancher CLI login command without also passing the `–cacert` flag results in the CLI attempting to fetch CA certificates stored in Rancher’s setting cacerts. This does not apply to any other commands and only applies to the login command if the `–cacert` flag was not provided.

An attacker with network-level access between the Rancher CLI and Rancher Manager could interfere with the TLS handshake to return a CA they control, despite the use of the `--skip-verify` flag. This may be abused to bypass TLS as a security control. Attackers can also see basic authentication headers in a Man-in-the-Middle due to the lack of TLS enforcement.

Please consult the associated [MITRE ATT&CK - Technique - Man-in-the-Middle](https://attack.mitre.org/techniques/T1557/) for further information about this category of attack.

### Patches
This vulnerability is addressed by removing the ability to fetch CA certificates stored in Rancher’s setting cacerts when using the login command. Whenever required, for example when using self-signed certificates, CA certificates have to be explicitly passed with the –cacert flag.

Patched versions of Rancher include releases `v2.13.2`, `v2.12.6`, `v2.11.10`, and `v2.10.11`.

### Workarounds
If a projecct can't upgrade to a fixed version, please make sure whenever required, for example when using self-signed certificates, to always explicitly pass CA certificates with the –cacert flag when using the login command.


### References
If there are 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 [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
- Verify with the [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).

Note: Rancher versions beyond 2.3.0-alpha5 are no longer supported at pkg.go.dev, follow [Rancher installation instructions for newer versions](https://ranchermanager.docs.rancher.com/v2.13/getting-started/installation-and-upgrade).
GitHub Security Advisory: GHSA-mc24-7m59-4q5p
Package: github.com/rancher/rancher (GO)
Severity: HIGH (CVSS 8.3)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 2.11.0, < 2.11.10
Patched in: 2.11.10

Summary: Rancher CLI skips TLS verification on Rancher CLI login command

Details:
### Impact
A vulnerability has been identified within Rancher Manager, where using self-signed CA certificates and passing the `-skip-verify` flag to the Rancher CLI login command without also passing the `–cacert` flag results in the CLI attempting to fetch CA certificates stored in Rancher’s setting cacerts. This does not apply to any other commands and only applies to the login command if the `–cacert` flag was not provided.

An attacker with network-level access between the Rancher CLI and Rancher Manager could interfere with the TLS handshake to return a CA they control, despite the use of the `--skip-verify` flag. This may be abused to bypass TLS as a security control. Attackers can also see basic authentication headers in a Man-in-the-Middle due to the lack of TLS enforcement.

Please consult the associated [MITRE ATT&CK - Technique - Man-in-the-Middle](https://attack.mitre.org/techniques/T1557/) for further information about this category of attack.

### Patches
This vulnerability is addressed by removing the ability to fetch CA certificates stored in Rancher’s setting cacerts when using the login command. Whenever required, for example when using self-signed certificates, CA certificates have to be explicitly passed with the –cacert flag.

Patched versions of Rancher include releases `v2.13.2`, `v2.12.6`, `v2.11.10`, and `v2.10.11`.

### Workarounds
If a projecct can't upgrade to a fixed version, please make sure whenever required, for example when using self-signed certificates, to always explicitly pass CA certificates with the –cacert flag when using the login command.


### References
If there are 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 [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
- Verify with the [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).

Note: Rancher versions beyond 2.3.0-alpha5 are no longer supported at pkg.go.dev, follow [Rancher installation instructions for newer versions](https://ranchermanager.docs.rancher.com/v2.13/getting-started/installation-and-upgrade).
GitHub Security Advisory: GHSA-mc24-7m59-4q5p
Package: github.com/rancher/rancher (GO)
Severity: HIGH (CVSS 8.3)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 2.12.0, < 2.12.6
Patched in: 2.12.6

Summary: Rancher CLI skips TLS verification on Rancher CLI login command

Details:
### Impact
A vulnerability has been identified within Rancher Manager, where using self-signed CA certificates and passing the `-skip-verify` flag to the Rancher CLI login command without also passing the `–cacert` flag results in the CLI attempting to fetch CA certificates stored in Rancher’s setting cacerts. This does not apply to any other commands and only applies to the login command if the `–cacert` flag was not provided.

An attacker with network-level access between the Rancher CLI and Rancher Manager could interfere with the TLS handshake to return a CA they control, despite the use of the `--skip-verify` flag. This may be abused to bypass TLS as a security control. Attackers can also see basic authentication headers in a Man-in-the-Middle due to the lack of TLS enforcement.

Please consult the associated [MITRE ATT&CK - Technique - Man-in-the-Middle](https://attack.mitre.org/techniques/T1557/) for further information about this category of attack.

### Patches
This vulnerability is addressed by removing the ability to fetch CA certificates stored in Rancher’s setting cacerts when using the login command. Whenever required, for example when using self-signed certificates, CA certificates have to be explicitly passed with the –cacert flag.

Patched versions of Rancher include releases `v2.13.2`, `v2.12.6`, `v2.11.10`, and `v2.10.11`.

### Workarounds
If a projecct can't upgrade to a fixed version, please make sure whenever required, for example when using self-signed certificates, to always explicitly pass CA certificates with the –cacert flag when using the login command.


### References
If there are 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 [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
- Verify with the [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).

Note: Rancher versions beyond 2.3.0-alpha5 are no longer supported at pkg.go.dev, follow [Rancher installation instructions for newer versions](https://ranchermanager.docs.rancher.com/v2.13/getting-started/installation-and-upgrade).
GitHub Security Advisory: GHSA-mc24-7m59-4q5p
Package: github.com/rancher/rancher (GO)
Severity: HIGH (CVSS 8.3)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 2.13.0, < 2.13.2
Patched in: 2.13.2

Summary: Rancher CLI skips TLS verification on Rancher CLI login command

Details:
### Impact
A vulnerability has been identified within Rancher Manager, where using self-signed CA certificates and passing the `-skip-verify` flag to the Rancher CLI login command without also passing the `–cacert` flag results in the CLI attempting to fetch CA certificates stored in Rancher’s setting cacerts. This does not apply to any other commands and only applies to the login command if the `–cacert` flag was not provided.

An attacker with network-level access between the Rancher CLI and Rancher Manager could interfere with the TLS handshake to return a CA they control, despite the use of the `--skip-verify` flag. This may be abused to bypass TLS as a security control. Attackers can also see basic authentication headers in a Man-in-the-Middle due to the lack of TLS enforcement.

Please consult the associated [MITRE ATT&CK - Technique - Man-in-the-Middle](https://attack.mitre.org/techniques/T1557/) for further information about this category of attack.

### Patches
This vulnerability is addressed by removing the ability to fetch CA certificates stored in Rancher’s setting cacerts when using the login command. Whenever required, for example when using self-signed certificates, CA certificates have to be explicitly passed with the –cacert flag.

Patched versions of Rancher include releases `v2.13.2`, `v2.12.6`, `v2.11.10`, and `v2.10.11`.

### Workarounds
If a projecct can't upgrade to a fixed version, please make sure whenever required, for example when using self-signed certificates, to always explicitly pass CA certificates with the –cacert flag when using the login command.


### References
If there are 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 [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
- Verify with the [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).

Note: Rancher versions beyond 2.3.0-alpha5 are no longer supported at pkg.go.dev, follow [Rancher installation instructions for newer versions](https://ranchermanager.docs.rancher.com/v2.13/getting-started/installation-and-upgrade).
GitHub Security Advisory: GHSA-mc24-7m59-4q5p
Package: github.com/rancher/rancher (GO)
Severity: HIGH (CVSS 8.3)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: < 0.0.0[PII_REDACTED]2249-bb0625fd1896
Patched in: 0.0.0[PII_REDACTED]2249-bb0625fd1896

Summary: Rancher CLI skips TLS verification on Rancher CLI login command

Details:
### Impact
A vulnerability has been identified within Rancher Manager, where using self-signed CA certificates and passing the `-skip-verify` flag to the Rancher CLI login command without also passing the `–cacert` flag results in the CLI attempting to fetch CA certificates stored in Rancher’s setting cacerts. This does not apply to any other commands and only applies to the login command if the `–cacert` flag was not provided.

An attacker with network-level access between the Rancher CLI and Rancher Manager could interfere with the TLS handshake to return a CA they control, despite the use of the `--skip-verify` flag. This may be abused to bypass TLS as a security control. Attackers can also see basic authentication headers in a Man-in-the-Middle due to the lack of TLS enforcement.

Please consult the associated [MITRE ATT&CK - Technique - Man-in-the-Middle](https://attack.mitre.org/techniques/T1557/) for further information about this category of attack.

### Patches
This vulnerability is addressed by removing the ability to fetch CA certificates stored in Rancher’s setting cacerts when using the login command. Whenever required, for example when using self-signed certificates, CA certificates have to be explicitly passed with the –cacert flag.

Patched versions of Rancher include releases `v2.13.2`, `v2.12.6`, `v2.11.10`, and `v2.10.11`.

### Workarounds
If a projecct can't upgrade to a fixed version, please make sure whenever required, for example when using self-signed certificates, to always explicitly pass CA certificates with the –cacert flag when using the login command.


### References
If there are 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 [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
- Verify with the [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).

Note: Rancher versions beyond 2.3.0-alpha5 are no longer supported at pkg.go.dev, follow [Rancher installation instructions for newer versions](https://ranchermanager.docs.rancher.com/v2.13/getting-started/installation-and-upgrade).
GitHub Security Advisory: GHSA-73jg-4qh6-3f4g
Package: github.com/beam-cloud/beta9 (GO)
Severity: MODERATE (CVSS 6.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: <= 0.0.0[PII_REDACTED]2221-c1cd75e813cf
Patched in: unpatched

Summary: Beam Exposes sensitive information via joinCleanPath function

Details:
Directory Traversal vulnerability in Beam beta9 v.0.1.552 allows a remote attacker to obtain sensitive information via the joinCleanPath function
GitHub Security Advisory: GHSA-923j-vrcg-hxwh
Package: github.com/chainguard-dev/malcontent (GO)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-683: Function Call With Incorrect Order of Arguments
Vulnerable versions: >= 1.8.0, < 1.20.3
Patched in: 1.20.3

Summary: malcontent vulnerable to symlink Path Traversal via handleSymlink argument confusion in archive extraction

Details:
malcontent could be made to create symlinks outside the intended extraction directory when scanning a specially crafted tar or deb archive. The `handleSymlink` function received arguments in the wrong order, causing the symlink target to be used as the symlink location. Additionally, symlink targets were not validated to ensure they resolved within the extraction directory.

**Fixes:**
- [Swap handleSymlink arguments; validate symlink location](https://github.com/chainguard-dev/malcontent/commit/a7dd8a5328ddbaf[PII_REDACTED]13efa7591e00017)
- [Validate symlink targets resolve within extraction directory](https://github.com/chainguard-dev/malcontent/commit/259fca5abc004f3ab238895463ef280a87f30e96)

**Acknowledgements**

Thank you to Oleh Konko from [1seal](https://1seal.org/) for discovering and reporting this issue.
GitHub Security Advisory: GHSA-9m43-p3cx-w8j5
Package: github.com/chainguard-dev/malcontent (GO)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-522: Insufficiently Protected Credentials
Vulnerable versions: >= 0.10.0, < 1.20.3
Patched in: 1.20.3

Summary: malcontent OCI image pull credential exfiltration via malicious registry token realm

Details:
Malcontent could be made to expose Docker registry credentials if it scanned a specially crafted OCI image reference. Malcontent uses [google/go-containerregistry](https://github.com/google/go-containerregistry) for OCI image pulls, which by default uses the Docker credential keychain. A malicious registry could return a `WWW-Authenticate` header redirecting token authentication to an attacker-controlled endpoint, causing credentials to be sent to that endpoint.

**Fix:** [Default to anonymous auth for OCI pulls](https://github.com/chainguard-dev/malcontent/commit/538ed00cdc639d687a4bd1e843a2be0428a3b3e7)

**Acknowledgements**

Thank you to Oleh Konko from [1seal](https://1seal.org/) for discovering and reporting this issue.
GitHub Security Advisory: GHSA-j477-6vpg-6c8x
Package: github.com/juju/juju (GO)
Severity: LOW (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: <= 0.0.0[PII_REDACTED]0037-9b1a0e53a4a4
Patched in: unpatched

Summary: Juju has broken CMR authorization

Details:
### Impact

Cross-model Relation authorization is broken and has a potential security vulnerability. If the controller does not have the root key to verify the macaroon (or if the macaroon has expired), an unvalidated and therefore untrusted macaroon is used to extract declared caveats. Facts from these caveats are then blindly used to mint a new macaroon that becomes valid.

### Scenario

A user knows that user X has access to offer Y. The user mints a macaroon stating that user X has access to offer Y and sends it to the controller in a request. The controller fails to verify the macaroon because it lacks the root key and mints a new macaroon requiring proof that user X has access to offer Y. Since user X does have access and the discharge endpoint does not require authentication, the controller returns the new macaroon. The user can then use the returned macaroon to consume the offer as user X.

### Patches

N/A

### Workarounds

A previous proposal via [this PR](https://github.com/juju/juju/pull/21062) addresses the issue but would break model migrations since macaroon root keys are not included in model descriptions. Additionally, root keys are not model-scoped, making it unclear which keys to transfer during migration.
GitHub Security Advisory: GHSA-vfjc-2qcw-j95j
Package: github.com/moby/moby (GO)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 17.12.0-ce
Patched in: 17.12.0-ce

Summary: Docker Moby /proc/scsi Path Exposure Allows Host Data Loss (SCSI MICDROP)

Details:
The DefaultLinuxSpec function in oci/defaults.go in Docker Moby through 17.03.2-ce does not block /proc/scsi pathnames, which allows attackers to trigger data loss (when certain older Linux kernels are used) by leveraging Docker container access to write a "scsi remove-single-device" line to /proc/scsi/scsi, aka SCSI MICDROP.
GitHub Security Advisory: GHSA-f72r-2h5j-7639
Package: github.com/siyuan-note/siyuan/kernel (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), CWE-178: Improper Handling of Case Sensitivity, CWE-426: Untrusted Search Path
Vulnerable versions: <= 0.0.0[PII_REDACTED]4835-d5d10dd41b0c
Patched in: unpatched

Summary: SiYuan File Read API Case Sensitivity Bypass can Lead to Path Traversal

Details:
# File Read Interface Case Bypass Vulnerability
## Vulnerability Name
File Read Interface Case Bypass Vulnerability

## Overview
The `/api/file/getFile` endpoint uses **case-sensitive string equality checks** to block access to sensitive files.
On case-insensitive file systems such as **Windows**, attackers can bypass restrictions using mixed-case paths
and read protected configuration files.

## Impact
- Read sensitive information in configuration files (e.g., access codes, API Tokens, sync configurations, etc.).
- Remotely exploitable directly when the service is published without authentication.

## Trigger Conditions
- Running on a **case-insensitive file system**.
- The caller can access `/api/file/getFile` (via CheckAuth or Token injection in published services).

## PoC (Generic Example)
After enabling publication:

**Request:**
```http
POST /api/file/getFile
Content-Type: application/json

{"path":"cOnf/conf.json"}
```

**Expected Result:**
- Successfully return the content of the configuration file.

## Root Cause
Path comparison uses strict case-sensitive string matching, without case normalization or identical file validation.

## Fix Recommendations
- Normalize path casing before comparison (Windows/macOS).
- Use file-level comparison methods such as `os.SameFile`.
- Apply blacklist validation on sensitive paths **after case normalization**.

## Notes
- Environment identifiers and sensitive information have been removed.

## Solution Commit
`399a38893e8719968ea2511e177bb53e09973fa6`