deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-5pmx-7r6r-wfqq
Package: github.com/kgateway-dev/kgateway/v2 (GO)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 2.1.0-agw-cel-rbac, < 2.1.0
Patched in: 2.1.0

Summary: Kgateway transformation policy template can emit files from the container 

Details:
## Summary

The transformation policy template feature in Kgateway versions through 2.0.4 allows users with TrafficPolicy creation permissions to craft transformations that read and expose arbitrary files from the dataplane container filesystem.

## Description

### Impact

Users with permissions to create a TrafficPolicy can create a transformation that returns files from within the dataplane container. While no secrets are mounted to the container by default, users who mount custom volumes to the dataplane should be aware of potential data exposure through this vulnerability.

This could allow unauthorized access to:
- Configuration files within the container
- Custom mounted volumes and their contents
- Any files accessible to the dataplane container process

Note: Updated availability score to high, as under some configurations this can prevent xDS updates.

### Patches

Upgrade to version 2.0.5 or 2.1.0. These versions include an updated transformation filter in envoy-gloo that prevents file access through transformation templates.

### Workarounds

If you are not using transformations, you can disallow TrafficPolicy creation or restrict transformation usage using a ValidatingAdmissionPolicy to prevent exploitation while preparing to upgrade.

## References

- Fix in 2.1.0: https://github.com/kgateway-dev/kgateway/pull/12528 (envoy-gloo v1.35.2-patch4)
- Backport to 2.0.5: Included in https://github.com/kgateway-dev/kgateway/pull/12535 (envoy-gloo v1.34.6-patch3)
- Envoy-gloo releases: https://github.com/solo-io/envoy-gloo/releases/tag/v1.35.2-patch4
- Envoy-gloo releases: https://github.com/solo-io/envoy-gloo/releases/tag/v1.34.6-patch3


## Credits

Kindly reported by @rikatz

## For More Information

If you have any questions or comments about this advisory, please reach out in slack https://cloud-native.slack.com/archives/C080D3PJMS4
GitHub Security Advisory: GHSA-5pmx-7r6r-wfqq
Package: github.com/kgateway-dev/kgateway/v2 (GO)
Severity: MODERATE (CVSS 6.3)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 2.0.5
Patched in: 2.0.5

Summary: Kgateway transformation policy template can emit files from the container 

Details:
## Summary

The transformation policy template feature in Kgateway versions through 2.0.4 allows users with TrafficPolicy creation permissions to craft transformations that read and expose arbitrary files from the dataplane container filesystem.

## Description

### Impact

Users with permissions to create a TrafficPolicy can create a transformation that returns files from within the dataplane container. While no secrets are mounted to the container by default, users who mount custom volumes to the dataplane should be aware of potential data exposure through this vulnerability.

This could allow unauthorized access to:
- Configuration files within the container
- Custom mounted volumes and their contents
- Any files accessible to the dataplane container process

Note: Updated availability score to high, as under some configurations this can prevent xDS updates.

### Patches

Upgrade to version 2.0.5 or 2.1.0. These versions include an updated transformation filter in envoy-gloo that prevents file access through transformation templates.

### Workarounds

If you are not using transformations, you can disallow TrafficPolicy creation or restrict transformation usage using a ValidatingAdmissionPolicy to prevent exploitation while preparing to upgrade.

## References

- Fix in 2.1.0: https://github.com/kgateway-dev/kgateway/pull/12528 (envoy-gloo v1.35.2-patch4)
- Backport to 2.0.5: Included in https://github.com/kgateway-dev/kgateway/pull/12535 (envoy-gloo v1.34.6-patch3)
- Envoy-gloo releases: https://github.com/solo-io/envoy-gloo/releases/tag/v1.35.2-patch4
- Envoy-gloo releases: https://github.com/solo-io/envoy-gloo/releases/tag/v1.34.6-patch3


## Credits

Kindly reported by @rikatz

## For More Information

