deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-25rw-g6ff-fmg8
Package: github.com/zitadel/zitadel/v2 (GO)
Severity: HIGH (CVSS 8.2)
CWE: CWE-287: Improper Authentication
Vulnerable versions: >= 4.0.0, <= 4.12.0
Patched in: 4.12.1

Summary: ZITADEL: Login V2 UI Policy Bypass Allows Unauthorized Self-Registration and Authentication

Details:
### Summary

A vulnerability in Zitadel's login V2 UI allowed users to bypass login behavior and security policies and self-register new accounts or sign in using password even if corresponding options were disabled in their organizaton.

### Impact

Zitadel enables administrators to configure their organization’s login behavior and security policies. As part of this functionality, they can disable user self-registration, enforce passwordless logins only, and more.

Due to improper enforcement an attacker could send direct HTTP requests to the login UI and create accounts in organizations that have disabled user self-registration, and gain unauthorized access to the system.
The same attack vector could be used to authenticate for example using username and password even when this login method was disabled.

### Affected Versions

Systems running one of the following versions are affected:
- **4.x**: `4.0.0` through `4.12.0` (including RC versions)

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by enforcing the policies on the logiin UI server.

4.x: Upgrade to >=[4.12.1](https://github.com/zitadel/zitadel/releases/tag/v4.12.1)

### Workarounds

The recommended solution is to upgrade to a patched version.

### Questions

If there are any questions or comments about this advisory, please send an email to [security@zitadel.com](mailto:security@zitadel.com)

### Credits 

ZITADEL extends thanks once again to Amit Laish from GE Vernova for finding and reporting the vulnerability.
GitHub Security Advisory: GHSA-pr34-2v5x-6qjq
Package: github.com/zitadel/zitadel/v2 (GO)
Severity: CRITICAL (CVSS 9.3)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.0.0, < 4.12.0
Patched in: 4.12.0

Summary: ZITADEL has 1-Click Account Takeover via XSS in /saml-post Endpoint

Details:
### Summary

A vulnerability was discovered in Zitadel's login V2 interface that allowed a possible account takeover.

### Impact

Zitadel exposes an HTTP endpoint named /saml-post. This endpoint is used for handling requests to SAML IdPs and accepts two HTTP GET parameters: url and id. When these parameters are supplied, users’ browsers auto-submit an HTTP POST request to the provided url parameter.
 
The endpoint insecurely redirects users using the provided url GET parameter. As a result, by specifying a javascript: scheme, malicious JS code could be executed on Zitadel users’ browsers. 

The endpoint also reflects user-supplied input in the server response, without HTML-encoding it. As a result, it is possible to inject arbitrary HTML code, which again leads to malicious JS code execution in the Zitadel users’ browsers.

An unauthenticated remote attacker can exploit these XSS vulnerabilities, and thus, execute malicious JavaScript code on behalf of Zitadel users. By doing so, such an attacker could reset the password of their victims, and take over their accounts.

It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.

### Affected Versions

Systems running one of the following versions are affected:
- **4.x**: `4.0.0` through `4.11.1` (including RC versions)
 
Important Note: Although this /saml-post endpoint is used when Zitadel is integrated with a SAML Identity Provider (IdP), the vulnerability in this finding does not require Zitadel to be configured with a SAML IdP. Consequently, Zitadel is vulnerable in its default, out-of-the-box configuration.

### Patches

The vulnerability has been addressed in the latest releases. The patch reworked the integration of SAML IdPs and the /saml-post endpoint no longer exists. Additionally, the page to change the password, now always requires the user's current password regardless of the state of the authenticated session.

4.x: Upgrade to >= [4.12.0](https://github.com/zitadel/zitadel/releases/tag/v4.12.0)

### Workarounds

The recommended solution is to upgrade to a patched version. If an upgrade is not possible and no SAML IdP integration is needed, a WAF or reverse proxy rule can be deployed to prevent access to the endpoint.

### Questions

If there are any questions or comments about this advisory, please email them to [security@zitadel.com](mailto:security@zitadel.com)

### Credits

ZITADEL extends thanks once again to Amit Laish from GE Vernova for finding and reporting the vulnerability.
GitHub Security Advisory: GHSA-pr34-2v5x-6qjq
Package: github.com/zitadel/zitadel (GO)
Severity: CRITICAL (CVSS 9.3)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.0.0, < 4.12.0
Patched in: 4.12.0

Summary: ZITADEL has 1-Click Account Takeover via XSS in /saml-post Endpoint

Details:
### Summary

A vulnerability was discovered in Zitadel's login V2 interface that allowed a possible account takeover.

### Impact

Zitadel exposes an HTTP endpoint named /saml-post. This endpoint is used for handling requests to SAML IdPs and accepts two HTTP GET parameters: url and id. When these parameters are supplied, users’ browsers auto-submit an HTTP POST request to the provided url parameter.
 
The endpoint insecurely redirects users using the provided url GET parameter. As a result, by specifying a javascript: scheme, malicious JS code could be executed on Zitadel users’ browsers. 

The endpoint also reflects user-supplied input in the server response, without HTML-encoding it. As a result, it is possible to inject arbitrary HTML code, which again leads to malicious JS code execution in the Zitadel users’ browsers.

An unauthenticated remote attacker can exploit these XSS vulnerabilities, and thus, execute malicious JavaScript code on behalf of Zitadel users. By doing so, such an attacker could reset the password of their victims, and take over their accounts.

It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.

### Affected Versions

Systems running one of the following versions are affected:
- **4.x**: `4.0.0` through `4.11.1` (including RC versions)
 
Important Note: Although this /saml-post endpoint is used when Zitadel is integrated with a SAML Identity Provider (IdP), the vulnerability in this finding does not require Zitadel to be configured with a SAML IdP. Consequently, Zitadel is vulnerable in its default, out-of-the-box configuration.

### Patches

The vulnerability has been addressed in the latest releases. The patch reworked the integration of SAML IdPs and the /saml-post endpoint no longer exists. Additionally, the page to change the password, now always requires the user's current password regardless of the state of the authenticated session.

4.x: Upgrade to >= [4.12.0](https://github.com/zitadel/zitadel/releases/tag/v4.12.0)

### Workarounds

The recommended solution is to upgrade to a patched version. If an upgrade is not possible and no SAML IdP integration is needed, a WAF or reverse proxy rule can be deployed to prevent access to the endpoint.

### Questions

If there are any questions or comments about this advisory, please email them to [security@zitadel.com](mailto:security@zitadel.com)

### Credits

ZITADEL extends thanks once again to Amit Laish from GE Vernova for finding and reporting the vulnerability.
GitHub Security Advisory: GHSA-rhr9-hgcm-x289
Package: github.com/gravitl/netmaker (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-404: Improper Resource Shutdown or Release
Vulnerable versions: < 1.2.0
Patched in: 1.2.0

Summary: Netmaker Vulnerable to Denial of Service via Server Shutdown Endpoint

Details:
The /api/server/shutdown endpoint allows termination of the Netmaker server process via syscall.SIGINT. This allows any user to repeatedly shut down the server, causing cyclic denial of service with approximately 3-second restart intervals.
GitHub Security Advisory: GHSA-6865-qjcf-286f
Package: github.com/siyuan-note/siyuan/kernel (GO)
Severity: CRITICAL (CVSS 9.3)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 0.0.0[PII_REDACTED]4809-d68bd5a79391
Patched in: 0.0.0[PII_REDACTED]4809-d68bd5a79391

Summary: SiYuan: Unauthenticated Reflected XSS via SVG Injection in /api/icon/getDynamicIcon Endpoint

Details:
### Summary
An unauthenticated reflected XSS vulnerability exists in the dynamic icon API endpoint:

- `GET /api/icon/getDynamicIcon`

When `type=8`, attacker-controlled `content` is embedded into SVG output without escaping. Because the endpoint is unauthenticated and returns `image/svg+xml`, a crafted URL can inject executable SVG/HTML event handlers (for example `onerror`) and run JavaScript in the SiYuan web origin.

This can be chained to perform authenticated API actions and exfiltrate sensitive data when a logged-in user opens the malicious link.

### Details
The issue is caused by unsafe output construction and incomplete sanitization:

1. **Endpoint is exposed without auth middleware**
   - Source: https://github.com/siyuan-note/siyuan/blob/master/kernel/api/router.go#L27-L37
   - `GET /api/icon/getDynamicIcon` is registered in the unauthenticated section.

2. **User input is inserted into SVG via string formatting**
   - Source: https://github.com/siyuan-note/siyuan/blob/master/kernel/api/icon.go#L115-L175
   - Source: https://github.com/siyuan-note/siyuan/blob/master/kernel/api/icon.go#L537-L585
   - In `generateTypeEightSVG`, `%s` directly injects `content` into `<text>...</text>` without XML/HTML escaping.

3. **Sanitizer only removes `<script>` tags**
   - Source: https://github.com/siyuan-note/siyuan/blob/master/kernel/util/misc.go#L235-L281
   - `RemoveScriptsInSVG` removes `<script>` nodes, but does not remove dangerous attributes (`onerror`, `onload`, etc.) or unsafe elements.

As a result, payloads such as `</text><image ... onerror=...><text>` survive and execute.

### PoC

#### Minimal browser execution PoC
Open this URL in a browser:

```http
GET /api/icon/getDynamicIcon?type=8&content=%3C%2Ftext%3E%3Cimage%20href%3Dx%20onerror%3Dalert(document.domain)%3E%3C%2Fimage%3E%3Ctext%3E
```

Example full URL:

```text
http://127.0.0.1:6806/api/icon/getDynamicIcon?type=8&content=%3C%2Ftext%3E%3Cimage%20href%3Dx%20onerror%3Dalert(document.domain)%3E%3C%2Fimage%3E%3Ctext%3E
```

Expected result:

- JavaScript executes (`alert(document.domain)`), confirming reflected XSS.

#### Authenticated impact demonstration
If a victim is authenticated in the same browser session, JavaScript running in origin can call privileged APIs and exfiltrate returned data.

### Impact
This is a reflected XSS in an unauthenticated endpoint, with realistic account/data compromise impact:

- Arbitrary JavaScript execution in SiYuan web origin.
- Authenticated action abuse via same-origin API calls.
- Sensitive data exposure (notes/config/API responses) from victim context.
- Potential chained server-impact actions depending on victim privileges and deployment mode.
GitHub Security Advisory: GHSA-jqwg-75qf-vmf9
Package: github.com/siyuan-note/siyuan/kernel (GO)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'), CWE-862: Missing Authorization
Vulnerable versions: <= 0.0.0[PII_REDACTED]0602-4ba64580c29c
Patched in: unpatched

Summary: SiYuan's direct SQL Query API accessible to Reader-level users enables unauthorized database access

Details:
### Summary
/api/query/sql allows users to run SQL directly, but it only checks basic auth, not admin rights, any logged-in user, even readers, can run any  SQL query on the database.

### Details

The vulnerable endpoint is in kernel/api/sql.go 

```go
func SQL(c *gin.Context) {
    ret := gulu.Ret.NewResult()
    defer c.JSON(http.StatusOK, ret)

    arg, ok := util.JsonArg(c, ret)
    if !ok {
        return
    }

    stmt := arg["stmt"].(string)
    result, err := sql.Query(stmt, model.Conf.Search.Limit) // ... runs arbitrary sql with no restrictions
}
```

The route in kernel/api/router.go only uses CheckAuth middleware

e.g (similar)

```go
ginServer.Handle("POST", "/api/query/sql", model.CheckAuth, SQL)
```

### PoC

Start SiYuan with the publish service turned on

```bash

# List out all tables in the database

curl -s -u reader_user:reader_pass \
  -X POST "http://127.0.0.1:6808/api/query/sql" \
  -H "Content-Type: application/json" \
  -d '{"stmt": "SELECT name, type FROM sqlite_master WHERE type='"'"'table'"'"'"}'


# Extract all user content from the database

curl -s -u reader_user:reader_pass \
  -X POST "http://127.0.0.1:6808/api/query/sql" \
  -H "Content-Type: application/json" \
  -d '{"stmt": "SELECT id, content FROM blocks"}'

```

### Impact
- High impact, reader users can query all data in the db including other users notes
- SQL api is mostly for select queries, but without validation, writes can still happen
- Malicious SQL can lead to serious performance issues

this is an auth bypass, the sql feature is for power users but even readers can use it
GitHub Security Advisory: GHSA-wj3p-5h3x-c74q
Package: github.com/rancher/backup-restore-operator (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: >= 6.0.0, < 6.0.3
Patched in: 6.0.3

Summary: Rancher Backup Operator pod's logs leak S3 tokens

Details:
### Impact
A vulnerability has been identified within the Rancher Backup Operator, resulting in the leakage of S3 tokens (both `accessKey` and `secretKey`) into the rancher-backup-operator pod's logs.

Specifically, the S3 `accessKey` and `secretKey` are exposed in the pod's logs under the following logging level conditions:

| Variable Exposed | Logging Level Condition | 
------------------ | ------------------------- |
| accessKey            | `trace: false` (default), and `debug: false` (default) |
| secretKey             | `trace: true` or `debug: true`|

**Note:** The S3 `accessKey` is exposed in the logs without requiring any supplementary configuration.

For further information on this attack category, please consult the associated [MITRE ATT&CK - Technique - Log Enumeration](https://attack.mitre.org/techniques/T1654/).

### Patches
This vulnerability is addressed by applying redaction to sensitive information that was leaking.

Patched versions of Rancher Backup Operator include: `108.0.1+up9.0.1`, `107.1.2+up8.1.2`, `106.0.6+up7.0.5`, and `105.0.6+up6.0.3`.

### Workarounds
Users are advised to rotate both S3 `accessKey` and `secretKey` once they have upgraded to a fixed version, especially if logs are exported.

Users who cannot update Rancher are advised to refresh the Rancher app Repository, which should provide the ability to update just the Rancher Backup chart alone. This will patch the vulnerabilities without requiring Rancher to be updated. This will not work for Rancher clusters in an air-gap setup.

For air-gapped Rancher clusters, the Rancher version must be updated first, and then after you will find the patched version of the Rancher Backup chart to upgrade. You will also need to sync new images for the release to your image mirror.

Users who cannot update either Rancher or Rancher Backup should ensure that both debug and trace values are both false (default). Users should revert the values to the default until they can update to prevent potential leaks.

### 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 [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
- Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).
GitHub Security Advisory: GHSA-wj3p-5h3x-c74q
Package: github.com/rancher/backup-restore-operator (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: >= 7.0.0, < 7.0.5
Patched in: 7.0.5

Summary: Rancher Backup Operator pod's logs leak S3 tokens

Details:
### Impact
A vulnerability has been identified within the Rancher Backup Operator, resulting in the leakage of S3 tokens (both `accessKey` and `secretKey`) into the rancher-backup-operator pod's logs.

Specifically, the S3 `accessKey` and `secretKey` are exposed in the pod's logs under the following logging level conditions:

| Variable Exposed | Logging Level Condition | 
------------------ | ------------------------- |
| accessKey            | `trace: false` (default), and `debug: false` (default) |
| secretKey             | `trace: true` or `debug: true`|

**Note:** The S3 `accessKey` is exposed in the logs without requiring any supplementary configuration.

For further information on this attack category, please consult the associated [MITRE ATT&CK - Technique - Log Enumeration](https://attack.mitre.org/techniques/T1654/).

### Patches
This vulnerability is addressed by applying redaction to sensitive information that was leaking.

Patched versions of Rancher Backup Operator include: `108.0.1+up9.0.1`, `107.1.2+up8.1.2`, `106.0.6+up7.0.5`, and `105.0.6+up6.0.3`.

### Workarounds
Users are advised to rotate both S3 `accessKey` and `secretKey` once they have upgraded to a fixed version, especially if logs are exported.

Users who cannot update Rancher are advised to refresh the Rancher app Repository, which should provide the ability to update just the Rancher Backup chart alone. This will patch the vulnerabilities without requiring Rancher to be updated. This will not work for Rancher clusters in an air-gap setup.

For air-gapped Rancher clusters, the Rancher version must be updated first, and then after you will find the patched version of the Rancher Backup chart to upgrade. You will also need to sync new images for the release to your image mirror.

Users who cannot update either Rancher or Rancher Backup should ensure that both debug and trace values are both false (default). Users should revert the values to the default until they can update to prevent potential leaks.

### 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 [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
- Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).
GitHub Security Advisory: GHSA-wj3p-5h3x-c74q
Package: github.com/rancher/backup-restore-operator (GO)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-532: Insertion of Sensitive Information into Log File
Vulnerable versions: >= 8.0.0, < 8.1.2
Patched in: 8.1.2

Summary: Rancher Backup Operator pod's logs leak S3 tokens

Details:
### Impact
A vulnerability has been identified within the Rancher Backup Operator, resulting in the leakage of S3 tokens (both `accessKey` and `secretKey`) into the rancher-backup-operator pod's logs.

Specifically, the S3 `accessKey` and `secretKey` are exposed in the pod's logs under the following logging level conditions:

| Variable Exposed | Logging Level Condition | 
------------------ | ------------------------- |
| accessKey            | `trace: false` (default), and `debug: false` (default) |
| secretKey             | `trace: true` or `debug: true`|

**Note:** The S3 `accessKey` is exposed in the logs without requiring any supplementary configuration.

For further information on this attack category, please consult the associated [MITRE ATT&CK - Technique - Log Enumeration](https://attack.mitre.org/techniques/T1654/).

### Patches
This vulnerability is addressed by applying redaction to sensitive information that was leaking.

Patched versions of Rancher Backup Operator include: `108.0.1+up9.0.1`, `107.1.2+up8.1.2`, `106.0.6+up7.0.5`, and `105.0.6+up6.0.3`.

### Workarounds
Users are advised to rotate both S3 `accessKey` and `secretKey` once they have upgraded to a fixed version, especially if logs are exported.

Users who cannot update Rancher are advised to refresh the Rancher app Repository, which should provide the ability to update just the Rancher Backup chart alone. This will patch the vulnerabilities without requiring Rancher to be updated. This will not work for Rancher clusters in an air-gap setup.

For air-gapped Rancher clusters, the Rancher version must be updated first, and then after you will find the patched version of the Rancher Backup chart to upgrade. You will also need to sync new images for the release to your image mirror.

Users who cannot update either Rancher or Rancher Backup should ensure that both debug and trace values are both false (default). Users should revert the values to the default until they can update to prevent potential leaks.

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