If you have any questions or comments about this advisory, please reach out in slack https://cloud-native.slack.com/archives/C080D3PJMS4
GitHub Security Advisory: GHSA-4766-x535-jw3r
Package: github.com/kgateway-dev/kgateway/v2 (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-862: Missing Authorization
Vulnerable versions: < 2.0.5
Patched in: 2.0.5

Summary: kgateway is missing xDS authorization

Details:
## Summary

The xDS interface in Kgateway versions 2.0.0 through 2.0.4 lacks authentication, allowing any client with unrestricted network access to the xDS port to retrieve potentially sensitive configuration data including certificate data, backend service information, routing rules, and cluster metadata.

## Description

### Impact

Kgateway xDS interface did not have authorization, so anonymous clients with unrestricted network access could gain access to the xDS data. This could expose sensitive information about your gateway configuration, certificate data, backend services, and routing topology to unauthorized parties.

### Patches

Upgrade to version 2.0.5 or 2.1.0. These versions enable JWT-based authentication for the xDS interface by default, ensuring that only authenticated clients can access the xDS configuration data.

### Workarounds

If immediate upgrade is not possible, NetworkPolicies can be used to block access to kgateway's xDS port, restricting network access to only trusted sources.

## References

- Fix in 2.1.0: https://github.com/kgateway-dev/kgateway/pull/12471
- Backport to 2.0.5: https://github.com/kgateway-dev/kgateway/pull/12535
- Related issue: https://github.com/kgateway-dev/kgateway/issues/10651

## Credits

Kindly reported by @rikatz

## For More Information

If you have any questions or comments about this advisory, please reach out in slack https://cloud-native.slack.com/archives/C080D3PJMS4
GitHub Security Advisory: GHSA-4766-x535-jw3r
Package: github.com/kgateway-dev/kgateway/v2 (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-862: Missing Authorization
Vulnerable versions: >= 2.1.0-agw-cel-rbac, < 2.1.0
Patched in: 2.1.0

Summary: kgateway is missing xDS authorization

Details:
## Summary

The xDS interface in Kgateway versions 2.0.0 through 2.0.4 lacks authentication, allowing any client with unrestricted network access to the xDS port to retrieve potentially sensitive configuration data including certificate data, backend service information, routing rules, and cluster metadata.

## Description

### Impact

Kgateway xDS interface did not have authorization, so anonymous clients with unrestricted network access could gain access to the xDS data. This could expose sensitive information about your gateway configuration, certificate data, backend services, and routing topology to unauthorized parties.

### Patches

Upgrade to version 2.0.5 or 2.1.0. These versions enable JWT-based authentication for the xDS interface by default, ensuring that only authenticated clients can access the xDS configuration data.

### Workarounds

If immediate upgrade is not possible, NetworkPolicies can be used to block access to kgateway's xDS port, restricting network access to only trusted sources.

## References

- Fix in 2.1.0: https://github.com/kgateway-dev/kgateway/pull/12471
- Backport to 2.0.5: https://github.com/kgateway-dev/kgateway/pull/12535
- Related issue: https://github.com/kgateway-dev/kgateway/issues/10651

## Credits

Kindly reported by @rikatz

## For More Information

If you have any questions or comments about this advisory, please reach out in slack https://cloud-native.slack.com/archives/C080D3PJMS4
GitHub Security Advisory: GHSA-cfjq-28r2-4jv5
Package: github.com/zitadel/zitadel (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-287: Improper Authentication, CWE-308: Use of Single-factor Authentication
Vulnerable versions: < 1.80.0-v2.20.0[PII_REDACTED]1250-b284f8474eed
Patched in: 1.80.0-v2.20.0[PII_REDACTED]1250-b284f8474eed

Summary: Zitadel May Bypass Second Authentication Factor

Details:
### Summary

A vulnerability in Zitadel's token verification prematurely marked sessions as authenticated when only one factor was verified. 

### Impact

Zitadel provides an API for managing sessions, enabling custom login experiences in a dedicated UI or direct integration into applications. Session Tokens are issued for active sessions, which can be used as Bearer tokens to call the Zitadel API.

Starting from 2.55.0 (see other affected versions below), Zitadel only required multi factor authentication in case the login policy has either enabled `requireMFA` or `requireMFAForLocalUsers`. If a user has set up MFA without this requirement, Zitadel would consider single factor auhtenticated sessions as valid as well and not require multiple factors.

Bypassing second authentication factors weakens multifactor authentication and enables attackers to bypass the more secure factor. An attacker can target the TOTP code alone, only six digits, bypassing password verification entirely and potentially compromising accounts with 2FA enabled.

### Affected Versions

Systems using the session API (v2 beta and v2) directly or via the new login UI in the following versions are affected:
- **4.x**: `4.0.0` to `4.5.0` (including RC versions)
- **3.x**: `3.0.0` to `3.4.2` (including RC versions)
- **2.x**: `v2.53.6` to `v2.53.9`,  `v2.54.3` to `v2.54.10`, `2.55.0` to `2.71.17`

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring a configured second factor regardless of the login policies `requireMFA` or `requireMFAForLocalUsers` configuration.

4.x: Upgrade to >=[4.6.0](https://github.com/zitadel/zitadel/releases/tag/v4.6.0)
3.x: Update to >=[3.4.3](https://github.com/zitadel/zitadel/releases/tag/v3.4.3)
2.x: Update to >=[2.71.18](https://github.com/zitadel/zitadel/releases/tag/v2.71.18)

### Workarounds

The recommended solution is to update Zitadel to a patched version.

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)

### Credits

This vulnerability was found by [zentrust partners GmbH](https://zentrust.partners) during a scheduled penetration test. Thank you to the analysts Martin Tschirsich, Joud Zakharia, Christopher Baumann.
The full report will be made public after the complete review.
GitHub Security Advisory: GHSA-xrw9-r35x-x878
Package: github.com/zitadel/zitadel (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-307: Improper Restriction of Excessive Authentication Attempts
Vulnerable versions: < 1.80.0-v2.20.0[PII_REDACTED]0735-b8db8cdf9cc8
Patched in: 1.80.0-v2.20.0[PII_REDACTED]0735-b8db8cdf9cc8

Summary: Zitadel allows brute-forcing authentication factors

Details:
### Summary

A vulnerability in Zitadel allowed brute-force attack on OTP, TOTP and password allowing to impersonate the attacked user.

### Impact

An attacker can perform an online brute-force attack on OTP, TOTP, and passwords. While Zitadel allows preventing online brute force attacks in scenarios like TOTP, Email OTP, or passwords using a lockout mechanism. The mechanism is not enabled by default and can cause a denial of service for the corresponding user if enabled. Additionally, the mitigation strategies were not fully implemented in the more recent resource-based APIs.

### Affected Versions

All versions within the following ranges, including release candidates (RCs), are affected:
- **4.x**: `4.0.0` to `4.4.0` (including RC versions)
- **3.x**: `3.0.0` to `3.4.2` (including RC versions)
- **2.x**: `v2.0.0` to `2.71.17`

### Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by enforcing the lockout policy on all OTP, TOTP and password checks. Additionally a “tar pit” has been introduced to slow down brute-force attacks by default. Zitadel responses will be delayed by t seconds, where t increases over the number of failed attempts within a given timeframe.

4.x: Upgrade to >=[4.6.0](https://github.com/zitadel/zitadel/releases/tag/v4.6.0)
3.x: Update to >=[3.4.3](https://github.com/zitadel/zitadel/releases/tag/v3.4.3)
2.x: Update to >=[2.71.18](https://github.com/zitadel/zitadel/releases/tag/v2.71.18)

### Workarounds

The recommended solution is to update Zitadel to a patched version.

The problem might be mitigated by enabling the optional logout policy ("Password maximum attempts") or by implementing more strict rate limits.

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)

### Credits

This vulnerability was found by [zentrust partners GmbH](https://zentrust.partners) during a scheduled penetration test. Thank you to the analysts Martin Tschirsich, Joud Zakharia, Christopher Baumann.
The full report will be made public after the complete review.
GitHub Security Advisory: GHSA-mwmh-7px9-4c23
Package: github.com/zitadel/zitadel/v2 (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect'), CWE-640: Weak Password Recovery Mechanism for Forgotten Password
Vulnerable versions: < 1.80.0-v2.20.0[PII_REDACTED]0537-72a5c33e6ac3
Patched in: 1.80.0-v2.20.0[PII_REDACTED]0537-72a5c33e6ac3

Summary: ZITADEL Vulnerable to Account Takeover via Malicious Forwarded Header Injection

Details:
### Impact

A potential vulnerability exists in ZITADEL's password reset mechanism. ZITADEL utilizes the Forwarded or X-Forwarded-Host header from incoming requests to construct the URL for the password reset confirmation link. This link, containing a secret code, is then emailed to the user.

If an attacker can manipulate these headers (e.g., via host header injection), they could cause ZITADEL to generate a password reset link pointing to a malicious domain controlled by the attacker. If the user clicks this manipulated link in the email, the secret reset code embedded in the URL can be captured by the attacker. This captured code could then be used to reset the user's password and gain unauthorized access to their account.

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:
- **4.x**: `4.0.0` to `4.5.0` (including RC versions)
- **3.x**: `3.0.0` to `3.4.2` (including RC versions)
- **2.x**: `v2.0.0` to `2.71.17`

### Patches

Patched version ensure proper validation of the headers:

4.x: Upgrade to >=[4.6.0](https://github.com/zitadel/zitadel/releases/tag/v4.6.0)
3.x: Update to >=[3.4.3](https://github.com/zitadel/zitadel/releases/tag/v3.4.3)
2.x: Update to >=[2.71.18](https://github.com/zitadel/zitadel/releases/tag/v2.71.18)

### Workarounds

The recommended solution is to update ZITADEL to a patched version.

A ZITADEL fronting proxy can be configured to delete all Forwarded and X-Forwarded-Host header values before sending requests to ZITADEL self-hosted environments.

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)

### Credits

Thanks to Amit Laish – GE Vernova for finding and reporting the vulnerability.
GitHub Security Advisory: GHSA-mwmh-7px9-4c23
Package: github.com/zitadel/zitadel/v2 (GO)
Severity: HIGH (CVSS 8.1)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect'), CWE-640: Weak Password Recovery Mechanism for Forgotten Password
Vulnerable versions: >= 2.0.0, < 2.71.18
Patched in: 2.71.18

Summary: ZITADEL Vulnerable to Account Takeover via Malicious Forwarded Header Injection

Details:
### Impact

A potential vulnerability exists in ZITADEL's password reset mechanism. ZITADEL utilizes the Forwarded or X-Forwarded-Host header from incoming requests to construct the URL for the password reset confirmation link. This link, containing a secret code, is then emailed to the user.

If an attacker can manipulate these headers (e.g., via host header injection), they could cause ZITADEL to generate a password reset link pointing to a malicious domain controlled by the attacker. If the user clicks this manipulated link in the email, the secret reset code embedded in the URL can be captured by the attacker. This captured code could then be used to reset the user's password and gain unauthorized access to their account.

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:
- **4.x**: `4.0.0` to `4.5.0` (including RC versions)
- **3.x**: `3.0.0` to `3.4.2` (including RC versions)
- **2.x**: `v2.0.0` to `2.71.17`

### Patches

Patched version ensure proper validation of the headers:

4.x: Upgrade to >=[4.6.0](https://github.com/zitadel/zitadel/releases/tag/v4.6.0)
3.x: Update to >=[3.4.3](https://github.com/zitadel/zitadel/releases/tag/v3.4.3)
2.x: Update to >=[2.71.18](https://github.com/zitadel/zitadel/releases/tag/v2.71.18)

### Workarounds

The recommended solution is to update ZITADEL to a patched version.

A ZITADEL fronting proxy can be configured to delete all Forwarded and X-Forwarded-Host header values before sending requests to ZITADEL self-hosted environments.

### Questions

If you have any questions or comments about this advisory, please email us at [security@zitadel.com](mailto:security@zitadel.com)

### Credits

Thanks to Amit Laish – GE Vernova for finding and reporting the vulnerability.
GitHub Security Advisory: GHSA-gf93-xccm-5g6j
Package: github.com/3scale-sre/marin3r (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-862: Missing Authorization
Vulnerable versions: <= 0.13.3
Patched in: 0.13.4

Summary: MARIN3R: Cross-Namespace Vulnerability in the Operator

Details:
## Summary
Cross-namespace Secret access vulnerability in DiscoveryServiceCertificate 
allows users to bypass RBAC and access Secrets in unauthorized namespaces.

## Affected Versions
All versions prior to v0.13.4

## Patched Versions
v0.13.4 and later

## Impact
Users with permission to create DiscoveryServiceCertificate resources in one 
namespace can indirectly read Secrets from other namespaces, completely 
bypassing Kubernetes RBAC security boundaries.

## Workarounds
Restrict DiscoveryServiceCertificate create permissions to cluster administrators 
only until patched version is deployed.

## Credit
Thanks to @debuggerchen for the responsible disclosure.
GitHub Security Advisory: GHSA-xc93-q32j-cpcg
Package: github.com/jon4hz/jellysweep (GO)
Severity: HIGH (CVSS 0.0)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 0.13.0
Patched in: 0.13.0

Summary: Jellysweep uses uncontrolled data in image cache API endpoint

Details:
### Impact
The `/api/images/cache` which is used to download media posters from the server accepted an `url` parameter, which was directly passed to the cache package and that downloaded the poster from this URL.
This URL parameter can be used to make the jellysweep server download arbitrary content.

The API endpoint can only be used by authenticated users.

### Patches

Fixed in `v0.13.0`. The affected (and now fixed) library was also moved to `internal/` because it wasn't meant to be imported.


### References
https://github.com/jon4hz/jellysweep/security/code-scanning/28
GitHub Security Advisory: GHSA-h238-5mwf-8xw8
Package: github.com/treeverse/lakefs (GO)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-862: Missing Authorization
Vulnerable versions: < 1.71.0
Patched in: 1.71.0

Summary: lakeFS affected by unauthenticated access to API usage metrics

Details:
### Impact

Missing authentication in the `/api/v1/usage-report/summary` endpoint allows anyone to retrieve aggregate API usage counts. While no sensitive data is disclosed, the endpoint may reveal information about service activity or uptime.

### Patches
Upgrade to >v1.70.1

### Workarounds

Any **ONE** of these is sufficient to block this reporting:
- Disable usage reporting by setting configuration option `usage_report.enabled` or environment variable `LAKEFS_USAGE_REPORT_ENABLED` to `false`.
- Using load-balancer or application level firewall - blocking the request route /api/v1/usage-report/summary.
GitHub Security Advisory: GHSA-f9f4-5859-29mf
Package: github.com/sqls-server/sqls (GO)
Severity: HIGH (CVSS 7.5)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: = 0.2.28
Patched in: unpatched

Summary: sqls-server/sqls is vulnerable to command injection in the config command 

Details:
sqls-server/sqls 0.2.28 is vulnerable to command injection in the config command because the openEditor function passes the EDITOR environment variable and config file path to sh -c without sanitization, allowing attackers to execute arbitrary commands.

This issue has been patched via commit https://github.com/sqls-server/sqls/commit/468a23fc89af89f632cc023a10c031e4bc781797.
GitHub Security Advisory: GHSA-qqj3-g7mx-5p4w
Package: github.com/neuvector/neuvector (GO)
Severity: HIGH (CVSS 8.6)
CWE: CWE-295: Improper Certificate Validation, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 0.0.0[PII_REDACTED]3453-1c4957d53911, < 0.0.0[PII_REDACTED]3207-084a437033b4
Patched in: 0.0.0[PII_REDACTED]3207-084a437033b4

Summary: NeuVector telemetry sender is vulnerable to MITM and DoS

Details:
### Impact
This vulnerability affects NeuVector deployments only when the `Report anonymous cluster data option` is enabled. When this option is enabled, NeuVector sends anonymous telemetry data to the telemetry server at `https://upgrades.neuvector-upgrade-responder.livestock.rancher.io`.

In affected versions, NeuVector does not enforce TLS certificate verification when transmitting anonymous cluster data to the telemetry server. As a result, the communication channel is susceptible to man-in-the-middle (MITM) attacks, where an attacker could intercept or modify the transmitted data. Additionally, NeuVector loads the response of the telemetry server is loaded into memory without size limitation, which makes  it vulnerable to a Denial of Service(DoS) attack. 

The patched version includes the following security improvements:
- NeuVector now verifies the telemetry server’s `TLS certificate chain` and `hostname` during the handshake process. This ensures that all telemetry communications occur over a trusted and verified channel.
- NeuVector limits the telemetry server’s response to `256 bytes`, mitigating the risk of memory exhaustion and DoS attacks.

These security enhancements are enabled by default and require no user action.


### Patches
Patched versions include release **v5.4.7** and above.

### Workarounds
If you cannot update to a patched version, you can temporarily disable the Report anonymous cluster data, which is enabled by default in NeuVector.
To change this setting, go to **Settings** → **Configuration** → **Report anonymous cluster data** in the NeuVector UI.

Disabling this option prevents NeuVector from sending telemetry data to the telemetry server, which helps mitigate this vulnerability.


### 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).